本篇文章基于之前所说的“焦油坑”项目，探讨一下在接手这些项目之后，如何能够保证编码质量。

说实话，想要保证这类项目的编码质量真的很难，在付出大量的时间、精力之后，很有可能是劳而无功。原因有很多，比如：积重难返、时间不充足、人员能力参差不齐、一锤子买卖。

一般来说，成本是固定的，范围只可能增加却不太可能减小，一般的项目都会在时间上做文章，会尽可能的压缩时间。这就导致需求靠嘴，设计全无，直接就编码。在这种情况下，只能够尽可能保证编码质量。

1. 通读源码。一般情况下，其实不太可能给太多的时间去深入了解代码，但是了解一下整体结构，每个包的作用，还是应该有的，这对之后的编码会有很大的好处。

2. 保持编码风格。每个人的编码风格都不太一样，在接手这种项目时，尽量与之前的编码保持风格，比如：之前是驼峰命名，现在也驼峰命名，不要再搞一套风格。这样便于阅读，不会在多种风格之间切换，导致读起来很难受。

3. 沿袭原有的设计。尽可能的沿袭原有的设计，比如原有设计使用的是SpringMVC，就没有必要非得换成SpringBoot。再比如原有的设计是贫血模型，就没有必要非得搞成充血模型。想怎么来就怎么来的后果，就是难以自拔。

3. 尽量多的使用原有工具类。很多工程师在接手一个项目后，特别喜欢到处声明自己的工具类或者干脆就不用工具类，这样想怎么样就怎么来的做法是很方便，但是直接导致冗余代码增多，造成的负担也会越来越重。

4. 尽量少的改动原有类。有的工程师是没有追求，有的工程师是追求过火，恨不得推翻原有代码重建，可惜最后总是虎头蛇尾，头尾不能相顾。对待原有代码要非常小心，如果不能保证完全清楚来龙去脉，最好放弃重构。

5. 少新增类，多新增方法。类新增的太多，导致难以维护，很难分清晰各自的职责，很容易恶性循环。新增方法就好的多，即不会影响原有结构和结果，又变的更加容易控制。

6. 新增的方法有明显的注释。Visual Studio的“region”就很好，可以有效的包裹业务逻辑，有明显的注释。IDEA也有相同的关键字。近几年eclipse用的比较少，读者可以自行寻找。

7. 小心编码，保持美感。不要因为这是一个烂的项目，就随心所欲。每一次编码都是一种升华，尽可能的保持代码的简洁、清晰，让其具备一种美感，也能保持心情愉悦。

8. 别惯客户臭毛病。这个说真的，是最难的。各种需求五花八门，各种设计天马行空。理想中的应该是一起制定目标，静心讨论，消除隔阂，保持客户参与度。但是，客户一般会关注结果较多，而且通常只懂业务不懂技术，会增加很大的编码难度，导致质量出现滑坡。

通过这篇文章，希望各位读者少在“焦油坑”里面扑腾，早日上岸，远离烦恼。