|
|
Jim Bird是一位經(jīng)驗(yàn)豐富的軟件開發(fā)經(jīng)理、項(xiàng)目經(jīng)理與CTO，專注于軟件開發(fā)與維護(hù)、軟件質(zhì)量與安全等領(lǐng)域中疑難問(wèn)題的解決。在過(guò)去的15年間，Jim曾管理過(guò)團(tuán)隊(duì)建設(shè)并主導(dǎo)過(guò)高性能的財(cái)務(wù)系統(tǒng)的建設(shè)。他的主要興趣在于如何提升小團(tuán)隊(duì)的效率以構(gòu)建真正的軟件：高質(zhì)量、安全、可靠、高性能及適應(yīng)性強(qiáng)。近日，Jim撰寫了一篇博文，談到了代碼審查的價(jià)值，如何進(jìn)行代碼審查，代碼審查的過(guò)程以及在代碼審查中需要注意的問(wèn)題，希望能為大家平日的代碼審查帶來(lái)一些啟示。
開始代碼審查
從一開始，開發(fā)者就會(huì)互相幫助，如果測(cè)試中遇到了問(wèn)題或是有新人加入到了團(tuán)隊(duì)，領(lǐng)導(dǎo)或是資深開發(fā)者就會(huì)審查他們的代碼。除此之外，我們還聘請(qǐng)了外部專家進(jìn)行安全代碼審查。
系統(tǒng)發(fā)布后，我們決定更加主動(dòng)一些，開始了基于風(fēng)險(xiǎn)的審查：項(xiàng)目中有人會(huì)編寫一些風(fēng)險(xiǎn)較高的代碼（比如說(shuō)框架與安全代碼、APIs、核心業(yè)務(wù)邏輯或是之前曾經(jīng)出現(xiàn)過(guò)問(wèn)題的地方），我們會(huì)審查他們的代碼。在這個(gè)過(guò)程中，代碼審查體現(xiàn)出了它的價(jià)值，我們收獲頗豐。即便如此，我們還是更進(jìn)一步，讓代碼審查成為一個(gè)標(biāo)準(zhǔn)的實(shí)踐。
這并不是一夜之間就形成的。讓團(tuán)隊(duì)相信代碼審查的價(jià)值并不是什么難事，他們已經(jīng)通過(guò)基于風(fēng)險(xiǎn)的審查獲得了收益。不過(guò)要想改變?nèi)藗兊墓ぷ鞣绞骄筒皇悄敲春?jiǎn)單的事情了，還要確保他們有足夠的時(shí)間進(jìn)行代碼審查，理解并對(duì)反饋?zhàn)鞒鲰憫?yīng)。此外，設(shè)計(jì)一個(gè)高效的代碼審查流程也是需要花時(shí)間的。
一開始，我們讓開發(fā)者選擇好搭檔并安排審查，但結(jié)果卻有些混亂。有時(shí)，開發(fā)者會(huì)尋找那些好說(shuō)話或是比較忙的人，這樣審查就比較容易通過(guò)了；此外，兩個(gè)開發(fā)者還有可能事先商量好，因此審查過(guò)程就會(huì)很快結(jié)束。由于人們并不知道要花費(fèi)多少時(shí)間才能完成代碼審查，因此審查經(jīng)常會(huì)拖得很久，常常在代碼已經(jīng)完成測(cè)試甚至是發(fā)布后才完成。
由于大多數(shù)人并沒(méi)有太多的代碼審查經(jīng)驗(yàn)，因此他們并不確定在審查時(shí)應(yīng)該看什么，如何給出有意義的反饋等信息。開發(fā)者常常會(huì)被負(fù)面的批評(píng)搞得很沮喪，有時(shí)甚至?xí)臒┮鈦y。
最后，我們決定由領(lǐng)導(dǎo)來(lái)完成大部分審查工作。雖然這會(huì)增加領(lǐng)導(dǎo)的工作量，也意味著他們沒(méi)有太多時(shí)間編寫代碼了，不過(guò)這么做卻是很有效果的。通常情況下，主開發(fā)者會(huì)對(duì)需求有著更好的理解，對(duì)代碼的行為有著清晰的認(rèn)識(shí)，這也意味著他們更有可能發(fā)現(xiàn)代碼中的錯(cuò)誤。由于是同一個(gè)人完成了大部分的代碼審查，因此被審查的開發(fā)者會(huì)收到一致的反饋信息。
我們?nèi)绾芜M(jìn)行代碼審查
在過(guò)去的幾年間，我們進(jìn)行代碼審查的方式幾乎沒(méi)有發(fā)生過(guò)什么大的變化。
無(wú)論是誰(shuí)編寫的，無(wú)論代碼的功能是什么，重要的代碼變更是一定要審查的。我們并沒(méi)有一個(gè)正式的審查會(huì)議，也沒(méi)發(fā)現(xiàn)使用諸如Code Collaborator、Crucible等工具有什么必要性，不過(guò)現(xiàn)在看起來(lái)使用這些工具來(lái)管理和追蹤審查有助于團(tuán)隊(duì)更好的起步。
有時(shí)，審查是面對(duì)面完成的，不過(guò)大多數(shù)時(shí)候都是離線進(jìn)行的。審查者與開發(fā)者會(huì)交換信息，也許通過(guò)郵件發(fā)送文件，因?yàn)槲覀冇X(jué)得這種方式更加便捷，也更加方便每一個(gè)人安排自己的時(shí)間。
隨著時(shí)間的流逝，審查中的變化之處是審查者該看什么，以及看到的結(jié)果。
審查正確性
很多時(shí)候，程序員們會(huì)花費(fèi)很多時(shí)間爭(zhēng)論在代碼審查過(guò)程中應(yīng)該看什么，但實(shí)際上他們卻沒(méi)有花太多時(shí)間完成真正的代碼審查。
我們開始代碼審查的目的是改進(jìn)代碼質(zhì)量，尋找測(cè)試中沒(méi)有發(fā)現(xiàn)的問(wèn)題。這么做并不是教授經(jīng)驗(yàn)不足的開發(fā)者如何編寫更好的代碼，或是如何在團(tuán)隊(duì)內(nèi)分享知識(shí)。這些都應(yīng)該是代碼審查所帶來(lái)的間接好處，不過(guò)審查的最終目的應(yīng)該是確保代碼能夠正常工作。
相對(duì)于使用長(zhǎng)長(zhǎng)的檢查列表，審查者在看代碼時(shí)首先會(huì)問(wèn)幾個(gè)問(wèn)題：
- 代碼的行為是否與預(yù)期一致，其邏輯是否是正確無(wú)誤的？
- 被審查的代碼是否與其他代碼擁有類似的結(jié)構(gòu)和功能？
審查可理解性
隨著時(shí)間的流逝，在代碼審查中尋找和得到的東西會(huì)發(fā)生變化。這是因?yàn)榇a本身會(huì)發(fā)生變化，完成這項(xiàng)工作的人——開發(fā)者與審查者也可能發(fā)生變化。
開發(fā)者需要在其IDE中裝上代碼檢查工具，同時(shí)我們也要使用一些優(yōu)秀的靜態(tài)分析工具來(lái)自動(dòng)檢查常見(jiàn)的編碼Bug和不好的編碼實(shí)踐。這意味著審查者的時(shí)間可以花在更加重要的設(shè)計(jì)錯(cuò)誤上，比如說(shuō)并發(fā)Bug、競(jìng)態(tài)條件和潛在的死鎖等，因?yàn)檫@些問(wèn)題是工具所無(wú)法檢測(cè)到的。
理解，而不是批評(píng)
審查的目的是理解代碼，確保代碼能夠正常工作，而不是批評(píng)任何人。
在代碼審查過(guò)程中，請(qǐng)不要摻入諸如“我認(rèn)為好的代碼是什么，你認(rèn)為好的代碼是什么”這樣的論戰(zhàn)之中。代碼審查應(yīng)該重點(diǎn)關(guān)注“我需要完全理解這部分代碼才能確保它能夠正常工作，如果由我來(lái)修復(fù)代碼中的問(wèn)題，我是不會(huì)這么寫的，因此希望你也不要這么來(lái)寫”。
隨著時(shí)間的流逝，有些東西會(huì)變好，有些則不然
隨著時(shí)間的流逝，在查看代碼時(shí)你會(huì)發(fā)現(xiàn)代碼在不斷變化。Michael Feathers發(fā)現(xiàn)大部分代碼在寫完后很少或是從來(lái)都不會(huì)變化；大部分變更都是發(fā)生在代碼基中的很小一部分代碼上的。
由于審查者會(huì)看到相同的代碼在不斷發(fā)生著變化，因此這也會(huì)改變他們的審查方式。
避免收益遞減
類似于軟件開發(fā)中的其他實(shí)踐一樣，你最終會(huì)發(fā)現(xiàn)代碼審查有著收益遞減的效應(yīng)，特別是一直在做相同的事情的時(shí)候，以相同的方式查看相同的問(wèn)題。最終會(huì)有這樣一個(gè)階段，那就是代碼審查的價(jià)值幾乎降到了0。不過(guò)這種情況并沒(méi)有發(fā)生在我們身上，我們依然從代碼審查過(guò)程中獲得了很多收益。
即便改進(jìn)了工具，增強(qiáng)了測(cè)試能力，我們依然進(jìn)行代碼審查，因?yàn)锽ug檢查工具、審查與測(cè)試會(huì)發(fā)現(xiàn)不同類型的問(wèn)題。我們還發(fā)現(xiàn)代碼審查會(huì)讓測(cè)試更加高效，這是因?yàn)槿绻霸?jīng)發(fā)現(xiàn)過(guò)問(wèn)題，那么開發(fā)者與測(cè)試者之間就不會(huì)出現(xiàn)過(guò)多的往復(fù)情況。
it知識(shí)庫(kù)：我們?nèi)绾芜M(jìn)行代碼審查，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
