檔案狀態:    住戶編號:3390330
 amanda 的日記本
快速選單
到我的日記本
看他的最新日記
加入我的收藏
瀏覽我的收藏
觀察工作性格 助同仁發揮潛能 《前一篇 回她的日記本 後一篇》 工作環境品質評估
 切換閱讀模式  回應  給他日記貼紙   給他愛的鼓勵  檢舉
篇名: Code Review
作者: amanda 日期: 2013.09.17  天氣:  心情:
http://mmdays.com/2013/05/28/my-codereview-exp/


我的 Code Review 經驗談
May 28th, 2013 by Mr. Friday


圖片:via Sebastian Bergmann@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?”

我想這就是為什麼這個團隊的程式碼總是有著 “重量不重質”,”求快不求好” 的問題…
標籤:
瀏覽次數:58    人氣指數:58    累積鼓勵:0
 切換閱讀模式  回應  給他日記貼紙   給他愛的鼓勵 檢舉
給本文愛的鼓勵:  最新愛的鼓勵
觀察工作性格 助同仁發揮潛能 《前一篇 回她的日記本 後一篇》 工作環境品質評估
 
給我們一個讚!