精讀《如何作好 CodeReview》

1 引言

任何軟件都是協同開發的，因此 CodeReview 很是重要，它能夠幫助你減小代碼質量問題，提升開發效率，提高穩定性，同時還能保證軟件架構的穩定性，防止代碼結構被惡意破壞致使難以維護。

因此 CodeReview 機制是否健全是一個工程團隊可否長期健康發展的決定因素之一，此次咱們讀一篇關於 CodeReview 如何作得更好的文章： how-to-make-good-code-reviews-better。

2 概述 & 精讀

做者結合本身在 Uber、微軟的工做經歷介紹了本身對如何作好 CodeReview 的見解。

CodeReview 的覆蓋範圍

Good CodeReview 會檢查代碼的正確性、測試覆蓋率、功能變化、是否遵循代碼規範與最佳實踐、能夠指出一些較爲明顯的改進點，好比難以閱讀的寫法、未使用到變量、一些邊界問題、commit 數量過大須要拆分等等。

Better CodeReview 會檢查引入代碼的必要性，與已有系統是否適配，是否具備可維護性，從抽象角度思考代碼是否與已有系統邏輯可以自洽。

Better CodeReview 會關注在可維護性層面，並具備全局性，每每幾個局部正確的代碼組合在一塊兒會產生錯誤的結果，或者是不必的代碼，或者是相互衝突的邏輯。Better CodeReview 更多用在底層架構場景，由於架構底層模塊關聯比較緊密，須要有總體視角，而業務上層模塊間最好採用解耦模式，這樣不只不須要更耗費精力的 Better CodeReview，也是一種更正確的架構設計。

CodeReview 的語氣

Good CodeReview 會給出建設性意見，而不是發表強硬措辭要求對方改正，或認爲本身的意見是惟一正確的答案，由於這樣的評論其實具備必定攻擊性，激發對方的防護心理，產生敵對心態，這樣會從內部瓦解一個團隊。最好能給出建議，或者多個選擇，給對方留有餘地。

Better CodeReview 永遠是考慮全面且正向積極的，會對寫的好的地方進行鼓勵，對寫的很差的地方也體現出善解人意的關懷，考慮到對方可能花費了不少心血，以一種換位思考的鼓勵心態進行評論。

其實讀到語氣這一章節，逐漸發現 CodeReview 不只是一個技術專業行爲，仍是一我的與人相處的社交行爲，有的人平時與人打交道很是謙遜，但在 CodeReview 中就變得尖酸刻薄，顯然是隻關注到了 CodeReview 的專業性這一面，忽略了社交性這一點。而要作到 Better CodeReview 還要學會換位思考，體現出包容、正向積極的態度，由於你技術經驗更豐富，能指出別人的問題很正常，但能保持謙遜，讓別人容易接受並受到鼓勵，可讓你成爲一個有氣度的技術專家。

如何完成 CodeReview 的審閱

Good CodeReview 不會輕易經過那些開放式 PR，至少在其被獲得充分討論前，但每一個 Review 者對本身關注的部分完成 Review 後須要進行反饋，不管是 「看起來不錯」 或者用縮寫單詞 「LGTM」，以後須要有明確的跟進，好比經過協做軟件通知做者進行進一步反饋。

Better CodeReview 實際執行中會更加靈活一些，對於一些比較緊急的改動會留下改進建議，但快速經過，讓做者經過後續代碼提交解決遺留的問題。

實際工做場景會遇到一些開放式或緊急的提交，良好的 CodeReview 習慣天然是要嚴謹一些，討論清楚再經過，而且要及時反饋。但某些比較緊急的提交就要區別對待了，更好的態度是在實踐中靈活對待，但及時緊急經過了，也要保證問題在後續得以修復，好比在代碼中留一些 "TODO" 或 "FIXME" 的標記，寫上對應的負責人與預期解決時間。

從 CodeReview 到直接交流

