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

【編者按】代碼審查，本身應(yīng)該是一個(gè)相互合作，相互學(xué)習(xí)，整合團(tuán)體動(dòng)力，最終卻以消極和敵意為代價(jià)向前發(fā)展。這種現(xiàn)象是如何造成的，我們又該如何克服呢？原文作者Erik Dietrich給出了一些見解。譯文如下：

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

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

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

居高臨下和嘲諷

在正常的代碼審查中，一般會(huì)產(chǎn)生邏輯錯(cuò)誤，但千萬不用止步于此。如果錯(cuò)誤可以驅(qū)動(dòng)開發(fā)，那么你可以添加一句“是個(gè)人都不會(huì)忘記這點(diǎn)”的評(píng)論會(huì)讓他們更加印象深刻。代碼審查是項(xiàng)單向活動(dòng)，不用擔(dān)心他們回過頭來找你算賬。

讓審查沒完沒了

一點(diǎn)點(diǎn)代碼審查算是“還不錯(cuò)”，那10小時(shí)的馬拉松會(huì)就值得考驗(yàn)了。請(qǐng)確保您審查每一行代碼、每一個(gè)配置文件的改變、每一個(gè)標(biāo)記標(biāo)簽及每個(gè)自動(dòng)重構(gòu)。

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

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

以事實(shí)定位你的意見

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

逃避所有可以很容易地自動(dòng)檢查出的錯(cuò)誤

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

保持消極

一點(diǎn)點(diǎn)積極的鼓勵(lì)都會(huì)激勵(lì)整個(gè)項(xiàng)目的進(jìn)度，代碼審查其實(shí)有很多這樣的機(jī)會(huì)，因?yàn)槟憧梢钥吹胶芏嘈碌淖鍪路椒āＵ驗(yàn)槿绱耍阅惚仨氁⌒模潦贾两K保持消極。使用白板或電子表格列出別人的錯(cuò)誤，并且多多益善。

結(jié)語

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

代碼審查不是考試，也不是為了證明代碼的價(jià)值，而是提出更好的解決方案的機(jī)會(huì)。通過結(jié)對(duì)編程來減少代碼審查中的摩擦。這樣一來，更多的人一起來捍衛(wèi)自己的工作而不是一個(gè)團(tuán)隊(duì)來挑某個(gè)人的刺。

研究表明，減少Bug最有效的方法不是過于苛刻，不是使用靜態(tài)分析工具，甚至不是單元測(cè)試，而是結(jié)對(duì)檢驗(yàn)。找一種工具來折騰是個(gè)不錯(cuò)的選擇，只要像待人一樣對(duì)待它就行了。

英文出自：Daedtech

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)