劇透警告：如果你喜歡合理的架構決策，而討厭成為“關鍵路徑”開發者（"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!) 編譯者：程景天。