相信，在一個項目團(tuán)隊中經(jīng)常會聽到這樣的爭吵：
“你這個test寫得太復(fù)雜，我看不懂，建議重寫！”
“我不覺得復(fù)雜啊，是你看得不仔細(xì)”
“你這個函數(shù)寫得太大，test肯定無法cover所有分支！重寫！”
“靠，我已經(jīng)用客戶端測試過了，沒有問題。”
“客戶端測試通過，但是test沒有cover所有分支，這是不行的，難道每次修改這里都用客戶端來測試這個函數(shù)有沒有問題嗎？這樣代價很大，最后會導(dǎo)致無法修改??！”
“我test寫那么完備，代碼都無法按時提交了，這個責(zé)任誰來負(fù)擔(dān)？”
“你test不寫完備，代碼耦合性太高，下次這塊代碼出了問題，責(zé)任你負(fù)擔(dān)的起嗎？“
……
兩人為此時吵了半天，最后吵到了項目經(jīng)理那去了。項目經(jīng)理一般有三種做法：
2B項目經(jīng)理：我不懂技術(shù)，你們自己商量決定。不要耽誤進(jìn)度啊
普通項目經(jīng)理：test要寫完備，把test補全吧。
寫代碼者不服，說出了種種理由。項目經(jīng)理又和他辯論半天，實在無法說服，最后項目經(jīng)理怒了：我怎么說你就怎么做！
優(yōu)秀項目經(jīng)理：test要寫完備，一定要補全test。說完之后就在項目review規(guī)則上補充三條規(guī)則：
1. test必須cover所有分支
2. test寫得如果reviewer無法短時間看懂，需要重寫。如果他人代碼導(dǎo)致自己寫的test失敗，需要寫test的人自己去修復(fù)，解除耦合性
3. 代碼質(zhì)量重于進(jìn)度，質(zhì)量不好在項目后期會導(dǎo)致致命后果，不得以進(jìn)度為借口放棄質(zhì)量。
并且加上為什么這樣規(guī)定的原因，之后，項目經(jīng)理在代碼提交流程上添加了代碼測試覆蓋率檢查工具，沒有達(dá)到覆蓋率無法提交到git
第一種項目經(jīng)理是無為而治?？瓷先ナ莻€好好先生，事實上是個吃閑飯的。看上去對每個人都好言好語，事實上對整個項目沒有一點作用。一天到晚就是催進(jìn)度。最后很有可能就是因為之前test寫得不完整導(dǎo)致代碼無法修改拖慢了進(jìn)度，但是這種項目經(jīng)理才不會管你呢，誰進(jìn)度慢了，就是誰的責(zé)任。
第二種項目經(jīng)理是人治。整體管理思路都對，個人權(quán)利無限大，但是無法讓手下信服。有可能導(dǎo)致整天處于這種問題的糾纏之中。手下的質(zhì)疑聲不斷，最后感覺自己管不了了。
第三種項目經(jīng)理是法治。逐步完善項目管理中的各種問題。法律不全則修補漏斗，大家都有法可依，最后整個項目組走的路越來越順暢，開發(fā)速度越來越快。