身為一個(gè)維護(hù)人員，我每天的工作就是研究產(chǎn)品的代碼，修正各種bug，或者添加各種新功能。Kent Beck在《重構(gòu)》一書中使用了一個(gè)隱喻，“壞味道（bad smell）”。用這個(gè)隱喻來形容我目前的處境，那就是我正在糞坑里掙扎。這里充斥著“Copy/Past/Modify”而來的代碼。為了實(shí)現(xiàn)一個(gè)功能而隨心所欲添加的成員變量。長達(dá)一兩千行的函數(shù)。幾萬行的類。到處都是public的成員變量。豐富多彩的編程風(fēng)格。

這個(gè)程序運(yùn)行起來很漂亮，用戶也很滿意（據(jù)說）。我想作為用戶，是不需要關(guān)心代碼如何如何的。作為老板也是不需要關(guān)心代碼如何如何的（雖然他聲稱他很在乎）。那么正真關(guān)心代碼的人是誰呢，我想來想去就是我自己，如果想改善生存環(huán)境只能靠自己。我先強(qiáng)調(diào)一下，這套代碼不是我寫的，我見到它時(shí)它已經(jīng)是這個(gè)樣子了，并且當(dāng)我提出要進(jìn)行整改時(shí)，所有人都是“能跑起來就不錯(cuò)啦，用戶又沒提，工時(shí)怎么算”。我只能作罷。我在這里不是發(fā)牢騷，牢騷我已經(jīng)在項(xiàng)目經(jīng)理那里發(fā)過了。我只是想討論一下這個(gè)“糞坑”是如何形成的，有沒有辦法避免。

先描述一下我見過的比較普遍的新增功能的過程。我們拿到用戶的修改需求后會做一個(gè)簡單的評估，一般是比較有經(jīng)驗(yàn)的程序員參加，然后給出一個(gè)簡單的修改方案，就會由一個(gè)程序員（不一定是比較有經(jīng)驗(yàn)的程序員）根據(jù)設(shè)計(jì)修改代碼。等程序員完成修改并且測試以后就會提交到項(xiàng)目經(jīng)理那里。項(xiàng)目經(jīng)理還會找人，一般是他自己，再測試幾遍。都通過了就會發(fā)送給用戶。當(dāng)然，用戶還會測試。最后是上線。

Bug修改也是差不多的流程。可以看到整個(gè)過程都在控制之中，項(xiàng)目經(jīng)理和用戶完全可以通過充分的測試來控制質(zhì)量。顯然，在這個(gè)過程中代碼的質(zhì)量并不是問題的關(guān)鍵。代碼糟糕，修改難度增加并不會導(dǎo)致用戶給更多的錢和時(shí)間，相反他們會說：“這本來就是你們的責(zé)任”。對于管理層，他們并不會去修改代碼，他們只需要驅(qū)使手下的程序員加班加點(diǎn)的“努力工作”。所以真正有切身厲害的是程序員自己，而造成這種局面的恰恰也是程序員自己。現(xiàn)在讓我們回到上面描述的流程中，好好看看最簡單的（項(xiàng)目經(jīng)理們的原話）環(huán)節(jié)，代碼修改。

這個(gè)程序員會先在代碼里確定功能的起點(diǎn)也就是啟動功能的地方，一般會從菜單入手。然后他會在代碼里尋找相似的功能，看看有沒有什么可以借鑒的。如果沒找到，就只能從頭開始編碼，但是一旦找到了（大多數(shù)情況下是可以找到的，從這一點(diǎn)就可以看出這套代碼的可怕），造糞運(yùn)動就開始了。他會把那個(gè)函數(shù)整個(gè)拷過來，仔細(xì)研究，慢慢修改，邊改邊運(yùn)行測試效果。這種方法收效甚偉，熟練工會以飛也似的速度進(jìn)行修改。再加點(diǎn)班，一般都能在用戶要求的期限內(nèi)完成。皆大歡喜。

稍微復(fù)雜的功能就需要有點(diǎn)經(jīng)驗(yàn)的程序員上了。但是操作過程與上面相仿，其實(shí)上面的操作就是這么代代相傳的。只不過有經(jīng)驗(yàn)者速度會更快，成功率會更高。但是我不得不說一句，這種方式讓人作嘔，畢竟這需要極大的耐心和細(xì)致，而且在成千上萬行代碼里上下移動滾輪很容易迷失，一天下來身心都是很疲倦的。有人搞軟件搞到猝死也就不足為奇了。

