提高团队代码质量

最近看到一篇博客，大致的意思就是网管将原本混乱不堪的交换机整理整齐了，起初交换机是图2那样的，由于越来用的人越多，操作的人越来越多，最终成为了图1那个样子。这不禁让我想到了项目中的代码，原先在刚上线的时候谈不上是完美的，但它总归是整齐的，但是由于中间人员流动，bug修改等等原因吧，最终的结果就是代码一团糟。为什么会出现这样的情况呢？

          

图1                                            图2

权限（权利）

拿交换机来说，当自己的网络不通畅的时候自己可以随便进出机房对交换机进行操作，插拔自己的网线的时候只要能让自己的网络通常，那么网线乱一些那又有什么关系呢？第一个人是这样想的同时也是这样做的，紧接着第二个、第三个……久而久之就成了图1的样子，混乱不堪。

同理代码也是一个道理，自己需要实现一个功能，在原来代码的基础上进行修改，只要自己的功能好使代码之间的耦合大一些又有什么关系呢？刚入职的第一个新人是这么想的也是这么做的紧接着第二个、第三个……久而久之仓库中的代码就变成了现在的这个样子，惨不忍睹。

没有权限的人可以操作本不该操作的东西，最终一定会一团糟。因为的人们在自己焦头烂额的时候才顾不上会不会影响他人，尽快将自己手头的棘手的问题解决掉才是重中之重。对于权限管理最经典的一句话就是：权限越低犯错的机会就越少。所以新人直接提交代码到代码库是欠妥的。

责任

出现这样的情况是因为大家只关心自己的一亩三分地，“各扫自家门前雪，休管他人瓦上霜”是每个人的不变信念，问题是“他人”并不是别人，是自己人，他人“瓦上霜”其实就是以后自己的“门前雪”。其实责任这个词就是自私的放大版，胸怀有多宽广责任就有多重大。

记得读过一篇关于代码质量的文章，其中说到一个理论叫破窗理论：一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙地被人打破；一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一个很干净的地方，人们不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹豫地抛，丝毫不觉羞愧。

很多情况下代码晦涩难懂并不是一下子就变成这个样子的，冰冻三尺非一日之寒。从第一个不负责任的人开始代码变得越来越难以维护。如果在提交代码之前有人（几个人）去review要提交的代码，相信出现问题的可能性就大大减小。试想自己的代码是要被全世界程序员读的，相信你会提高自己的代码质量。

行动

发生了这样的事情，最终是要解决的，如果希望永远不发生这样的事情，这是一种理想状态，只有说前面的工作我们尽可能的做好来降低这种事情出现的概率。但是，一旦发现了问题还是需要解决的。而且是立刻解决，否则错误会随着时间的推移解决成本也就越来越大。不要借口说现在没时间，等有时间了如何如何吧。现在没时间以后更没时间，因为以后只会比现在更忙。(什么？项目紧没时间，那么请跳槽，对于一个没有规划急功近利的公司是需要被社会淘汰的，所以你的不离职就是在姑息整个软件行业的不良风气)

Review初期是可以避免很多低级错误的，但是到了后期就流于形式了，因为一直负责review的负责人已经疲惫了。况且很多严重的bug并不是review就能发现的，Review只能找出显而易见的错误。所以，

第一、负责review代码的人决不能固定，而且一份代码可以多人review

第二、不放过任何一个Bug，尤其是因为修改或者新用例带来的bug，这些bug后面就藏着不整洁的代码，需要整个团队耐心的将其挖掘出来解决掉。