你是否曾被糟糕的代码困扰过？为何会出现这样的代码?是想快点儿完成还是赶时间？

代码拖后腿、对代码的修改都会影响其他代码。不断补救前面混乱的代码，导致团队生产力开始下降，趋向于零，加上团队管理层缺乏项目管理经验，只能不断往项目中增加人手，期望以此提升生产力。由于并不存在人月神话，新人和老人都只能背负着提升生产力的可怕压力，结果产生了更多的混乱。长此以往，团队陷入了“沼泽”般的恶性循环。

1.代码整洁：整洁成就卓越代码

本章所有的理论和做法都是基于相信“混乱的代码是罪魁祸首，而保持代码整洁是唯一的解决之道”这一观点来分享的。

什么是代码整洁？C++发明者斯特劳斯特鲁普指出：“我喜欢优雅和高效的代码。代码逻辑应当直截了当，让缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

斯特劳斯特鲁普的这段话包含整洁代码的标准和做法，强调“整洁的代码只做好一件事”。仔细想来确实如此，糟糕的代码想做太多事，意图混乱、目的不明；而整洁的代码力求集中，每个函数、每个类和每个模块都全神贯注于一件事，不受细节的干扰和影响。

可见，整洁的代码看起来优雅、美观，读起来令人愉悦。而代码运行效率也值得我们关注：多余的运算周期并不雅观，也不会让人愉悦。糟糕的代码可能引发“破窗效应”：一扇破损的窗户被放任破损，最终整个大厦都将倾颓。糟糕的代码还会引发更大的混乱一一因为在修改烂代码时，往往会越改越烂。

（1）代码尽量精简

简洁函数能增加代码的易读性。这也使我们倾向于编写功能单一、高效的函数。

我们衡量类的大小时，可以用“职责”代替“代码行”的概念:一个类应该只有一个职责，也就是一个类应该只做一件事。

（2）删除不必要的代码注释

（3）别重复自己

2.代码可读性：Keep It Simple，Stupid

阿道先做一个假设：程序员绝大部分时间不是编写全新的代码，而是阅读、理解和修改代码。在这个基础上，如果代码可读性差，就会让大家在阅读和修改代码时浪费时间。

（1）审美

（2）变量

（3）命名

3.代码规范：格式、注释分清楚

其实这一节内容完全可以包含在前两节内容中，但阿道在工作中曾深受代码不规范的困扰，如看不懂别人的变量命名、找不到自己曾经的文件等，故将其作为单独一节呈现，以强调代码规范的重要性。

命名对软件开发很重要，当程序员看到文本命名时，会下意识地根据文本的意义和自身的经验来理解并解释，那么如果此时文本和内涵不一致，就会给别人带来阅读和理解上的困难。

系统设计的结果是“概念模型”。这个模型主要由概念和逻辑推理构成，如果概念定义不扎实，系统设计的“大厦”就不会坚固。而命名代表了概念的定义，所以是系统设计的基础层，重要性不言而喻。

最后，给大家分享阿道所在的禅道团队的代码规范经验。

首先，在制定编码规范的时候简化规则。规则越多，就越不容易记忆，越容易出现意外。我们的命名规范就只有一个驼峰。从数据库到程序到页面，所有的命名都遵循驼峰这样一个规则。阿道了解有的团队的命名规范比较多，如类名首字母会大写、数据库字段名会用下画线间隔，其实大可不必，简单一点的规则更容易遵循。

其次，我们会更关注起一个好的名字。从数据库名到表名，到字段名，到程序里面的类名、属性名、方法名、参数、返回值，到接口里面的入参、出参，再到页面里面的元素、样式，一定要多花点儿心思想一个可以自我解释的名字。有的朋友可能会讲，还有注释呢。但与其写注释来解释这个名字是什么含义，不如花点儿时间让它自我解释。

我们还会通过定期的集体代码评审来统一大家的编码规范。每两周抽个时间把大家都聚到一起，统一看代码，检查代码审查规范的问题、命名的问题、逻辑的问题、版式的问题，以及实现方案的问题、效率的问题和安全的问题等。通过这种方式可以有效地保证规范在团队里面的贯彻执行。