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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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