original="https://static.oschina.net/uploads/space/2017/0918/081801_AH3f_2720166.png" data-image-enhancer="larger than third of 645" />
定义代码质量
首先当你开始意识到项目里代码质量差的时候，恭喜你已经有了代码审美。这是推进编程水平的重要的一步。很显然，如果你不知道什么是差的代码，你就写不出好的代码。写不出好的代码，更高的架构也就无从谈起。
先来定义团队代码质量的黄金标准：易维护。
代码最基本的要求，易读。现代的软件项目都不是一朝一夕，有团队合作，有新需求，要修 bug，代码不只是只给机器读的，是给人读的。一份清晰、易懂的代码就包括了：良好的代码风格，清晰的逻辑，合理的结构。也许做到 90 分和天赋有关，做到 70 分其实没难度，单纯看你花了多少努力在这件事。
很多人用中文写几百个字描述一件事都说不清，一个逻辑有两千行代码又怎么可能写的清楚呢。锻炼过程也和提高表达能力相似，只是之前是某种文字，现在是用代码。文学里有修辞手法，有总分总，代码里有语法糖，有 MVC。
代码质量从何开始
如果重视代码质量，如何达成代码质量的基本共识呢？
解决这个问题的核心并不是一本万能手册。不存在一本黄金宝典，包含了各式各样的代码，任何时候都可以按图索骥得到一个检验标准。你能得到的是一个评判的方式，可以从哪些角度去认知代码，最后发现这样的代码在这个条件会引起一些问题，所以这代码不够好。
我认为的起点是这几本书：《编写可读代码的艺术》《代码整洁之道》《重构》《代码大全》。就如前面说过的，这些书的重点并不是具体某个代码、某种条件下好的代码长什么样，而是他们怎么得出了这样的结果。当你理解了这几本书的核心思想后可以开始正确审视自己的代码质量了，可以开始 code review 了。
追求代码质量是一个成长的过程
代码质量就像作者写出好的文章一样，是一个不断进步、不断推进的过程。
一开始你可能写十几行就要停下来思考，这个命名合不合适，这样的逻辑是不是有点乱。后面可能到一个类的封装是不是合适。再后面可能几个月回头看自己的代码才意识到，当时这样写会有歧义，扩展性不好等等。
这也是自己不断提高编程能力的过程，写出易维护的代码只是第一步。
没有 code review 的团队没有未来
如何提高团队的代码质量？
代码是有程序员写出来的，如果每个人都是老江湖，团队的代码质量就高了啊。可是能有几个团队每个人都能写出高质量的代码？
其实真的非常简单，严格的执行 code review 就可以了。让那些知道好代码长什么样的人控制代码质量。就像工厂里的质检，不合格的代码不会被合进代码库。
没有 code review 的团队没有未来。
要不就是这个团队技术能力差，没有能力进行 review。
要不就是项目简单，不需要 review，什么垃圾代码都可以完美支撑。
要不就是项目复杂，团队技术实力也可以。核心代码由救火队员控制，他们根本不关心其他人代码写成怎么样。出问题了他们救火，他们会保证项目运行，其他成员技术能力的提高不在意。
最后一种情况可能是最常见的情况，但是也是最可悲的情况。他意味技术团队的负责人本质上并不关心成员的技术成长。提高项目代码质量的最终实现还是靠每个成员的能力可以写出高质量的代码。每个人都成长了，最后项目代码质量自然就提高了。然而管理技术团队的人没有意识去促成这件事情的发生，那么一个新手在这样的团队成长还是靠自我摸索，这会是一个缓慢的过程。
Code review 就像快进的结对编程，一个老手点评一个新手代码的时候，就会产生交流，要阐明为什么不能这样写。在保证项目质量的同时，对新手也进行了指引。两个水平相当的人 review 则得到了其他视角的审视结果，最后交流的结果就是两个人都得到了更全面的见解。
所以没有 code review 的团队没有未来。每个团队都有自己的基因，如果你在团队没有话语权，只能祝你早日找到一个有 review 的团队，不要期望通过自己的努力改变他们。以我的经验来看，无法叫醒一个装睡的人，一个真正好的团队，推进 code review 不会有任何阻力，如果有，开掉那个人。
转自：闲谈团队的代码质量 作者：没故事的卓同学
相关文章
