讓評審人愛上你的8個要點

簡介：今天小編做爲一個開發者，放下外部的客觀因素，僅從一個代碼的實現者，一個被評審人的角度去思考如何讓評審變得高效而富有意義。換句話說：如何讓評審人愛上我（被評審人）。

衆所周知，每一個有技術追求的團隊，都試圖想把Code Review作到極致。正所謂——未經審視的代碼，不值一提。爲何Code Review如此重要，本篇再也不贅述，僅作簡單總結：

• 提前發現問題，防患故障於未然
• 快速提升團隊新同窗的編程能力

然而夢想很豐滿，現實很骨感，團隊的評審活躍度和評審質量每每使人堪憂，原因種種，上至技術TL、下至代碼功能的實現者，甚至產品經理（嗯，必定是業務過重致使沒時間作Code Review）都能成爲作很差Code Review的罪魁禍首。今天小編做爲一個開發者，放下外部的客觀因素，僅從一個代碼的實現者，一個被評審人的角度去思考如何讓評審變得高效而富有意義。換句話說：如何讓評審人愛上我（被評審人）。

爲何要讓評審人愛上我

在以往的文章討論中，咱們每每更專一於如何提高評審人的水平，如何找出評審代碼的問題，或者如何讓被評審人能快速解決提出的問題。但咱們忽略了評審人的感覺，彷佛評審人就是一個毫無感情的找BUG機器。固然，不排除一些自動化掃描的工具（好比：Codeup的缺陷檢查、漏洞分析等等），它們確實是AI機器人。但除此之外不少時候由於對代碼的業務理解、團隊的編碼風格等問題，仍是須要團隊的其餘成員做爲評審者介入其中。對於不走心的敷衍評審咱們撇開不談，評審者參與一次評審仍是挺耗費精力和時間的，須要時間去閱讀、理解、並指出疑問。所以，咱們應該放下防備，坦然對待評審過程，並對評審人心懷感激。

如何讓評審人愛上我

既然咱們已經下定決心與評審人來一場甜蜜的Code Review之旅，怎樣才能讓評審人愛上我（的評審）？我從一次評審的全週期來分析，分別爲：

• 【評審前】如何作好評審前的準備；
• 【評審中】如何對待評審中的討論/問題；
• 【評審後】評審後須要作什麼。

提交評審前

重點：

• 認真審視本身的代碼
• 作好提交（Commit）
• 保證測試基線

認真審視本身的代碼

在評審中，最忌諱的一點就是犯一些低級錯誤，這樣不只會給評審者不好的印象，也會將評審者的時間浪費在一些低級錯誤之中。因此，咱們要在提交代碼前本身先認真審視本身的代碼。

格式問題

格式問題，常發生在一些初建的團隊，你們有不一樣的開發習慣、編碼風格，在單人開發中，並無什麼問題。當這個項目涉及到多人協做時，就會顯得很麻煩。好比下面這個評審，實際上是沒有實際的改動只是編碼風格的格式化。但密密麻麻的文件變更，每每會讓人心神不寧。
所以在提交前，咱們應按照團隊的規範，設置好本身的編輯器格式工具，並在提交前檢查是否存在格式上問題，避免這種問題在Code Review的時候浪費你們的時間。

拼寫錯誤

拼寫錯誤是屬於低級錯誤了，目前主流的編輯器都支持拼寫檢查，只要你們認真對待編輯器高亮的warning，就能找出來啦。

代碼規範掃描

一些很是基礎問題，能夠經過自動化工具掃描出來。好比針對java的開發規約檢測，代碼平臺提供的漏洞檢測、安全掃描等。在提交之後看到分支上改動的commit都是綠色的pass，心情也會好不少。畢竟咱給評審者提供的代碼也是通過一遍初選的複賽選手了。

作好提交（Commit）

說到提交（commit），不少同窗都以爲沒什麼。不就是git commit 麼。或者commit的時候，由於Git的強制要求必須包含message，才隨便輸幾個只有本身懂的提交說明，而後git push拉倒。好比下面這種提交說明，我在不少兄弟團隊的代碼倉庫都有見過。

這種提交說明的問題，我就再也不贅述了。接過老項目、給老工程填過坑的人都懂。所以在評審階段，咱們就要作好提交。

• 要點一：按功能拆分提交，拒絕大Diff評審

