如何做有效的Code Review？我有這些建議
（點擊
上方公眾號
，可快速關注）
編譯：伯樂在線/maifans
如有好文章
投稿，請點擊 → 這裡了解詳情
代碼評審（Code review）是保證代碼質量的一種有效手段，做得好的話，對公司來講是一筆收益頗高的時間投資。但實踐起來往往變成了炫耀編程技能、固執己見、惡言相向、同事關係惡化的事，這該如何是好？
往往代碼評審過程中，評審者（Reviewer）往往會過於關心旁枝末節，而忽視主要問題，也就是所謂的自行車棚效應。在批准價值百億的核電站的建設提案中，專家們往往會浪費大量時間糾結於廠內自行車棚（bikeshed）的顏色；因為核電站太大、太複雜，「專家們」未必真懂，但總不能不說話啊，那就從無關痛癢的自行車棚挑毛病吧。
有效的代碼評審
代碼評審是開發人員編寫的代碼由另一個人檢查以查找缺陷和改進的過程。換句話說，開發人員大部分都是獨立編寫代碼的，當代碼完成之後，他們會召集一次評審。
代碼評審是提高軟體質量的有效途徑。在Google，所有代碼都要經過同行評審。引用《代碼大全（第2版）》中的幾個例子：
IBM 的 Orbit 項目有 50 萬行代碼，使用了 11 級的檢查。它提前交付，並且只有通常預期錯誤的百分之一。
一份對 AT＆T 的一個 200 多人組織的研究報告顯示，在引入評審後，生產率提高了14％，缺陷減少了90％。
噴氣推進實驗室估計，通過早期發現和修復缺陷，每次評審節省約 25,000 美元。
然而，不少團隊在有效的代碼評審爭論中，失去了原本的效益。在功能失調的團隊和組織中，對所有參與者來說它可以迅速變成一個
令人不快的經歷
：
它成為評審人員來展示技能的平台。他們在別人的代碼中指出「錯誤」，並強加自己沒有價值的「意見」。
在代碼完全就緒前，開發人員會非常抗拒別人審查他們的代碼 ——可以說這可能是一件好事，但他沒有真正理解評審的意義。
開發人員放棄代碼所有權，並開始依賴他人查找問題。
在這篇文章中，我將討論團隊和組織可以做的一些事情，讓代碼評審為所有參與者帶來愉快的體驗。
對管理層的建議：營造健康文化
有效的代碼評審，需要一個重視質量和卓越的健康文化。
如果團隊不以提供高質量的產品為信仰，代碼評審將不會給您所期望的結果。你需要一個人人參與的積極文化—立足於建設性批評，智者勝。
除了創造一個健康文化，並允許花時間和資源進行評審，管理者在代碼評審中應保持低姿態。
大多數人不想在上司面前暴露自己的秘密，這已是一種文化。代碼評審最好由同行進行，管理層不應該詢問可以用來評價人的細節。
的確有一些管理人員索要檢查表和成績，以便他們可以「
衡量」
並評價人。可能你已經有一個健康的文化（算你幸運）。
這還不夠，營造健康的文化取決於許多因素（團隊和組織內部）。這是非常具有挑戰性的，沒有靈丹妙藥。沒有正確的文化，代碼評審不會帶來期望的收穫，甚至在極端情況下可能會適得其反。對個人的建議：換位思考
Karl Wiegers 在他的《Peer Reviews in Software: A Practical Guide》中寫道：
產品的作者與評審者之間的互動至關重要。
作者必須足夠信任和尊重評審者才能接受他們的意見。
同樣，評審者必須尊重作者的才華和辛勤工作。評審者應謹慎選擇他們用來提出問題的辭彙，重點關注他們對產品的觀察。說『我沒有看到這些變數被初始化
』可能會引發建設性的反饋
， 而『你沒有初始化這些變數』可能會讓作者非常不爽。關注代碼很容易，但不要忘記，桌子（或計算機）的另一端有一個人。他有主見有
「
自我」
。請記住，解決問題的方式有很多。
要謙虛。
我既見過非常高效的評審，也見過因為吹毛求疵而非常低效的評審
。
不要吹毛求疵！！！
確保您有編碼標準
。
編碼標準是在組織中共享的人人都認同的一套準則。如果你沒有編碼標準，那麼不要讓討論變成一個比較編碼風格的比賽（大括弧{
在同一行還是下一行！）如果你遇到這樣的情況，請在編碼標準論壇上離線討論。
學會良好地溝通。
你必須能夠清楚地表達想法和理由。
編程策略是一個仁者見仁智者見智的問題。
評審者和開發人員應該尋求理解彼此的觀點，而不應該成為哲學辯論
對評審者的建議：謙虛
開發者不是冤大頭。
評審的目的不是證明誰是更優秀的程序員而是查找缺陷，並確保代碼是簡單和可維護的。
問問題。
不要提出可能聽起來帶指責的要求或言論。例如，不要說：『你沒有遵循標準XYZ
』。更好的方式是真正尋求理解開發者的觀點：『你對標準XYZ
有什麼看法，它是否適用於這裡？』，這可以引到我的下一個觀點。
避免『你為什麼』，『你為什麼不』風格的問題。
它會使人對立。 『為什麼把它聲明為全局變數？』可以更好地表達為『我不明白為什麼這裡用一個全局變數』。尋找方法來簡化代碼。代碼評審的目標之一是創建「
可維護」
軟體。
記住要欣賞並感謝對方。
人們經常忘記一句簡單的『幹得好』或『它看起來很棒』的影響有多大。
有些事情，如果看起來像排練過的或以諷刺的語氣說出來，就不會奏效。像正常對話一樣對待代碼評審。你正在聆聽他人，應該真正尋求理解他們的觀點。需要時提供建議和提示。如果代碼很棒，不要強迫找一些消極的來說。
對開發者的建議：它不是個人的事情
不要感情用事。
記住，別人說的不是，是代碼中的缺陷或不足，而不是你。
意識到你和你的代碼是捆綁在一起是正常的事情。
如果你為自己的工作感到自豪，那是一個很好的跡象，說明你是一個關心作品的人。
有適當的自我。
足夠信任和捍衛自己的觀點，但又不至於盲目拒絕對方的好建議和意見
。
人非聖賢孰能無過。
評審者作為第二雙眼，可以指出你可能忽略的事情。問題與具體建議一樣有價值。
提問題要有針對性。
『將所有這些類納入它們自己的軟體包中是否更有意義』
感謝審稿人的時間和他們可能提供的任何反饋。
總結
同行評審是人們互相交流，而無效（ineffectiveness）則源於社會學問題。然而，管理者花費大量時間在操心使用哪些驚艷的工具。
工具會有所幫助，但只有工具不會神奇地帶來結果。立足於正確的文化同時…
換位思考，以人為本！ 
看完本文有收穫？請轉
發分享給更多人
關注「P
ython開發者」，提升Python技能
※PyCharm 2017.2.3 發布，支持 Docker Compose
※數據科學和 ML 領域常用的 Python 庫
※機器學習沒有想像中的那麼難
※Werkzeug庫：routing模塊
※Python 增強的生成器：協程
TAG:Python開發者 |