NingG +

开发实践:代码重构的思考

特别说明:这个是一个经验丰富的同事(王洋)写的,内容非常好,转发到我的 blog 上了。

写代码的一些原则

写代码的一些原则:

具体的措施

以下是一些具体的措施:

一、命名

二、常量

这里举一个例子:

HashMap<String,String> contentMap = new HashMap<String,String>();
//放入一个数据的时候是这样的:
contentMap.put("orderId",orderId);
// 取出数据的时候是这样的:
String orderId = contentMap.get("orderId");

这里的“orderId”字符串就称之为魔法字符串,其实很容易写错。而且假如以后这个参数改个名字叫:movieOrderId,那这些字符串就得改很多处,而且不能通过搜索特定字符串一次性替换(因为很多变量名也叫orderId,而且并不见得所有的“orderId”都应该改)。而如果使用常量来代表“orderId”字符串,就在key形成了一致性约束,以后改名字的时候,只需要改常量的内容,put和get操作就自动一致了。这是一个简单的变量“高内聚”

三、删掉未使用代码

四、代码布局

五、注释

六、日志

七、异常和中断处理

八、模块划分

模块划分的目的是为了“高内聚”,把具有相同意义的代码和数据放在一起,一是方便了阅读和查找,二是可以将稳定的代码沉到下层,变化抽象到上层。下图是我们之前商量过的代码分层框架, 不一定要完全按照这种模式来,但可以有意的按照这种思路去把代码分离开。

从下到上来说各层代表含义:

这样分模块的目的是为了减少代码的耦合性,把相关的数据和代码抽象的更集中,每当你想用某个常量、枚举、对象的时候,你大致扫一下domain就知道当下有什么东西,不致于针对同一个东西写好几份代码。而对于service来说,站在原子服务的角度来说,因为service足够小,所以增加新业务时,service是可以不修改的,而只需要添加服务就可以,biz层也只需要添加逻辑,组合service的服务就可以达到目的,这样就达到了“开放扩展,关闭修改”的目的,降低修改代码带来的风险。

九、使用模型

处理外部数据时,尽量使用自己的业务模型,除非特别简单的http回应,其它的处理都是应该封装自己的model的。

为什么要把外部数据映射成model呢?

模型要有业务含义,在传递给服务时,一定要和该服务有很强的业务关系,不要为了简单使用DO,或者参数差不多、但业务不相关的model图省事。对于没有形成强业务绑定的model,经常会因为一个业务的修改,导致当下业务也需要联动的修改。要降低耦合性

避免超级model,做任何业务,都把参数往一个model中塞。这样一是让看代码的人毫无头绪,不知道到底哪些参数和当下业务相关,二是让修改的人很担心,去掉一个参数会不会影响到多个业务。所以尽量避免使用公共model,如果确实参数重合度比较高的,可以考虑model之间的有意义的继承。

多用模型,少用hashmap。hashmap当时它相当于一个自由模型,啥都可以塞,啥都可以取,使用上是方便,但是没有套上任何业务信息,业务越大,修改越多,就会越不可控。每次修改都会造成一些隐患。

Top