我們很多人都以為CodeReview不重要，因為其他人寫的程式碼和自己的關係可能不是太大，review的時候也不會上心，但事實上這個想法大錯特錯。CodeReview和我們的日常開發息息相關，缺少了它，那你的專案就是不完整的了。本文作者Yezhiwei，我做了一些適當補充。

背景

關於CodeReview的一些思考

上圖為[產品迭代開發協作流程]，其中我們在 Demo 本次迭代之前會對開發人員的程式碼進行評審，所以今天就聊一下關於CodeReview的一些思考。

Code Review 的主要目標

Code Review，也就是我們常說的程式碼評審。Code Review 主要是在軟體開發的過程中，對原始碼進行評審，其目的是找出並修正軟體開發過程中出現的錯誤，保證軟體質量，同時也能提高開發者自身水平。
程式碼寫不好，可能是對業務不瞭解，對程式語言不熟悉，也可能對公司程式碼整體架構不熟悉，我們要找到原因並提出改進的解決方案。
正視 Code Review，不僅僅是過一個流程，而是能從中學習到些什麼。
備份，多一兩個人熟悉這塊業務程式碼，避免最初的開發者休假等情況發生時，沒有人能頂上來。

Code Review 帶來哪些好處

從開發者的角度來看

開發工程師需要按合理的邏輯化分，分模組從原始需求，然後是方案，最後是程式碼實現的進行講解。
這個過程需要的能力：對需求的理解（有助於合理化分功能）；表達能力，怎麼說才能讓評審的同學聽懂你傳遞的資訊；邏輯能力，是否有明的邏輯錯誤；心理壓力承受能力，隨時會有同學進行提問；
作為開發者要時刻提醒自己，程式碼不僅是給機器讀，還是要給人看的，所以程式碼的可讀性也要考量，提交程式碼的資訊是否寫得非常清楚、合理。想想什麼樣的程式碼最想讓你罵娘？哈哈... 愛美之心，人皆有之。漂亮的程式碼，也是我們的追求，它不僅能夠完成要求的功能，而且還要整齊，有條理，易於理解。
分享在這次需求開發過程中運用到的高階技術或一些奇淫巧技。
程式碼被 Code Review 後，評審者也相當於參與了這次開發，相當於“備份”，當你休假或正在忙別的需求的時候，這時“備份”就能幫上你的忙了。
對開發者的一個要求，大家統一程式碼風格，方便後期的維護。不推薦使用開發工具的自動格式化，手動調整會更好些，也能避免程式碼衝突。

從評審者的角度來看

稽核的粒度要多細？每次評審花多少時間？具體哪些地方需要評審？

程式碼格式方面：大家約定俗成，避免公司的程式碼風格不一致，新同學在這方面不太熟悉，就有可能出問題，但這類問題比較容易解決。
程式碼可讀性方面：方法不要太長；變數名、方法名要能說明它的使用者和型別；不要有巢狀太多層的條件語句或迴圈語句；迴圈語句中避免呼叫遠端服務或比較耗時的方法；如果不可避免有一些註釋，一定要保證註釋準確且與程式碼完全一致。
業務邊界和邏輯問題：思考一下有沒有漏掉任何業務邊界和邏輯問題。對現有業務是否有影響等。
錯誤處理：有沒有對引數驗證？遠端呼叫超時或服務不可用時，有沒有預設的補救錯誤？資料庫儲存出錯有哪些影響？
程式碼質量和規範：遵循公司的程式設計規範，如：有重複程式碼段，就應該提取出來公用；不要在程式碼裡隨意設定常數，所有的常數應該在頂部統一定義或有專業的類；哪些變數是私有的、哪些是公有的，等等。
程式碼架構：包的組織方式，是否和程式碼庫的風格一致，API 的定義是否 RESTful 等等。

評審者能學到什麼？

深入瞭解需求及全域性的資訊架構。
鍛鍊了自己的邏輯思維。
學習開發者的一些奇淫巧技。
即使沒有參與具體的程式碼開發，但是可以一起與開發者背鍋了，哈哈。

從參與者的角度來看

參考者有哪些收穫呢？

理論上也應該和評審者沒有任何區別。

但是，如果心態和情緒不對的話，可能會變成下面的情況了：

有了瞭解需求及全域性的資訊架構機會。
學習開發者的一些奇淫巧技的機會。
可能有了一段帶薪刷手機的時間機會，哈哈。

總之，還是看心態，如果在你心中覺得只是一個流程、混個過場，或者帶著情緒來做這件事，可能也只能收穫這些“機會”，沒有達到期望的效果。

Code Review 推薦流程

程式碼提交

我們現在用的 gitLab 的程式碼倉庫，在每次提交程式碼的時候，要說明清楚提交的程式碼到底是什麼功能，方便有針對性的程式碼稽核，一般程式碼提交分四類：

bug 修復，一般需要關聯 bug 系統裡對應的編號
程式碼最佳化，如重構、移動、拆分方法等
新功能開發，一般會和需求文件、設計方案關聯
系統遷移，如拆分出更多的專案，分別提交到程式碼庫

發出合併請求，而不是直接合並程式碼

可以利用 gitflow 中每個分支的生命週期和使用規範，Meger Request 是一次程式碼提交請求，提交後，其他工程師可以在這次請求中提出修改建議，也可以針對某一些程式碼的發動進行討論或是整體的評價。

Code Review 形式

一般來說Code Review的形式有下面兩種：

線上
線下

有部分公司都會採用線上，線上的方式更符合開源社群的review的方式，大家透過線上的一些comment和reply來進行交流溝通，這樣所有的review其實都有記錄可查，但這樣會導致一個問題，就是有人比較忙的時候可能就比較敷衍直接就進approve了。

有些公司也會採用線下，線下的方式屬於集中式，學習式的review，很多時候這種模式也可以看做一次技術分享，不僅是被review的人的分享，review程式碼的人也可以將自己過去的經驗，分享給其他同學，讓大家以後都儘量避免同一個問題或者都用這種方式進行最佳化，並且集中式的話，大家在一個會議室精力都比較集中，review的質量也較高。但是這種有點不好的是review會佔用大量的時間，如果平時本來開會就多，開發時間就少，再來幾次review，那不想996也難呀。

有哪些收穫？

提高了程式碼質量，知道自己的程式碼會被別人評審之後會寫得比較認真。
bug 數量減少，經過各個環節的評審，目的就是避免程式碼返工和 bug 生產，有的是帶薪寫 bug 哈哈。。
團隊成員對整個專案的熟悉程度會比較均衡，程式碼不會只有當初的開發者瞭解，Code Review 後所有的參與都能修改 bug，增加新功能。
避免人員單點風險。
每個成員都可以稽核別人的程式碼，多溝通、營造團隊的技術氛圍。