我的 Code Review 經驗談

圖片:via Sebastian [email protected]Flickr

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

問:為什麼多數人不喜歡作 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?”

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

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!
  • Jamie Sa

    今年的二月,我們小小的 Startup 完成了 1000 Pull Requests (Github Style),這一種文化上的改變,Team Member 彼此瞭解對方 Coding 的個性長短處。如果要好好推動,還是要有好的工具,Github 的 PR 就非常的優秀。

    Code Review 其實會節省整體專案的時間!

  • Allen Lin

    比起pull request還需要單以code來理解原作者意思,
    而且還得等review才能被merge在一起,
    pair programming會不會比較有效率呢?