2018
Apr
19

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

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

透過 Code Review 可以讓不同專長的工程師,一起評論一段程式碼,並提出自已的看法,每個人可以從中學習到各種不同知識,漸漸的拉近每個人的能力與想法,一開始實作 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 出現兩種意見,各有利弊的時候,應使用客觀的角度,用理論與數據來決定採用哪個方案,拿不出數據時,我個人建議採用曾經發生過的案例。

回應 (Leave a comment)