代碼審核和代碼重構(gòu)

代碼審核和代碼重構(gòu)，有其特別意義代碼審核代碼審核是通過閱讀別人的代碼，來尋找錯(cuò)誤，提出改進(jìn)意見等的過程和實(shí)踐。使得代碼更清晰，設(shè)計(jì)更合理，綜合性能更好是條很漫長的路。另外一雙眼睛，另外一種審視問題的角度會極大的促進(jìn)方案更清楚，更優(yōu)異。代碼審核還會幫助程序員相互傳授有用的技術(shù)，方法，風(fēng)格等。只要一個(gè)項(xiàng)目的開發(fā)者多于一個(gè)人，那么立即開始相互審核代碼。理想情況下，每一行代碼都要被兩個(gè)人看過，作者和審核人。對代碼審核的實(shí)踐有很多東西值得探討：何時(shí)審核，如何整體審核，由誰來審核。在很多全職的程序員共同參與的大工程中，每一段代碼都應(yīng)在提交的時(shí)候送評（如果有更好的工具支持，則應(yīng)在提交之前）。審核人要清楚與之相關(guān)的代碼，并要理解其作用（還有，更重要的，可能會發(fā)生的錯(cuò)誤）。在此過程中，審核要快速的完成（一到兩天內(nèi)），作者在評論完成之前，不要試圖改動(dòng)這段代碼，以避免把事情搞亂。參與人數(shù)少的小項(xiàng)目則不必如此。要是代碼不多的話，進(jìn)展的速度會很快，要是每一次提交都審核的話耽誤不起。但是，代碼審核對代碼和寫代碼的人都很有益處（因?yàn)?，不說別的，這使得至少兩個(gè)人都理解這段代碼。）用什么樣的風(fēng)格做項(xiàng)目，只要適合就好，但一定要養(yǎng)成審核代碼和讓人審核代碼的好習(xí)慣。如果你是審核人：及時(shí)如若有人請你審核一段代碼，要么馬上開始，要么痛快的告訴人家不行（并轉(zhuǎn)交給更有資歷的審核人）。千萬不要讓人家等。尊重代碼審核的目的是確保代碼的質(zhì)量，不是為了顯示出誰比誰高明。作為審核人，你的確有很大的權(quán)力，但是不能亂用。詳盡若是有些東西你搞不清楚，要么是代碼寫的就不夠清楚，要么是注釋不夠，也可能二者兼有。請作者澄清（不單單是對你私下里的解釋，要寫進(jìn)代碼里）。要是什么不對勁，這很可能，或者是對的但看上去是錯(cuò)的，或是晦澀的，都要告訴作者使其修改。執(zhí)行規(guī)定要是項(xiàng)目中有些規(guī)定或規(guī)范（代碼風(fēng)格，命名規(guī)范，測試等），發(fā)現(xiàn)不符的地方一定要讓作者修改。有些時(shí)候這樣做顯得吹毛求疵，但是定下這些規(guī)定和規(guī)范是有緣由的，所以應(yīng)該遵守。如果你是被審核代碼的作者：尊重審核人是你的朋友，給你有價(jià)值的建議。如果你有些不同見解，那么這絕對是建設(shè)性談話的好議題。要是審核人對你的代碼有誤解，那么極有可能是你沒有把代碼寫清楚。不要以為批評是針對你本人代碼審核是要改進(jìn)代碼，不是要刺傷（或者是提升）你的自尊心。審核之所以一定要關(guān)注你做錯(cuò)的地方，是因?yàn)槟蔷褪且倪M(jìn)的地方。對不良代碼的批評都是建設(shè)性的（很可能包括積極的建議從某方面深入思考），要是并非如此，也許找審核人禮貌的談一談是個(gè)不錯(cuò)的選擇。盡早盡量獲得審核審核一大堆剛寫的代碼是非常非常討厭的，只有一種例外，審核人發(fā)現(xiàn)在整個(gè)部分你都在犯傻。這個(gè)過程需要一點(diǎn)一點(diǎn)修改提交。即使你認(rèn)為要多做一點(diǎn)兒，將工作拆分成易于審核的小塊，這樣會避免很多錯(cuò)誤，以使你得到數(shù)倍的回報(bào)。十個(gè)100行的代碼審核要比一個(gè)900行的來得輕松得多，拆分著做會節(jié)省很多尋找修正bug的工作量。代碼重構(gòu)重寫一段代碼保留其運(yùn)行的外部特性，但在某些方面有所改進(jìn)，這樣的過程稱之為重構(gòu)。通常這是為了代碼更加清晰易讀，或是為了更易于擴(kuò)展，也可能是為了執(zhí)行的更快。這項(xiàng)活動(dòng)不論規(guī)模大小，都可以叫做重構(gòu)。重新命名變量和函數(shù)是重構(gòu)，在類之間調(diào)換功用亦是重構(gòu)，將一個(gè)100，000行糾纏在一起的代碼分解成一個(gè)插件架構(gòu)和若干相對較小獨(dú)立的組件。當(dāng)然，三種目的的重構(gòu)遇到的問題會有很大的不同，但有一點(diǎn)是不變的：無論哪一種目的的重構(gòu)都不改變原有代碼與外部世界的交互。重構(gòu)對代碼，對身心都是有益處的。一定要重構(gòu)。重寫一段代碼并不丟人。就當(dāng)?shù)谝话媸遣莞?。這會幫助你勾勒問題的輪廓，是你明白你要從方案中得到些什么。得到已經(jīng)正常運(yùn)轉(zhuǎn)的代碼是非常有用的，這樣可以制定測試組件，來精確定義你到底要解決什么問題。然后，有了測試組件，你就可以修改你的初始方案做出改進(jìn)。之后，修改第二稿，第三稿，直到?jīng)]有可改的了。相似的，千萬不要以為沒有對代碼的行為做出顯式的修改就是浪費(fèi)時(shí)間。相反，通過梳理代碼，你可以使其更加易讀便于理解，易于維護(hù)和擴(kuò)展，便于發(fā)現(xiàn)和修正bug。要是需求在最后的時(shí)刻發(fā)生了變化，在這上面花點(diǎn)精力的就會顯得太值了，事實(shí)上也往往如此。那么，怎么重構(gòu)呢：重構(gòu)其價(jià)值如何強(qiáng)調(diào)都不過分。不要將重構(gòu)與實(shí)質(zhì)性的修改混為一談代碼的行為在你重構(gòu)前后應(yīng)該是一致的，相同的。這也是檢查與驗(yàn)證你是不是進(jìn)行重構(gòu)的極其有效的手段。盡可能將你的重構(gòu)一個(gè)一個(gè)的提交，而將實(shí)質(zhì)性的修改分開提交。測試重構(gòu)的代碼除了最簡單重構(gòu)外，值得重構(gòu)的代碼，也只得測試。相應(yīng)地，由重構(gòu)的定義可知重構(gòu)應(yīng)該在不改變代碼行為的框架內(nèi)進(jìn)行。若是測試套件已經(jīng)有了足夠的邊界條件測試，很好。要是沒有，做一些，并在你開始重構(gòu)之前弄好它們。這是一個(gè)很好的方法可以使你的重構(gòu)不拖累其它部分。一小塊一小塊的來信誓旦旦地說“我要重寫這個(gè)程序”，然后埋頭就干，企圖一下子把所有都重做一遍。說說很容易，但絕對行不通。這樣絕對不會得到看上去一樣的程序，你就開始想是個(gè)bug呢，還是原本特性如此呢，原來的代碼到底對此事如何處理呢，等等。絕對是災(zāi)難。在重構(gòu)過程中，當(dāng)目標(biāo)總是停滯不前，我們總是可是把事情分成一小段一小段的，以便查驗(yàn)。別害怕丑陋的中間產(chǎn)物舉例來說，如果你想修改一個(gè)接口，首先為新的接口提供支持，然后將所有客戶端逐個(gè)轉(zhuǎn)換，然后去掉舊版本的接口。要是修改過于龐大的話，不要一蹴而就，將其拆分成幾個(gè)小部分完成?？梢钥隙ó?dāng)你修改到一半時(shí)，代碼看起來會很難看，有些客戶端用新方法，有些用舊方式，但是程序依舊正常工作，測試也正常通過，你好檢驗(yàn)?zāi)愕男薷臎]有引入任何不希望的破壞。重構(gòu)都可以像這樣來拆分。嘗試拆分，盡量將工作化成可以度量的小塊兒。不要卡在中間要是開始了進(jìn)行重構(gòu)，那就進(jìn)行到底。關(guān)鍵是代碼要變清晰，但是干了一半兒的活兒通常會是舊的混亂加上新的方案混合在一起。絕對不要讓程序長時(shí)間出于這種狀態(tài)。通過重構(gòu)為實(shí)質(zhì)性修改鋪墊你是不是經(jīng)常開始做X的時(shí)候發(fā)現(xiàn)必須要先改Y才能行，而在改Y的時(shí)候，你又發(fā)現(xiàn)得先改Z，最后呢你困惑了，結(jié)果是一團(tuán)糟。我們都有過類似的經(jīng)歷，只是相對少一些而已，預(yù)先估計(jì)都需要改什么，然后先重構(gòu)，測試，提交Z，接著是Y，最后是X。這樣會得到更好的代碼，減少錯(cuò)誤，即使真的有東西弄亂了，你也更容易讓其步入正軌。別怕刪代碼人們（很可能是你）花了很多的時(shí)間去寫并不意味著是代碼一定能很好地完成既定任務(wù)。這些代碼幫助定義了任務(wù)是什么，完成此項(xiàng)任務(wù)會遇到怎樣的困難，這些都對日后的工作很有用，因此其作者的工作很值得尊敬。即使是知道了不用這么做也是很有幫助的，有時(shí)候很值得投入全部力量去寫代碼做這項(xiàng)似乎無意義的事。另一方面，無效的，廢棄的代碼只會使程序變得擁擠不堪，難于閱讀和理解，所以還是刪掉的好。要是后來你又最終決定用了，版本控制系統(tǒng)會將其完好無損的還給你。不要把應(yīng)刪掉