6 個實用的 Code Review 實踐技巧
你為了完成任務瘋狂地敲了三周代碼；
你將一個包含大約 1000 行新代碼的 Pull Request 提交評審；
你收到兩條關于 code style 的評論，以及一個關于評審人表示他看不懂這些代碼用途的問題；
你修復 code style 并回答評審人的問題，然后評審人通過你寫的代碼；
你把代碼分支合并到 Master，雙眼緊閉，緊握著拳頭，緊咬牙關等待著結果。幾分鐘后，CI 完成。幸好，Master 沒有崩潰。然而…
此后 6 個月，你一直戰(zhàn)戰(zhàn)兢兢，不知道代碼何時會崩潰，以及以什么方式崩潰。
評審人心理上更容易接受開始和完成一小塊代碼的評審工作。更大的 PR 自然會讓評審人推遲和拖延評審，并且在評審過程中被打斷的可能性更大。
作為一名評審人，如果 PR 太長，就很難深入進去。要檢查的代碼越多，我們越需要耗費更多腦力來理解整個代碼塊。
用戶要你造一輛車；
6 個月后，你造了一輛漂亮的保時捷；
你向用戶展示這輛車后，他們問你這輛車能不能放得下他們的 5 個孩子和沖浪板。
更獨立的評審單元，這意味著更好的審查質量；
受影響的人更少，因此可以聚集在更少的幾個專業(yè)領域中；
原子性回滾，可以回滾小的 commit 或 PR。這是很有價值的，因為如果出了問題，就更容易確定錯誤是在哪里引入的，以及回滾哪些部分。
將易事和難事分開。假設有一個新特性，需要重構一個頻繁使用的 API。你可以更改這個 API，升級十幾個調用的站點，然后實現(xiàn)這個特性。你的變更中有 80% 不是功能上的變更，明顯可以忽略掉，而 20% 是需要仔細注意測試覆蓋率、預期行為、錯誤處理等等的新代碼，并且可能要經(jīng)過多次修訂。對于每一個修訂，評審人都需要瀏覽所有的修改以找到相關的部分。通過將其分成兩個 PR，很容易就可以快速完成大部分工作，并優(yōu)化評審工作，將主要精力投入到難點上。
將 PR 分解成單獨的關注點評審人可以這樣想：“這是我們自己的代碼，我們該如何改進它呢？”
提出肯定意見！如果你看到有些代碼部分寫得不錯，就加條評論表揚一下。這能讓代碼作者繼續(xù)保持好的一面，并有助于他在心理上更容易接受改進建議。
代碼作者不妨這么想，評審人的出發(fā)點肯定是好的，不要將評論當作是對個人的批評。
下表列出了一些存在不足的評審反饋，以及如何按以上建議進行重寫的建議。
誰具備你正在構建的特性或組件的上下文？
誰精通你正在使用的語言、框架或工具？
誰對這一主題知之甚深，有自己的理解？
誰關心你所寫代碼的結果？
誰應該學習這些東西？或者，如果你是一名正在評審“老鳥的菜鳥程序員”，不妨抓住這個機會多多提問學習。別怕你的問題太幼稚，一個強大的團隊會找時間來分享知識。
為什么這個 PR 是必要的？
誰會從中受益？
可能會出什么問題？
你還考慮過其他方法嗎？你為什么決定采用這種方法？
這對其他系統(tǒng)有什么影響?
團隊將達成共識。團隊會更了解你的工作，除你之外，其他團隊成員可以完善代碼庫的這一部分。
團隊將共同承擔責任。如果出現(xiàn)問題，不只是某個人的代碼需要修復，而是整個團隊的代碼都需要修復。
最近熱文
? ?朋友入職中軟一個月（外包華為）就離職了！ ???川大 NLP 博士生被華為以 200 萬年薪錄用！分享以下科研及論文寫作經(jīng)驗... ???程序員因接外包被判坐牢 456 天！兩萬字長文揭露心酸真實經(jīng)歷... ???為什么很多公司都不招大齡碼農？ 最近整理了一份大廠算法刷題指南，包括一些刷題技巧，在知乎上已經(jīng)有上萬贊。同時還整理了一份6000頁面試筆記。關注下面公眾號，在公眾號內回復「刷題」，即可免費獲?。?span style="letter-spacing: 0.544px;-webkit-tap-highlight-color: rgba(0, 0, 0, 0);font-weight: bolder;">回復「加群」，可以邀請你加入讀者群！
明天見(??ω??)??