一个团队中经常会充满了这样的争吵：

　　“你这个test写得太复杂，我看不懂，建议重写!”

　　“我不觉得复杂啊，是你看得不仔细”

　　“你这个函数写得太大，test肯定无法cover所有分支!重写!”

　　“靠，我已经用客户端测试过了，没有问题“

　　”客户端测试通过，但是test没有cover所有分支，这是不行的，难道每次修改这里都用客户端来测试这个函数有没有问题吗?这样代价很大，最后会导致无法修改!!“

　　”我test写那么完备，代码都无法按时提交了，这个责任谁来负担?“

　　”你test不写完备，代码耦合性太高，下次这块代码出了问题，责任你负担的起吗?“

　　……

　　……

　　两人为此时吵了半天，最后吵到了项目经理那去了。项目经理一般有三种做法：

　　2B项目经理：”我不懂技术，你们自己商量决定。不要耽误进度啊“

　　普通项目经理：”test要写完备，把test补全吧。“。写代码者不服，说出了种种理由。项目经理又和他辩论半天，实在无法说服，最后项目经理怒了：”我怎么说你就怎么做!“

　　优秀项目经理：”test要写完备，一定要补全test“。说完之后就在项目review规则上补充三条规则：

　　1. test必须cover所有分支

　　2. test写得如果reviewer无法短时间看懂，需要重写。如果他人代码导致自己写的test失败，需要写test的人自己去修复，解除耦合性

　　3. 代码质量重于进度，质量不好在项目后期会导致致命后果，不得以进度为借口放弃质量。

　　并且加上为什么这样规定的原因，之后，项目经理在代码提交流程上添加了代码测试覆盖率检查工具，没有达到覆盖率无法提交到git

　　第一种项目经理是无为而治。看上去是个好好先生，事实上是个吃闲饭的。看上去对每个人都好言好语，事实上对整个项目没有一点作用。一天到晚就是催进度。最后很有可能就是因为之前test写得不完整导致代码无法修改拖慢了进度，但是这种项目经理才不会管你呢，谁进度慢了，就是谁的责任。

　　第二种项目经理是人治。整体管理思路都对，个人权利无限大，但是无法让手下信服。有可能导致整天处于这种问题的纠缠之中。手下的质疑声不断，最后感觉自己管不了了。

　　第三种项目经理是法治。逐步完善项目管理中的各种问题。法律不全则修补漏斗，大家都有法可依，最后整个项目组走的路越来越顺畅，开发速度越来越快。