从代码质量谈起

Posted 2020-10-13 思踌之路

最近加入了一个临时的项目组，针对前期客户提出的需求在原有系统上做一些升级开发。说白了就是只能使用旧的技术在原有代码上增加功能，有的是需要开发新功能有的只是在原有基础上进行改进。刚开始，项目经理在和我谈需求的时候聊得轻描淡写，以为只是做一些简单的迭代开发，因此信心满满的答应下来。可直到拿到项目的源码才发现全然不是这么回事。项目逻辑混乱，代码杂论无章再加上客户需求不够具体致使整个项目组一度陷入阅读源码的泥潭。

2017年初阿里巴巴也发布了《Java开发手册》旨在帮助行业人员提高开发质量和效率、大大降低代码维护成本，手册里面提到的规范我无需列举。在此只是做一些补充把我个人认为非常重要又很基础的规范提出来供大家讨论。

1.容器类

　　i.不要乱用容器：不要为了方便用容器类代替JavaBean的作用。尤其在数据库的读取的时候，尽量使用对应的实体对象传输数据。

　　ii.使用容器都必须有泛型约束：使用容器类就一定要为容器增加泛型约束。容器是为了提高代码效率而产生的，不要为了省事把容器当成“垃圾箱”。

　　iii.函数形参超过4个且类型相同的时候才应该考虑使用容器作为形参：使用容器作为形参会让二次开发人员无法对参数一目了然，降低代码的可读性和增加接口文档的编写难度。

　　iv.作为方法返回值的容器类型不能直接作为其他方法的实参带入：容器类经常被作为方法的返回值，但是不可以直接将它作为实参带入其他方法。因为使用同一个容器来回在不同的方法中进出会污染容器并且也让二次维护变的极其困难。因此即使是类型相同，泛型形同的情况下也应该首先在方法外将包含的对象取出来，然后再生成新的容器作为实参。

2.异常类

　　i.不要别出心裁的设计异常：JDK提供的异常种类已经足够了。除非是有特殊需求否则不要专门设计一个异常类。自定义的异常只会增加代码的耦合。

　　ii.推荐抛出RuntimeException：RuntimeException不需要在接口中声明。

3.变量

　　1.变量名不可以使用拼音且应该意图清晰：一个好的变量名应该能同时提供多种信息（包括：变量功能，变量类型）

4.代码提交

　　i.不要提交有问题的代码：SVN不是代码痕迹管理，提交出错的代码可能会让整个项目成员的项目都报错。如果仅仅是希望保持一个痕迹管理的个人版本，推荐使用GIT。

5.项目

　　i.小而精好过大而全

　　ii.约定优于配置

Coder不是天然的高大上，我们是为了让计算机更好的帮助人类工作而存在的职业。大多数时候我们会穿着廉价的T恤，喝着廉价的咖啡，使用着廉价的电脑。如果你还编写着廉价的代码，就等于挥霍着廉价的青春。

最后的最后，永远不要向垃圾代码妥协——至每一个不愿意向现实低头的行者，及我。