在平時的開發中，你們每每都是多個任務並行開發。不少同窗又不喜歡來回切換變動的分支，致使不少評審都是多個功能一股腦的提交，所以評審天然也就變得很大。或者在開發一個比較大的需求時，沒能將功能進行拆分細化，致使全部的改動都在同一個評審中，甚至在同一個Code Review中。例如：

這個評審，中間混雜了數十個功能的提交，評審者很容易迷失在不一樣功能的邏輯迷宮中。更有甚者，會提交增刪行數高達上萬行的評審。對於這種超大評審，我不太相信評審者會認認真真地看完。有研究自媒體分享的統計，現代人的注意力只能聚焦5分鐘，若是一個分享超過5分鐘沒法結束，人們每每會由於想不起來前面的內容而放棄。評審也是如此，長達數萬行的改動，都在同一個評審中，即使是在評審頁面上提供鉚釘已閱讀的文件的功能，也很難在短期內容理解上下文的邏輯。所以評審者須要耗費長達半個小時以上的獨立時間來閱讀評審的改動，而這對於正常的開發人員是很是崩潰的。所以，咱們在完成一個功能的時候，應當合理的按功能拆分，將提交變小（small is beaut iful）。當改動過於龐大應該考慮拆分多個評審進行。

• 要點二：描述清楚本次提交的內容、改動點、改動影響

一個評審的開始，從打開頁面到評審開始，通常眼睛的順序是：評審標題->評審描述->改動列表->改動詳情

評審的標題和評審的描述每每就是咱們提交的內容生成的。而做爲評審開始的前兩個關鍵點，評審提交描述是很是重要的。好比下面這種例子：

我相信各位做爲評審人，看完這個評審已經想關掉評審了（一些暴躁老哥甚至直接點拒絕）。使人費解的評審標題，空白的評審描述。即使咱們拿着Code Review坐在評審者的電腦前、或者釘釘上附上評審解釋，這種體驗都是很是很差的，由於你們都不肯意注意力被分散。就像咱們寫代碼同樣，你們都更願意在開發過程當中聚焦在編輯器上，而不是在不一樣的屏幕間來回切換（查看需求、被人中途打擾等）。所以咱們應該寫好描述，儘可能讓評審開始的時候，你們都能在一塊屏幕（一個頁面上）完成評審的全部工做。

除此以外，良好提交說明，能夠提早讓評審者感知到改動點和改動影響。好比下面：

評審者從描述中就能肯定咱們改動的地方和改動的影響，從而可以讓評審者更快的進入狀態，而不須要本身去閱讀詳細內容猜咱們改了什麼。

• 要點三：功能改動和非功能改動儘可能分開

在一次功能中，咱們除了功能性的改動，可能還包含一些非功能性的變更，若是都揉和在一塊兒，每每看起來很是的難受。好比下面這種狀況：

在這個改動中，我除了作一些功能上改動，還順便修改了文檔、對以往的格式問題作了格式化。雖然都是同一個改動，但觀感仍是很是差的。就像老師講課，好的老師必定是按內容概括，按內容教授，而不是代數幾何混在一塊兒講。

所以咱們能夠在評審的提交中作進一步的拆分。仍是針對上面的例子。咱們調整後的樣子爲：

在評審頁面的左側點擊所有提交，經過提交信息選擇咱們須要獨立評審的提交內容。

選擇功能性改動的提交，進行功能改動的評審。

選擇非功能性提交，即可以只關注非功能的改動。好比這裏咱們只用單獨看下README裏的改動就能夠，全程清爽。

保證測試基線

在不少已經成型的項目中，每每都有充分的測試覆蓋掃描。當咱們提交代碼的時候，在功能上咱們第一個要保證的就是以往的測試都能經過（除非是這個測試用例已經廢棄或存在錯誤，這種咱們應該單拎一個功能來修正），這也是對評審者的尊重，由於連功能的正確性都沒法保證的評審是無心義的。

在雲效中，咱們能夠將評審的目標分支做爲保護分支，在自動化檢查中配置自動化檢查。經過在流水線中經過靈活的配置來設置咱們工程中須要卡點檢查。

而後，在咱們提交的評審的時候，就會自動觸發咱們配置的卡點了。若是卡點不經過，是不容許評審經過的。所以咱們在提交評審中，要注意卡點的內容，要讓咱們的評審「綠」起來。

評審中

重點：

• 積極對待評審反饋
• 代碼是最好的解釋
• 原諒評審人的誤解/失誤
• 保證Code Review的時效性

