如何使编码质量保持正轨
本篇文章基于之前所说的“焦油坑”项目,探讨一下在接手这些项目之后,如何能够保证编码质量。
说实话,想要保证这类项目的编码质量真的很难,在付出大量的时间、精力之后,很有可能是劳而无功。原因有很多,比如:积重难返、时间不充足、人员能力参差不齐、一锤子买卖。
一般来说,成本是固定的,范围只可能增加却不太可能减小,一般的项目都会在时间上做文章,会尽可能的压缩时间。这就导致需求靠嘴,设计全无,直接就编码。在这种情况下,只能够尽可能保证编码质量。
1. 通读源码。一般情况下,其实不太可能给太多的时间去深入了解代码,但是了解一下整体结构,每个包的作用,还是应该有的,这对之后的编码会有很大的好处。
2. 保持编码风格。每个人的编码风格都不太一样,在接手这种项目时,尽量与之前的编码保持风格,比如:之前是驼峰命名,现在也驼峰命名,不要再搞一套风格。这样便于阅读,不会在多种风格之间切换,导致读起来很难受。
3. 沿袭原有的设计。尽可能的沿袭原有的设计,比如原有设计使用的是SpringMVC,就没有必要非得换成SpringBoot。再比如原有的设计是贫血模型,就没有必要非得搞成充血模型。想怎么来就怎么来的后果,就是难以自拔。
3. 尽量多的使用原有工具类。很多工程师在接手一个项目后,特别喜欢到处声明自己的工具类或者干脆就不用工具类,这样想怎么样就怎么来的做法是很方便,但是直接导致冗余代码增多,造成的负担也会越来越重。
4. 尽量少的改动原有类。有的工程师是没有追求,有的工程师是追求过火,恨不得推翻原有代码重建,可惜最后总是虎头蛇尾,头尾不能相顾。对待原有代码要非常小心,如果不能保证完全清楚来龙去脉,最好放弃重构。
5. 少新增类,多新增方法。类新增的太多,导致难以维护,很难分清晰各自的职责,很容易恶性循环。新增方法就好的多,即不会影响原有结构和结果,又变的更加容易控制。
6. 新增的方法有明显的注释。Visual Studio的“region”就很好,可以有效的包裹业务逻辑,有明显的注释。IDEA也有相同的关键字。近几年eclipse用的比较少,读者可以自行寻找。
7. 小心编码,保持美感。不要因为这是一个烂的项目,就随心所欲。每一次编码都是一种升华,尽可能的保持代码的简洁、清晰,让其具备一种美感,也能保持心情愉悦。
8. 别惯客户臭毛病。这个说真的,是最难的。各种需求五花八门,各种设计天马行空。理想中的应该是一起制定目标,静心讨论,消除隔阂,保持客户参与度。但是,客户一般会关注结果较多,而且通常只懂业务不懂技术,会增加很大的编码难度,导致质量出现滑坡。
通过这篇文章,希望各位读者少在“焦油坑”里面扑腾,早日上岸,远离烦恼。