相信，在一个项目团队中经常会听到这样的争吵：
“你这个test写得太复杂，我看不懂，建议重写！”
“我不觉得复杂啊，是你看得不仔细”
“你这个函数写得太大，test肯定无法cover所有分支！重写！”
“靠，我已经用客户端测试过了，没有问题。”
“客户端测试通过，但是test没有cover所有分支，这是不行的，难道每次修改这里都用客户端来测试这个函数有没有问题吗？这样代价很大，最后会导致无法修改！！”
“我test写那么完备，代码都无法按时提交了，这个责任谁来负担？”
“你test不写完备，代码耦合性太高，下次这块代码出了问题，责任你负担的起吗？“
……
两人为此时吵了半天，最后吵到了项目经理那去了。项目经理一般有三种做法：
2B项目经理：我不懂技术，你们自己商量决定。不要耽误进度啊
普通项目经理：test要写完备，把test补全吧。
写代码者不服，说出了种种理由。项目经理又和他辩论半天，实在无法说服，最后项目经理怒了：我怎么说你就怎么做！
优秀项目经理：test要写完备，一定要补全test。说完之后就在项目review规则上补充三条规则：
1. test必须cover所有分支
2. test写得如果reviewer无法短时间看懂，需要重写。如果他人代码导致自己写的test失败，需要写test的人自己去修复，解除耦合性
3. 代码质量重于进度，质量不好在项目后期会导致致命后果，不得以进度为借口放弃质量。
并且加上为什么这样规定的原因，之后，项目经理在代码提交流程上添加了代码测试覆盖率检查工具，没有达到覆盖率无法提交到git
第一种项目经理是无为而治。看上去是个好好先生，事实上是个吃闲饭的。看上去对每个人都好言好语，事实上对整个项目没有一点作用。一天到晚就是催进度。最后很有可能就是因为之前test写得不完整导致代码无法修改拖慢了进度，但是这种项目经理才不会管你呢，谁进度慢了，就是谁的责任。
第二种项目经理是人治。整体管理思路都对，个人权利无限大，但是无法让手下信服。有可能导致整天处于这种问题的纠缠之中。手下的质疑声不断，最后感觉自己管不了了。
第三种项目经理是法治。逐步完善项目管理中的各种问题。法律不全则修补漏斗，大家都有法可依，最后整个项目组走的路越来越顺畅，开发速度越来越快。