如何做到正向循環的 Code Review ?

其實不少大神都有寫過如何進行 Code review 或類似的文章,不過我還是想藉著自身的經驗總結一遍。 通常會需要你 Code review 就代表你對 Codebase 或者程式設計的功力已經有相當程度的熟悉了(是的,能力越大,責任越大)!

但是 Code review 並不是霹哩啪拉給個幾條意見,然後就打完收工的事,歸根究底它多少還是牽扯人際關係的互動,這就是程式設計師的江湖。

闖江湖不免要來幾條規矩:

  • 開宗明義,用批評摧毀團隊很快很簡單,但是團隊要建立互信與默契卻是需要長期的經營
  • Code review 要具備同理心、Code review 要具備同理心、Code review 要具備同理心!別人也是花時間寫的程式碼,初衷也是想要達成規定的功能與目標,沒有人想被批抨得一文不值,你們都是為了產品好,只是想法與做法不同而已,請用實質的建議取代批評
  • 內心要認知一件事——「 PR 的作者對規格/程式碼相關情境的了解,應該在 Reviewer 之上」,也就是說作者對於程式碼中存在的缺點以及妥協應該都相當了解,如果有覺得奇怪的地方,可以先詢問作者是否有任何考量,再進行後續討論
  • Code review 不是把別人的 PR(Pull Request) 變成你喜歡的樣子,也不是炫耀火力,千萬別不順眼就拔刀拔槍要相殺, Code review 的目的在於:
    1. 讓經驗可以透過互動方式在成員間流轉
    2. 避免致命錯誤被送到 Production 造成團隊困擾(人人都想開開心心上班,準準時時下班)
    3. 維持 Codebase 一定程度的整潔,避免大家像在玩疊疊樂,誰倒楣誰當壓垮疊疊樂的最後 1 根積木
  • Code review 如果有爭執,請用數據說明,譬如效能不好的地方請用 profiling 說服作者,或者有 best practices 也請提供文件或出處,給彼此 1 個教學相長的機會
  • Comment 的文字會容易被誤解情緒,你可能文字表達沒有任何情緒,但是讀者容易誤解其中情緒,最好的方法是雙方可以再 face to face 快速講解 1 遍(有默契之後,幾乎就可以不需要這步驟),或者善用 emoji 輔助表達文字情緒,避免被誤解
  • Code review 留的 comment 可以加上標籤表達是建議還是要求,例如 [Optional] , [Suggestion] , [FYI] , 因為有些無傷大雅的更動可以讓作者在趕時間的情況下先忽略(而且作者本來就沒有義務接受所有不合理的要求⋯⋯)
  • 別吝嗇給稱讚,看到好的地方請大方留下稱讚,稱讚可以給人帶來自信,激發更多創意,好稱讚,不稱讚嗎?

基本上,只要做到這些應該就能夠來一場溫馨快樂又有內容的 Code Review 囉!

一起成為人人都喜歡的 Reviewer 吧~!😎

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

追蹤新知

看完這篇文章了嗎?還意猶未盡的話,追蹤粉絲專頁吧!

我們每天至少分享 1 篇文章/新聞或者實用的軟體/工具,讓你輕鬆增廣見聞提升專業能力!如果你喜歡我們的文章,或是想了解更多特定主題的教學,歡迎到我們的粉絲專頁按讚、留言讓我們知道。你的鼓勵,是我們的原力!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!