我们身边总会充斥着一些牛不像牛马不像马的代码。读起来繁琐,改起来痛苦。尤其是维护别人写的代码的时候,往往都会抱怨:要是让我知道这是谁写的,我非打他一顿。可是扪心自问,我们自己写过的代码又是什么样的?维护我们自己代码的人会不会也是这样想呢?
想必大家都有这样的感受,一个需求刚开始开发的时候,特别用心的设计代码,这里用这样封装,那里用那种模式。等到需求变了三次,代码就开始看不懂什么样子了。等到维护两年,好多地方自己都不敢动了。再换成别人来维护,改了一个问题,引发三个问题,换成谁都得疯。
那究竟应该怎么办呢?以下几点是本人的愚见。
第一,不要刻意追求设计模式。有一些人张嘴闭嘴就是设计模式,学了几种设计模式到处套用,来显示自己的有水平,还美名其曰是为了以后可维护和可扩展。但是真的是这样么?每种设计模式是为了解决对应的问题而存在的。说白了他只是一种解决方案。设计模式是好,但是不要硬套。我们的目的是要解决我们存在的问题,实现我们对应的功能。好多时候我们写三个类,五个方法,时不时的重构一下,问题全部解决了。为什么还要套几种设计模式,弄的以后维护的人读起来一阵头大。
第二,尽量多思考一些原则。比如类的单一职责原则(一个类只做一件事),开闭原则(扩展开放,修改关闭),里氏替换原则(is a的关系可以代替)等等,这些是降低耦合的根本,也会让我们更加明白我们是要干什么。
第三,减少每一个方法的代码量。有一句话是一个方法里面的代码尽量不要超过30行。因为太多了就不容易读懂了,也有可能参杂了别的功能。我们要尽量拆分我们的方法。一个方法只做一个动作,就像一个类只做一件事情一样。功能性的代码更是不要有逻辑判断。
第四,一定要写注释。有的人说只要所有命名规范就可以不用注释,那都是理想的状态。我们要写清楚什么时间,谁做了什么修改,目的是完成什么功能。这样我们在版本控制器上可以很明确追溯到代码的发展。