關注、星標嵌入式客棧，精彩及時送達
代碼爲什麼要review?
以爲代碼比較少bug，其實是這樣的畫風：
如果代碼前期不提高質量，程序猿後期就可能會有這樣酸爽的體驗：
所以爲神馬要對項目代碼做代碼評審（code review）呢？一方面，直接原因是可以提高代碼質量，將bug在開發過程中，測試前就給它揪出來；另一方面，團隊協同作戰，制定的代碼規範怎麼實施下去呢？code review也將是一個很好的措施，可以漸進的形成統一的編碼風格，提升團隊協同開發整體作戰水平，並對於形成協同互動的團隊文化產生積極促進作用。why？
激勵認可，代碼提交者提交一系列的代碼交由審閱者審查（review），審閱者常由同事擔任或者更資深的攻城獅擔當，審查過程中不免有可圈可點之處被肯定；也有缺陷漏洞被識別，在肯定的方面必然會激勵代碼作者，被指出疏漏之處，必然能有機會堵住疏漏，降低後期查錯的成本。對於大多數同學而言，獲得前輩認可必然會被激勵，獲得指點，必然有助進益！
團隊建設，知識技能的分享交流可以幫助團隊：
code review可以識別待改進項或者未完善或完成的任務，團隊成員隨後可以在已完成的工作基礎上進行漸進迭代開發。
提交者可能會使用一種技術或算法，評審員可以從中學習獲益。更爲重要的是，代碼審查有助於漸進提高整個團隊的代碼質量標準。因爲審查過程中，就一個點會進行深度剖析，思想碰撞，所謂不辯不明。經過良好的長期的代碼審查機制，團隊的整體認知將會漸進提高！
積極良好的互動交流將有助於構建良好的團隊文化
風格一致性：code review將有助於形成統一的代碼風格，這是技術管理的一個重要維度。代碼風格的一致性，也將有助於減少bug，提升協同開發能力，提升代碼的可讀性以及可維護性。爲啥能提升協同開發能力？如果代碼風格各異，比如一個項目多人並行開發，各是各的代碼風格，你想象一下拼裝集成起來是多麼痛苦吧？一旦發現有bug，解bug又會是多麼痛苦。
可讀性識別，所謂當局者迷，旁觀者清，代碼片段的可讀性對於作者本人來說很難判斷，而對於沒有完整上下文的閱讀人員來說則很容易感知。可讀性高的代碼更容易重用，總體上來說bug會少些。
錯誤識別，不經意錯誤（例如，打字錯誤）或結構錯誤（例如，死代碼，邏輯或算法錯誤，性能或架構問題）通常更容易被審閱代碼人員從旁觀的角度發現。即使是簡短而非正式的代碼審查，也會對代碼質量和錯誤率產生較大影響。
合規性需求，比如在特定的行業，醫療、工業、汽車領域，代碼審查是開發流程中強制要求的環節，比如功能安全認證，醫療器械認證法規體系，汽車電子等都明確要求需要進行代碼審查並出具審查報告。
都Review些啥呢？
具體要Review哪些內容呢？這個問題貌似永遠沒有絕對正確的答案，每個開發團隊都應該對自己的方法達成一致。所謂達成一致，團隊成員需要一起制定代碼規則以及Review的checklist（檢查項列表），切忌由某一個人制定規則：
難免片面偏頗，即便是前輩大牛，也不能保證所有的理解都是完善正確的
需要團隊align認同，否則難以實施，尤其團隊成員水平相差不多，氛圍文化還沒有很好形成時，不免出現誰也不服誰的情形。
規則還可以協同漸進完善，但一定要是可實施的，而不是流於形式。
代碼評審是需要無差別化，要一視同仁，即便是團隊中最資深的人也並不意味着他的代碼不需要評審。即使在極少數情況下代碼是無瑕疵的，審查也提供了一個指導和協作的機會，並且加深團隊對代碼的理解。
具體實施可從兩個方面着手：
團隊協同定義代碼規範，當然如果已有規範，需要對新人進行培訓。代碼規範沒有絕對標準答案，只是爲了建立一套成員都認可的代碼風格以及習慣。
團隊協同定義審查項列表，每個成員都可能是作者也可能是審查員，一方面在寫代碼時，就有了一把尺去度量，在審查時也有一個尺去檢驗。
對於審查項，比如可定義下面類似的規則：
檢查通過引用傳遞的參數是否正確使用？
檢查對於應實現返回的分支是否都實現了顯式返回？
檢查函數是否清晰易理解？
檢查類型轉換是否正確？
........
啥時候Review?
代碼審查應該在自動檢查（單元測試、代碼風格、持續集成構建）成功完成之後進行，但是應該在代碼合併到代碼庫的主幹（或者叫mainline或者叫trunk）分支之前進行。
單元測試，相信做過的朋友應該會有體會，有效的單元測試將提前識別出bug
代碼風格，主要是指代碼的樣式，比如縮進，花括號的寫法，很多編輯器能幫助自動完成。比如IAR，比如Clang-Format，visual code的ident插件等。
持續集成，比如有很多公司會使用Jenkins搭建一個自動構建平臺，藉助這個平臺可以實施自動集成編譯、自動運行單元測試、自動運行代碼靜態檢查等。
爲什麼要在這些自動檢查成功之後才Review？因爲這幾個過程都有可能發現問題，並觸發修改代碼，所以Rview一個相對穩定的版本將會減少重複Review的工作量，節約時間。那麼爲什麼要在合併到主幹之前審查呢？這顯然比較好理解，因爲這樣可以儘量將高質量穩定的版本或者功能合併進主幹，可以保證主幹的相對穩定以及質量。
該怎麼Review呢?
發起Review的代碼提交者，需要提前做好準備工作，從而提高效率，以減少浪費其他參與人員的時間：
明確範圍：待審查變更應具有明確範，成體系的範圍。例如，這筆更改實現新功能或修復的錯誤。較短的更改優先於較長的更改。對於一個涵蓋多項需求用例的更改，比較好的做法是拆分成多次review，或者組織review時儘量條理清晰，做些分門別類的前期準備，以方便審查，提高效率。
僅提交完整且經過自我審查（比如利用版本管理工具的diff進行）和經過單元測試的代碼。爲了節省審閱者的時間，比較好的做法是在發送審閱者之前測試提交的更改（比如前面談到的完成靜態代碼檢查、單元測試、代碼風格），並確保它們通過本地和持續集成服務器上的所有內部版本以及所有測試和代碼質量檢查。
代碼樣式提前整理好，人工審查需要消耗其他人的時間，代價可謂昂貴，所以應聚焦到程序邏輯上，而非樣式，語法或格式的爭辯上。更好的辦法是採用工具自動完成，比如Clang-Format等自動工具來解決這些問題。
具體Review時，有哪些值得推薦的做法呢？
要針對代碼不要針對作者，忌攻擊作者，否則影響士氣，不建議管理者將代碼審查缺陷當作績效考覈指標。
要開放不要保守，沒有人寫出絕對完美的代碼，助人亦是助己，建立良好的代碼審查文化，以積極看待發現的缺陷。
要識別缺陷不要修復缺陷
要高效不要拖沓，不宜超過2小時
要合理節奏不要太快或太慢
要聚焦邏輯而非形式，如前面所說，不要浪費時間在語法、格式等主題
要追溯跟蹤、落地實操不要形式套路，否則不如不做。對於識別出的問題，應逐一反饋關閉。
建議採用輔助工具進行審查
審查代碼前，作者應準備必要的註釋或者代碼解釋，以提高審查效率。
一次查看代碼儘量控制在200-400行，太多則不易識別出問題
團隊協同制定審查清單，並一致認同
總結一下
良好的代碼審查機制，將有助於提升代碼質量、減少產品缺陷、降低開發成本，同時也有助於持續提升團隊凝聚力、建立更好的團隊協作文化、提升整體的作戰能力。而形式化的代碼審查，則將浪費成本、影響士氣。至後臺發送CR，領取checklist
本文辛苦原創，如喜歡請點贊/在看/分享支持，不勝感激！
—END—
往期精彩推薦，點擊即可閱讀
