May 28th, 2013 by Mr. Friday

這是從團隊之美看到的問答：

問：為什麼多數人不喜歡作 Code Review ？

答：因為叫兩個人作同一件事聽起來很沒效率。

我在台灣的時候，必須很誠實的說我所在的團隊內彼此從來沒作過 code review，偶爾會作也只是因為別的團隊想改我們的程式送來 patch 所以要 review。問到為什麼不做？聽到的理由多半是：”我們的人力資源不夠（潛台詞：不像國外那麼多），所以沒有時間作 code review”。

妙的是，我後來在美國待過的 team，不論大小（有大到四十人，也有只三四個人），code review 根本是每次程式修改前的基本要求。如果有哪幾次沒有作，”Code Review Dashboard 當了” 多半是主因。

Code Review 之於生產力其實是個迷思。（團隊之美這本書也提到，多年前，很多老闆也尖叫著要把 QA 開除以 “提升生產力”）

Code Review 的好處在於：

• 多一雙眼睛在看你的程式碼，所以任何含 bug / hacky / hard code / non-scalable 的程式碼很容易在程式寫進去之前就被挑出來。這一點有點像是先行投資以減少日後修改的麻煩。
• 對於幫忙作 code review 的人，第一次看新功能程式碼會花比較多時間，但後續的修改 review 就會比較快。
• 多一個人了解程式碼，如果原開發者不在了至少還有另外一個人知道這是啥
• code review 多半是資深的 developer 帶領，在 review 過程中可以激發很多教學相長的討論。這是最好的在職訓練。

但反過來說，它也有缺陷：

• 團隊裡面要有人主動願意花時間作 review，不然大家看到 pull request 都逃開，最後沒有人可以把程式 check-in。
• Code Review 把關者的好壞差很多。如果這個人處處刁難吹毛求疵，又或者要求大家一定要照他的規範來寫，大家會盡量不送 review 而想辦法偷偷把程式 check-in，這反而是反效果。

所以，它要達到好的效果，跟團隊大小真的無關，團隊內的資深工程師到底夠不夠專業與合群其實才是決定性的因素。有好的工程師作 review，時間其實是節省的！

就我的認識， Code Review 是良好的團隊一定要實施的措施，而且是在 “每次程式修改前”。有一次我跟以前的朋友講，他回道：”如果是在我們團隊，老闆會說你有那麼多時間作 review，為什麼不直接去做下一個 project？”

我想這就是為什麼這個團隊的程式碼總是有著 “重量不重質”，”求快不求好” 的問題…