積極對待評審反饋

一部分同窗反感代碼評審的緣由是，他們認爲評審人是有意爲難本身。不能排除在一些比較複雜的社會環境中確實可能存在這種問題。可是做爲被評審人，咱們仍是要積極的看待評審的反饋。畢竟雞蛋裏挑骨頭的前提是要有骨頭，問題提出就必定有其合理性。絕大部分技術人對待代碼仍是中立的，不能積極面對評審更多的是咱們擔憂本身的代碼不夠好，怕別人指出問題。但換個角度想，評審人其實也是在幫助咱們，早點在評審階段發現問題，總比線上出了問題要好。另外，在不斷的評審中，咱們也能快速的進步本身的編碼能力。

代碼是最好的解釋

當評審者對咱們的代碼提出疑問的時候，咱們除了解釋，更應該作的是考慮爲何會出現這種疑問。有時候雖然我對評審人的疑問作了詳細的回覆，評審人彷佛也理解了。但這個評審真的就結束了嗎？馬克思老人家說，咱們應該透過現象看本質。畢竟評審人可能不僅一個，即使當前的其餘評審人看到這個解釋也能明白,但咱們沒法保證後續涉及這塊的代碼改動再次評審的時候，會有人能明白這裏的歧義。所以這種存在歧義的評審質疑，其自己的問題是代碼未能作很好的解釋。

面對這種狀況，通常的建議添加充分的代碼註釋。但我更建議咱們直接對代碼進行重構，讓代碼自己就能解釋清楚其意義。

原諒評審人的誤解/失誤

孔子云：人非聖賢孰能無過。評審者在評審中也會存在對正確代碼的誤解。在這種時候，咱們不能得理不饒人，應當保持謙遜。正如在開篇中提到的，評審者實際是對咱們提供幫助的，幫消滅咱們本身未知的隱患。所以咱們不該該貿然反擊，應當理性迴應，在解釋的同時也是對咱們本身的代碼的一個很好的回顧。除此以外，咱們還應意識到這裏另外一個問題—— 存在即合理 ，若是評審者提出了疑問，是否證實這裏存在不合理性，多是代碼有歧義須要重構？

保證Code Review的時效性

評審也應該有時效性。由於評審人評審的代碼，每每不是本身的參與的業務，評審週期拉的太長，可能會想不起來。所以在評審中，每每會設置一個提醒的鉤子。配合釘釘的webhook接收，能儘早的感知評審的人的意見。

在修改結束後及時給予反饋。這樣讓評審者對評審還沒「冷卻」的時候，就能更快的繼續評審，你們就能早早下班啦。

評審後

評審後，評審的內容會保存在平臺上，後面能夠隨時查看回顧。除此以外，在評審後最重要的是選擇一個合併方式。通常我會選擇squash的模式進行合併。將評審中的全部提交合併爲一個commit。這樣合併到主幹中，一個提交就是一個功能。注意，這個和前文的提交拆分並非一回事。在提交評審階段，咱們爲了方便評審，將提交拆爲功能改動和非功能改動。但在合併階段由於已經經過了評審。咱們要將一個功能的改動放到一個提交中。

點擊合併後，評審中的屢次提交最終會壓縮爲一個commit合併到目標分支中。這樣也就保證了一個功能一個commit的原則。在後續排查問題和線上回滾都會很是方便。

P.S. 合併方式應該依據各自團隊對工程管理和開發模式的選擇來決定，以上只是一個簡單的例子。

總結

總結一下，若是讓評審者愛上給我作評審，我會這麼作：

1. 提交前認真審視本身的代碼，拒絕低級錯誤
2. 按功能拆分提交，寫好提交說明
3. 讓全部的單側、集測變綠經過，保證質量基線
4. 積極對待評審反饋
5. 用代碼解釋評審者的疑問
6. 正確對待評審者的誤解/失誤
7. 及時修正/反饋，保證評審的時效性
8. 評審後選擇正確的合併方式

本文做者：陳博俊，阿里雲技術專家，Git開源項目貢獻者，負責阿里巴巴經濟體代碼平臺及雲效代碼平臺底層架構設計及運維開發。

---

長按識別上圖二維碼 當即報名

6大專場

27位海內外技術大咖

邀你共享效能盛宴

鎖定6月23日-6月24日

9:00-12:00  14:00-18:00

咱們期待與您共建研發效能美好將來！

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。