Good CodeReview 會給出完整的評論和修改建議，若是後續提交的代碼不符合預期，Review 者能夠直接與代碼提交者面對面交流，這樣能夠避免後續花費更多溝通時間。

Better CodeReview 會在第一次給出完整的評論和修改建議，若是後續提交代碼不符合預期，會當即與代碼提交者當面溝通，避免異步溝通帶來更多的理解誤差。

補充一下，在 PR 內容過多時也能夠選擇直接與提交者當面溝通，這樣能夠更多理解做者的想法，使 Review 準確性更高。另外並不要每次都直接交流，異步的 CodeReview 自己就是一種提效方案，這會使你工做節奏把握在本身手中，僅在這種方案出現溝通問題時再選擇當面交流。

區分重點

Good CodeReview 能夠區分提示的重要程度，並在不過重要的改動前面加上 「nit:」 標記，這樣可使提交者的注意力集中在重要的問題上。

Better CodeReview 會採起工具手段解決這些問題，好比一些代碼 lint 工具，由於這些問題每每是能夠被工具自動化解決的。

代碼自動化工具的目的，很大一部分也是爲了保證代碼一致性，從而下降 CodeReview 成本，也減小不重要的評論信息出現，讓 CodeReview 儘量反饋邏輯問題而不是格式問題。

針對新人的 CodeReview

Good CodeReview 對任何人都是用相同評判標準，能夠遵循上面幾點注意事項。

Better CodeReview 會對新人區分對待，對新人給予對多的耐心、解釋和評論，甚至給出解決方法，並更積極的給出鼓勵。

任何人到一家新公司都有適應過程，一視同仁是 base 要求，但若是能給予新人更多關懷就更好啦。

跨辦公區、時區的 CodeReview

Good CodeReview 僅在工做時間有重疊的時間範圍內進行 CodeReview，這樣能保證對方能夠積極響應，在必要時進行語音、視頻溝通。

Better CodeReview 會注意到更本質的問題，留意跨團隊協做的必要性，若是某個模塊常常被另外一個時區同時修改，也許能夠將這個模塊交給對方維護，或者將 CodeReview 交給對方團隊內部進行會更加高效。

筆者所在公司也有跨時區協做狀況，但絕大部分場景會避免跨時區的 CodeReview，由於 CodeReview 通常會在同一時區團隊內部進行，這樣效率更高，應對跨時區協做時，每每也是電話、視頻會議優先。

公司支持

Good CodeReview 會獲得公司組織支持，公司能意識到這麼作雖然看起來佔用開發時間，但長遠來看提高了開發效率，所以能任何 CodeReview 價值。

Better CodeReview 會獲得公司進一步支持，公司甚至不斷研發並完善 CodeReview 系統與流程，經過系統化方案保證上面幾項 CodeReview 注意事項是否有在團隊內落實，能夠全員參與。

CodeReview 也是一種團隊文化和公司文化，公司文化帶來的是規章制度與系統工具，團隊文化帶來的是良好 CodeReview 氛圍與更高 CodeReview 的效率。

3 總結

總結一下，良好的 CodeReview 須要作到如下幾點：

1. 更全面，從正確性到系統影響評估。
2. 注意語氣，從給出建設性一覺到換位思考。
3. 及時完成審閱，從充分討論到隨機應變。
4. 增強交流，從面對面交流到靈活選擇最高效的溝通方式。
5. 區分重點，從添加標記到利用工程化工具自動解決。
6. 對新人要更友好。
7. 儘可能避免跨時區協做，必要時選擇視頻會議。

最後，但願 CodeReview 可以獲得公司的支持，若是大家公司尚未承認 CodeReview 的價值，能夠將這篇文章分享給你的領導。

討論地址是： 精讀《如何作好 CodeReview》 · Issue #237 · dt-fe/weekly

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

版權聲明：自由轉載-非商用-非衍生-保持署名（ 創意共享 3.0 許可證）