這種代碼基本上不可能自動測試，只能手動測試，測試起來非常繁瑣，對于程序員來說是很繁重的工作。很容易讓人煩躁，尤其是在加班趕進(jìn)度的時(shí)候。這種代碼會引起bug的爆炸，試想一處的bug被到處復(fù)制，而且還會引入新的Bug，后果之嚴(yán)重可想而之。這種代碼破壞了幾乎所有OO開發(fā)的原則，無法擴(kuò)展，只能修改。通過他衍生出來的項(xiàng)目變得更加無法維護(hù)。

說了這么多，現(xiàn)在說今天的重點(diǎn)，我認(rèn)為造成這種局面的原因如下：

1、 管理層不重視代碼書寫，認(rèn)為是體力勞動；

2、 項(xiàng)目經(jīng)理疲于應(yīng)付進(jìn)度，無心且無力；

3、 程序員水平參差不齊，缺乏正確的指導(dǎo)。

　　我不是老板，不能要求老板像我一樣看問題，其實(shí)想想看老板雇傭我就是讓我來給他照顧代碼的，所以我不能要求老板來幫我。項(xiàng)目經(jīng)理的職責(zé)應(yīng)該是控制項(xiàng)目進(jìn)度，協(xié)調(diào)各方關(guān)系，像代碼這種小問題也不應(yīng)該勞煩他。剩下的就是開發(fā)人員了，作為每天都在和代碼打交道的人實(shí)在沒有理由不關(guān)心代碼，實(shí)在不應(yīng)該給本來就一團(tuán)亂麻的代碼添亂。其實(shí)只要不滿足于只是完成功能（當(dāng)然對很多人來說這已經(jīng)很了不起了），完成功能之后多想一下，嘗試尋找違反“DRY”原則的地方，嘗試把平時(shí)學(xué)習(xí)的OOP知識印證到代碼里，代碼也許就能有極大提高，自己的水平也會提高。這種對代碼進(jìn)行反復(fù)批判調(diào)整的過程就叫“重構(gòu)”，前面我們提到的那本書就是對這些方法的總結(jié)和提升。當(dāng)然，要想正真掌握它并不容易，需要不斷學(xué)習(xí)，實(shí)踐和總結(jié)。但是我以為，最重要的是把重構(gòu)變成習(xí)慣。只有當(dāng)你養(yǎng)成了重構(gòu)的習(xí)慣你才算是掌握了這個(gè)工具。

養(yǎng)成重構(gòu)的習(xí)慣先要從訓(xùn)練對代碼的審美開始。經(jīng)常看到人們提到“代碼之美”，我很贊同這種觀點(diǎn)，但是對美的欣賞是一種比較高的層次。并不是每個(gè)初學(xué)者都能做到的。所以不如先學(xué)什么是“代碼之丑”。辨別代碼的丑俊有一個(gè)很簡單的辦法，尋找重復(fù)。代碼的重復(fù)，數(shù)據(jù)的重復(fù)，配置信息的重復(fù)，甚至測試發(fā)布步驟的重復(fù)反復(fù)，都是丑惡的，都要清除。其次是簡單。簡單不是直接，不是把功能代碼寫到菜單事件里就叫簡單。一開始可以這樣寫，但是要時(shí)刻提醒自己這里的代碼其他地方可能會用到，要想辦法提煉成功能明確的函數(shù)(Extract Method)。從習(xí)慣養(yǎng)成這個(gè)角度上講，我認(rèn)為程序員應(yīng)該有代碼潔癖。

在代碼品味提高之后，很自然的就會對“不美的代碼”產(chǎn)生“整容”的沖動。但是不能亂來，重構(gòu)是講求方法學(xué)的。Kent Beck說過：“我不會對無法自動測試的代碼進(jìn)行重構(gòu)”。但是現(xiàn)實(shí)并不理想，我們也不是大師，而且生活所迫，所以有時(shí)候我們只能對“無法自動測試的代碼”進(jìn)行重構(gòu)。建議大家都去讀一讀Kent Beck的《重構(gòu)》這本書。他先從方法學(xué)的角度對重構(gòu)進(jìn)行闡述，然后總結(jié)出許多實(shí)用的重構(gòu)技巧。有了思想上的武裝，重構(gòu)就會有的放矢了。

養(yǎng)成一種習(xí)慣并不容易，需要外界的壓力，需要自身的毅力，最重要的是足夠的渴望。只要你是一個(gè)想把程序員作為終身職業(yè)的人，都應(yīng)該嘗試養(yǎng)成重構(gòu)這個(gè)習(xí)慣。

it知識庫：養(yǎng)成重構(gòu)的習(xí)慣有多重要，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。