代碼審查是如何抹殺開發者積極性的？

【編者按】代碼審查，本身應該是一個相互合作，相互學習，整合團體動力，最終卻以消極和敵意為代價向前發展。這種現象是如何造成的，我們又該如何克服呢？原文作者Erik Dietrich給出了一些見解。譯文如下：

前不久，我收到一封有關討論代碼審查的郵件，對方對其抱著無所謂的態度，我想這可能是大部分人持有的態度，這也一直是大多數的代碼審查的面臨的尷尬狀況，但不是全部。與其冒著把孩子與洗澡水一起倒掉的風險，那不如干脆不要把洗澡水弄臟。我的意思是，完全杜絕糟糕的代碼審查。

雞蛋里挑骨頭和無意義的討論

我想我們大多數人都同意，沒有什么比花一兩個小時的爭論是否要使用隱式類型，或是拋出ArgumentNullException還是NullReferenceException異常更無聊了。為什么讓你的代碼審查變成那樣呢？你可以不用擔憂大局，僅僅進行哲學討論，如代碼的可讀性和易維護性。那些曾將代碼審查作為學習和合作機會的人，很快就會意識到，他們只會關注產生意見分歧的地方。

居高臨下和嘲諷

在正常的代碼審查中，一般會產生邏輯錯誤，但千萬不用止步于此。如果錯誤可以驅動開發，那么你可以添加一句“是個人都不會忘記這點”的評論會讓他們更加印象深刻。代碼審查是項單向活動，不用擔心他們回過頭來找你算賬。

讓審查沒完沒了

一點點代碼審查算是“還不錯”，那10小時的馬拉松會就值得考驗了。請確保您審查每一行代碼、每一個配置文件的改變、每一個標記標簽及每個自動重構。

保證所有審查必須“通過”

當你將情景設置為“教授和學生”，你不妨繼續制定“審查必須通過”的政策。這樣一來，它就不是一個專業團隊檢討彼此的工作，你可以提出批評、建議和見解，而是一個被嚇壞了的初級開發人員試圖找出這次發布的版本中做的不夠好的地方。為什么把每個開發/循環/發布搞得像參加SAT考試一樣隆重呢？

以事實定位你的意見

也許你會認為靜態方法比實例方法更好，這是一個事實。想想你帶有個人偏好的設計模式，編碼方法，風格等，然后去掉類似“我認為”，“我喜歡”，或者“在我看來”等修飾語，將“我喜歡用下劃線命名字段名”變成“你應該用下劃線命名你的字段名”；“我覺得你的參數很混亂”變成“我們的參數很混亂”。不管你做什么，不需要有任何證據或引用說明。當你告訴別人，他們的代碼太長了，他們會問：“哪里太長了？你只要回答“我是高級程序員，而你的代碼比我長。”

逃避所有可以很容易地自動檢查出的錯誤

為什么要花費一天時間坐在一個狹小的會議室，尋找是否有人犯了采用Camelcase命名而不是Pascalcase命名方法的大罪呢？你可以一行一行地數方法的代碼行數，甚至通過手工計算循環的復雜度。當然，有很多工具可以在幾秒鐘內可以做任何你想做的事情，但這樣就失去了公開指責初級開發人員錯誤的機會了。

保持消極

一點點積極的鼓勵都會激勵整個項目的進度，代碼審查其實有很多這樣的機會，因為你可以看到很多新的做事方法。正因為如此，所以你必須要小心，至始至終保持消極。使用白板或電子表格列出別人的錯誤，并且多多益善。

結語

我相信，良好的代碼審查需要一致協作。如果發現了錯誤，你不需要直接告訴別人他們錯了，換成“你覺得，如果我傳遞null給這個方法會怎么樣呢？”就足夠了，別人可能會說“哦，這個我沒考慮到，我馬上解決它。”讓他們自己意識到錯誤并提出改進的方法會更好。

代碼審查不是考試，也不是為了證明代碼的價值，而是提出更好的解決方案的機會。通過結對編程來減少代碼審查中的摩擦。這樣一來，更多的人一起來捍衛自己的工作而不是一個團隊來挑某個人的刺。

研究表明，減少Bug最有效的方法不是過于苛刻，不是使用靜態分析工具，甚至不是單元測試，而是結對檢驗。找一種工具來折騰是個不錯的選擇，只要像待人一樣對待它就行了。

英文出自：Daedtech

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