為什麼要 Code Review

軟體工程師開發一個功能後，常常會再被其它工程師數落，不管是能力多強的工程師寫的程式，還是會被後面接手的人罵，其中很大的原因就是不同的想法，與各人知識能力不同，我們如何靠 Code Review 來解決這種問題呢。

Code Review 就是請其它工程師大家一起評論自已寫的程式，把程式碼公開讓別人來檢查 / 優化 / 補強，評論的內容會因各人專長與想法的不同，而產生很多爭議，例如安全性專家會龜毛的要求修補任何有可能的小小漏洞，效能專家會盡可能的想提升程式 Performance。

透過 Code Review 可以讓不同專長的工程師，一起評論一段程式碼，並提出自已的看法，每個人可以從中學習到各種不同知識，漸漸的拉近每個人的能力與想法，一開始實作 Code Review 會花大量的時間，每個人都會用自已喜歡角度來看程式，當兩個人的意見有衝突的時候，就會出現筆戰，試圖挑戰對方的底線，但只要持之以恆，團隊成員的默契將越來越好，最後就能把每個人的能力與想法一起提高拉平，

Code Review 最怕是那種不下任何評論，但是心中滿滿抱怨不配合的人，這種人無法接受其它人的意見，又不願意跟別人溝通，每次寫程式都用自已的習慣，面對別人的評論總是講一點就修一點，沒完沒了，不思進步，如果團隊內有這種人會嚴重影響 Code Review 的進行。

良好的 Code Review

要做到良好的 Code Review 並不是這麼簡單的，大部分的人都是心胸狹窄、度量小，尤其是男性生物，本能就是要競爭，打敗身邊的所有人，要讓工程師接受別人的評論，承認自已寫的程式不好是很難的一件事，所以 Code Review 的時候，不要讓對方感受到他的程式不好。

• 看到程式有不正確的地方時，不要直接說對方寫錯了，改用間接 / 詢問的方式來提醒比較不傷人，例如 Code Review c 語言，發現對方忘了 initialize memory，不要直接寫 "你忘了 initialize memory."，而改用 "我找不到這個變數在哪裡 initialize memory? "。
• 不要強迫作者一定要修完所有的 Comment 才 Merge 程式，有些不影響系統的 Comment 可以下一次 PR 再一起修即可，這樣也能夠加快 Code Review 的過程。
• 給評論時不要攻擊對方。
• 公司內可以訂定程式準則，減少 Review 的爭議。
• 下評論時內容要清楚，明確，不要順便打幾個字，這樣會給人不尊重的感覺，而且會造成對方誤解你的意思，拉長 Review 過程。
• 因材施教，資深的工程師寫 Comment 時，內容必須是對方能力所能了解的，或是提供線上文件當參考，順便讓新人有自我學習的機會。
• 開一個新的 Pull Request 時，要盡可能的把為什麼要改這段程式的原因與方法，寫在 comments ，讓 Review 者可以更快速的了解程式，以及了解你的想法，就算是很基本的知識，建議也要寫出來，除非你很確定 Review 者很強，自已看得懂。
• 重覆的問題只要寫一次就好了，下評論的時候再註明請對方一並修改所有類似的問題，評論數太多會讓其它 Review 者覺得程式的問題很多，觀感不好，也會對作者心理有不好的影響。
• 資深工程師要能虛心接受資淺工程師寫的評論，用專業的態度來看評論。
• 當 Review 出現兩種意見，各有利弊的時候，應使用客觀的角度，用理論與數據來決定採用哪個方案，拿不出數據時，我個人建議採用曾經發生過的案例。