為什么代碼評審（code reviews）很重要
劇透警告：如果你喜歡合理的架構決策，而討厭成為“關鍵路徑”開發者（"critical path" developer），你會喜歡上代碼評審的。
敏捷團隊是自組織的，擁有跨越團隊的技能集。這在一定程度上是通過代碼評審實現的。代碼評審可以幫助開發人員學習代碼庫，並幫助他們學習新的技術，從而提高他們的技能。
「CODING 企業版」作為企業級軟件研發管理系統，助力團隊敏捷開發轉型升級。
那么，到底什么是代碼評審（code reviews）呢？
當開發人員完成一項工作時，另一個開發人員會查看代碼並考慮如下問題：
- 在代碼中是否存在明顯的邏輯錯誤？
- 查看需求，是否所有用例都實現了？
- 新的自動化測試是否足以滿足新代碼？
- 是否需要重新編寫現有的自動化測試用例來應對代碼的變化？
- 新代碼是否符合現有的開發規范？
代碼評審應該與團隊的現有流程集成。例如，如果一個團隊正在使用任務分支工作流，那么在所有代碼編寫完成並通過自動化測試之后，在代碼合並之前，就會啟動代碼評審。這確保了代碼評審人員的時間被用來檢查機器遺漏的東西，並防止糟糕的編碼決策污染開發主線。
代碼評審對於敏捷團隊來說有什么作用呢？
無論開發方法如何，每個團隊都可以從代碼評審中獲益，敏捷團隊更是能獲得巨大的好處。因為團隊的工作是分散的，通過代碼評審可以做到沒有人是唯一知道代碼庫特定部分的人。簡單地說，代碼評審有助於促進跨代碼庫和整個團隊的知識共享。
代碼評審共享知識
所有敏捷團隊的核心都是戰無不勝的靈活性：一種將工作從待辦事項列表中划掉並由所有團隊成員開始執行的能力。因此，團隊能夠更好地圍繞新工作進行展開，沒有人是“關鍵路徑”。全棧工程師可以處理前端工作和服務器端工作。
隨着代碼評審使開發人員接觸到新的想法和技術，他們會編寫出更好的代碼。
通過代碼評審可以更好的進行工作評估
還記得評估的那一節嗎？評估是一項團隊練習，當產品知識在團隊中傳播時，團隊會做出更好的評估。隨着新特性被添加到現有代碼中，原開發人員可以提供良好的反饋和評估。此外，任何代碼評審人員也會綜合考慮代碼庫的復雜性、已知的關注的問題。通過這種方式代碼評審員分享了代碼庫中那個部分的原開發人員的知識。這種實踐使得產品知識有多人了解，當大家做最終評估時，通常會使評估更加可靠。
代碼評審能讓你享受休假
沒有人喜歡成為一段代碼的唯一聯系人。同樣地，沒有人願意鑽研不是他自己寫的關鍵代碼——尤其是在生產環境有緊急情況發生時。代碼評審在整個團隊中共享知識，這樣任何團隊成員都可以接管並繼續領航這艘大船。（我們喜歡在 Atlassian 進行這樣的比喻！）但這里的重點是：沒有任何一個開發人員是關鍵路徑，這也意味着團隊成員可以根據需要休假。如果你發現自己在產品開發中忙的焦頭爛額時，代碼評審是一種很好的方式讓你獲得自由。自由地去享受個假期，或者自由地去看看產品其他領域的事情。
通過代碼評審指導新工程師
敏捷開發的一個特點是當新成員加入團隊時，經驗豐富的工程師會指導新成員。代碼評審有助於促進關於代碼庫的溝通。通常，團隊在代碼評審期間的代碼中隱藏了產品知識。新成員帶着新鮮的眼光，從新視角來審查代碼庫的粗糙之處和歷史遺留缺陷的地方。因此，代碼評審也有助於確保新見解與現有知識相調和。
專業提示：請記住，代碼評審不僅僅是高級團隊成員評審初級團隊成員的代碼。代碼評審應該在各個方向上進行。知識是沒有界限的！代碼評審可以幫助新加入的工程師，但絕不應該僅僅作為一種指導練習。
在“上古”時代，代碼作者在開始 Code Review 前，還需要手動做一份變更列表（changelist），來告訴評審者這一次提交做了什么改動。得益於 Git 的誕生，今天的我們可以借助基於 Git 版本控制系統的平台，來更輕松無痛地開展代碼審閱，比如「CODING 企業版」，作為企業級軟件研發管理系統，其提供的 Code Review 功能簡單好用，能大大提高代碼審閱效率：
借助 Git 自動實現精細的文件改動，紅色代表刪減，綠色代表新增，支持行級評論，再也不用在不同工位間來回走動，直接在具體代碼下進行交流。
長遠來看，代碼評審可以節省時間
代碼評審確實有點耗時，但是“做評審所花費的時間”不會比“不做評審所浪費的時間”多到哪里去。
只要執行得好，從長遠來看，代碼評審是可以節省團隊時間的。原因有如下三點：
- 代碼評審可以分擔任務負擔
很多 Atlassian 的團隊，需要對任何代碼進行雙重評審才能合並到代碼庫上去。聽起來是不是有點額外增加工作負擔了？但實際上不會。當代碼作者遞交評審時，是遞交給整個團隊的。任何工程師都可以加入評審。這使得任務負擔可以被分擔，從而可以防止“一項工作耽擱影響總體進度”的情況發生。也可以保證團隊代碼評審的質量。
- 代碼評審可以把軟件bug扼殺在搖籃里
把代碼評審作為提交代碼前的必要工序去執行，可以讓很多問題（例如熬夜做了不靠譜的架構決策、實習生用了不合理的設計模式）在軟件最終發布前就被發現。
- 代碼評審可以提高工作質量
當一個工程師知道自己的代碼會被同事審閱時，他會傾向於付出更多努力來讓自己的程序設計變得足夠優雅、讓自己的代碼能順利通過全部測試。工程師們有了這個上進意識，最終也可以讓整個項目變得更加順暢、有效。
在開發周期里，如果急着得到反饋，那就不要等代碼評審給出意見。提前得到反饋，往往會產出更好的代碼。因此，無論何時，都不要羞於讓別人提意見。這會提高你后續的工作質量，也會提高整個團隊的代碼評審能力。從而讓開發團隊進入正循環。
「CODING 企業版」作為企業級軟件研發管理系統，任務看板功能實現了 Epic \ user stories \ Sprint 等敏捷概念落地。
本文中文翻譯自原文：Why code reviews matter (and actually save time!)
編譯者：程景天。