近期看到一篇博客。大致的意思就是网管将原本混乱不堪的交换机整理整齐了，起初交换机是图2那样的，由于越来用的人越多，操作的人越来越多。终于成为了图1那个样子。这不禁让我想到了项目中的代码。原先在刚上线的时候谈不上是完美的，但它总归是整齐的。可是由于中间人员流动，bug改动等等原因吧，终于的结果就是代码一团糟。为什么会出现这种情况呢？
图1 图2
权限（权利）
拿交换机来说，当自己的网络不通畅的时候自己能够随便进出机房对交换机进行操作，插拔自己的网线的时候仅仅要能让自己的网络通常，那么网线乱一些那又有什么关系呢？第一个人是这样想的同一时候也是这样做的，紧接着第二个、第三个……久而久之就成了图1的样子，混乱不堪。
同理代码也是一个道理。自己须要实现一个功能，在原来代码的基础上进行改动，仅仅要自己的功能好使代码之间的耦合大一些又有什么关系呢？刚入职的第一个新人是这么想的也是这么做的紧接着第二个、第三个……久而久之仓库中的代码就变成了如今的这个样子。慘不忍睹。
没有权限的人能够操作本不该操作的东西，终于一定会一团糟。由于的人们在自己焦头烂额的时候才顾不上会不会影响他人，尽快将自己手头的棘手的问题解决掉才是重中之重。
对于权限管理最经典的一句话就是：权限越低犯错的机会就越少。
所以新人直接提交代码到代码库是欠妥的。
责任
出现这种情况是由于大家仅仅关心自己的一亩三分地。“各扫自家门前雪。休管他人瓦上霜”是每一个人的不变信念，问题是“他人”并非别人，是自己人。他人“瓦上霜”事实上就是以后自己的“门前雪”。
事实上责任这个词就是自私的放大版。胸怀有多宽广责任就有多重大。
记得读过一篇关于代码质量的文章，当中说到一个理论叫破窗理论：一个房子假设窗户破了，没有人去修补，隔不久。其他的窗户也会莫名其妙地被人打破。一面墙。假设出现一些涂鸦没有被清洗掉。非常快的，墙上就布满了乱七八糟、不堪入目的东西；一个非常干净的地方，人们不好意思丢垃圾。可是一旦地上有垃圾出现之后。人就会毫不犹豫地抛，丝毫不觉惭愧。
非常多情况下代码晦涩难懂并非一下子就变成这个样子的。冰冻三尺非一日之寒。
从第一个不负责任的人開始代码变得越来越难以维护。假设在提交代码之前有人（几个人）去review要提交的代码，相信出现故障的可能性就大大减小。试想自己的代码是要被全世界程序猿读的，相信你会提高自己的代码质量。
行动
发生了这种事情，终于是要解决的，假设希望永远不发生这种事情。这是一种理想状态，仅仅有说前面的工作我们尽可能的做好来减少这种事情出现的概率。
可是。一旦发现了问题还是须要解决的。并且是立马解决。否则错误会随着时间的推移解决成本也就越来越大。不要借口说如今没时间，等有时间了怎样怎样吧。如今没时间以后更没时间，由于以后仅仅会比方今更忙。
(什么？项目紧没时间，那么请跳槽，对于一个没有规划急功近利的公司是须要被社会淘汰的，所以你的不离职就是在姑息整个软件行业的不良风气)
Review初期是能够避免非常多低级错误的，可是到了后期就流于形式了，由于一直负责review的负责人已经疲惫了。
况且非常多严重的bug并非review就能发现的，Review仅仅能找出显而易见的错误。
所以，
第一、负责review代码的人决不能固定，并且一份代码能够多人review
第二、不放过不论什么一个Bug，尤其是由于改动或者新用例带来的bug。这些bug后面就藏着不整洁的代码，须要整个团队耐心的将其挖掘出来解决掉。
都说高质量的代码须要高水平的开发人成员，事实上高质量的代码，需要的是关怀开发商
版权声明：本文博客原创文章，博客，未经同意，不得转载。