代码质量——摘自刘未鹏博客

来源：互联网发布：winform界面设计软件编辑：程序博客网时间：2024/05/18 03:38

在各种长期和短期压力之下写代码，当然代码质量是重中之重，尤其是对于C++代码，否则各种积累的技术债会越压越重。对于创新项目而言，代码基处于不停的演化当中，一开始的时候什么都不是，就是一个最简单的骨架，然后逐渐出现一点prototype的样子，随着不断的加进新的feature，再不断重构，抽取公共模块，形成concept和abstraction，isolate接口，拆分模块，最终prototype演变成product。关于代码质量的书很多，有一些写得很好，例如《The Art of Readable Code》，《Clean Code》或者《Implementation Patterns》。这里没有必要去重复这些书已经讲得非常好的技术，只说说我认为最重要的一些高层的指导性原则：

持续重构：避免代码质量无限滑坡的办法就是持续重构。持续重构是The Boy Scout Rule的一个推论。离开一段代码的时候永远保持它比上次看到的时候更干净。关于重构的书够多的了，细节的这里就不说了，值得注意的是，虽然重构有一些通用的手法，但具体怎么重构很多时候是一个领域相关的问题，取决于你在写什么应用，有些时候，重构就是重设计。例如我们的代码基当中曾经有一个tricky的设计，因为相当tricky，导致在后来的一次代码改动中产生了一个很隐蔽的regression，这使得我们重新思考这个设计的实现，并最终决定换成另一个（很遗憾仍然还是tricky的）实现，后者虽然仍然tricky（总会有不得已必须tricky的地方），但是却有一个好处：即便以后代码改动的过程中又涉及到了这块代码并且又导致了regression，那么至少所导致的regression将不再会是隐蔽的，而是会很明显。
KISS：KISS是个被说烂了的原则，不过由于”Simple”这个词的定义很主观，所以KISS并不是一个很具有实践指导意义的原则。我认为下面两个原则要远远有用得多： 1) YAGNI：You Ain’t Gonna Need It。不做不必要的实现，例如不做不必要的泛化，你的目的是写应用，不是写通用库。尤其是在C++里面，要想写通用库往往会触及到这门语言最黑暗的部分，是个时间黑洞，而且由于语言的不完善往往会导致不完备的实现，出现使用上的陷阱。2) 代码不应该是没有明显的bug，而应该是明显没有bug：这是一条很具有指导意义的原则，你的代码是否一眼看上去就明白什么意思，就确定没有bug？例如Haskell著名的quicksort就属于明显没有bug。为了达到这个目的，你的代码需要满足很多要求：良好的命名（传达意图），良好的抽象，良好的结构，简单的实现，等等。最后，KISS原则不仅适用于实现层面，在设计上KISS则更加重要，因为设计是决策的第一环，一个设计可能需要三四百行代码，而另一个设计可能只需要三四十行代码，我们就曾遇到过这样的情况。一个糟糕的设计不仅制造大量的代码和bug（代码当然是越少越好，代码越少bug就越少），成为后期维护的负担，侵入式的设计还会增加模块间的粘合度，导致被这个设计拖累的代码像滚雪球一样越来越多，所以code review之前更重要的还是要做design review，前面决策做错了后面会越错越离谱。
解耦原则：这个就不多说了，都说烂了。不过具体怎么解耦很多时候还是个领域相关的问题。虽然有些通用范式可循。
Best Practice Principle：对于C++开发来说尤其重要，因为在C++里面，同一件事情往往有很多不同的（但同样都有缺陷的）实现，而实现的成本往往还不低，所以C++社群多年以来一直在积淀所谓的Best Practices，其中的一个子集就是Idioms（惯用法），由于C++的学习曲线较为陡峭，闷头写一堆（有缺陷）的实现的成本很高，所以在一头扎进去之前先大概了解有哪些Idioms以及各自适用的场景就变得很有必要。站在别人的肩膀上好过自己掉坑里。