老實說，文章的描述和之前的經歷如出一轍。
個人獲得的經驗就是，壞的架構所引起的代碼dirty就沒有重構的價值了。
如果把一個項目的代碼描述成一個蘋果，爛代碼就像是出現腐敗的區域，如果一個蘋果只有一小塊出現變質還可以削掉，如果整個蘋果都爛掉了，那就只好扔掉。
而文章中描述的情況正像是完全腐爛的蘋果，重構代碼的人正試圖削掉蘋果的腐爛部分。結果削着削着發現，整個蘋果都是壞的。
蘋果壞了可以扔掉，但是對於一個項目來說，卻沒有辦法放任存在潛在BUG 的代碼，這就是最困難的地方。
從公司層面，不如勇敢一些更新換代產品，當然，前提是從這個腐爛的代碼上總結失敗的經驗，運用科學的生產方法，這樣的產品才更有保證。
當然，腐爛代碼產生的原因是多方面的，樂觀一點來分析，架構的設計初衷和產品的發展產生了偏離，開發人員經驗不足，項目工期太趕等等。。。。。。
寫了一會兒，突然發現代碼的生成和城市的建設發展有一定相似性：
1、規劃的結果往往不能盡善盡美；
2、都需要持續改進；
3、時代的發展總會導致某些功能的不合時宜；
4、一定程度上都有工期的要求，不可避免的存在趕工；
5、某些功能都會存在BUG(城市內澇，代碼crush)；
6、都需要在整個過程中存在富有極度責任心的人才能完成工作；
總之，希望軟件設計的方法越來越成熟，普及的越來越廣泛，讓軟件生產方式變得可控，有效率，可維護。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
下面是轉載文章：(包含轉載的轉載)
轉載鏈接：
http://blog.csdn.net/ceofit/article/details/7777154
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
對於敏捷的重構，個人一直抱有懷疑的態度。原因如下：
1、架構性的不合理不指望後期的迭代能夠有勇氣和時間去重構。
2、前期的編碼，後期遇到大量的需求變更或問題修復導致代碼面目全非，到處都是坑，很多代碼大部分人不知道爲何如此。誰敢重構？
3、當前持續集成的版本至少可以正常運行，功能也可以保證，於是不敢進行大範圍的重構。還是那句話：坑太多。
個人覺得大範圍重構的這份勇氣、魄力和責任大部分人都沒有，而且迭代緊緊張張的也沒時間去重構。
所以敏捷過程中重構多見於功能塊的重構、代碼級重構。結構不敢動，補丁不敢動。長此以往，坑越來越多，耦合性越來越強，代碼越來越混亂...
聲明：下面是原文，轉載自http://coolshell.cn/articles/5201.html
你曾去想重構一個很老的模塊，但是你只看了一眼你就噁心極了。文檔，奇怪的函數和類的命名，等等，整個模塊就像一個帶着腳鐐的衣衫襤褸的人，雖然能走，但是其已經讓人感到很不舒服。面對這種情況，真正的程序員會是不會認輸的，他們會接受挑戰認真分析，那怕重寫也在所不惜。最終那個模塊會被他們重構，就像以前和大家介紹過的那些令人銷魂的編程方式中的屠宰式編程一樣。下面是重構代碼的幾個階段，文章來自：The 7 stages of refactoring，下面的翻譯只是意譯。
第一階段 - 絕望
在你開始去查看你想要重構的模塊的，你會覺得好像很簡單，這裏需要改一個類，那裏需要改兩到三個函數，重寫幾個函數，看上去沒什麼大不了的，一兩天就搞定了。於是你着手開始重構，然後當你調整重構了一些代碼，比如改了一些命名，修理了一些邏輯，漸漸地，你會發現這個怪物原來體型這麼大，你會看到與代碼不符甚至含糊不清的註釋，完全摸不着頭腦的數據結構，還有一些看似不需要方法被調了幾次，你還會發現無法搞清一個函數調用鏈上的邏輯。你感到這個事可能一週都搞不定，你開始絕望了。
第二階段 – 找最簡單的做
你承認你要重構的這個模塊就是一個可怕的怪物，不是一兩下就可以搞定的，於是你開始着幹一些簡單的事，比如重新命名一下幾個函數，移除一些代碼的阻礙，產生幾個常量來消除magic number，等等，你知道這樣做至少不會讓代碼變得更糟糕。
第三階段 – 再次絕望
但是接下來的事會讓你再次撞牆。你會發現那些代碼的瑕疵是些不痛不癢的事，改正這些事完全於事無補，你應該要做的事就是重寫所有的東西。但是你卻沒有時間這麼幹，而這些代碼剪不亂理還亂，耦合得太多，讓你再一次絕望。所以，你只能部分重寫那些不會花太多時間的部分，這樣至少可以讓這些老的代碼能被更多的重用。雖然不完美，但是至少可以試試。
第四階段 – 開始樂觀
在你試着部分重構這個模塊幾天之後，隨着重構了幾個單元后，雖然你發現改善代碼的進度太慢了，但此時，你已知道代碼應該要被改成什麼樣，你在痛苦之後也鎖定了那些那修改的類。是的，雖然你的時間預算已經超支，雖然要乾的事比較多，但你還是充滿希望，覺得那是值得的。你胸中的那團火又被點燃了。
第五階段 - 快速了結
在這個時候，你發現你已花了太多的時間，而情況越來越複雜，你感到你所面對的情況越來越讓你越到不安，你明白你自己已經陷入了困境。你原本以爲只需要一次簡單的重構，然而現在你要面對的是重寫所有的東西。你開始意識到原因是因爲你是一個完美主義者，你想讓代碼變得完美。於是你開始在怠慢你文檔，並想找到一個捷徑來重寫老的代碼，你開始採用一些簡單而粗暴，快速而有點骯髒的方法。雖然不是很完美，但你就是這樣去做了。然後，你開始運行測試做UT，發現UT報告上全是紅色，幾乎全都失敗了，你恐慌了，於是快速地fix代碼，然後讓UT 能工作。此時，你拍拍自己胸口，說到，沒問題 ，於是就把代碼提交了。
第六階段 – 修改大量的Bug
你的重寫並不完美，雖然其過了測試，但是那些UT測試對於你的新的代碼有點不太合適，雖然他們都沒有報錯，但是他們測試得範圍太小了，沒有覆蓋到所有的情況和邊界。所以，在這以後，你還需要幾周或是更長的時間不得不來修正越來越多的bug，這使得你的設計和代碼在每一次quick-fix後就變得越來越難看。此時，代碼已經不像你所期望的那樣完美了，但你依然覺得他還是比一開始要好一些。這個階段可能歷經幾個月。
第七階段 - 覺悟
經過了6個月，你重寫的模塊又出了一個比較嚴重的bug。這讓你重構的那個模塊變得更難堪。你發現出的這個問題是和當初的設計不一致，你還發現被你重構掉的那段老的代碼並不是當初看上去的那麼壞，那段老的代碼確實考慮到了一些你未曾考慮到的事情。這個時候，你團隊裏有人站出來說這個模塊應該被重構或是重寫，而你卻不動聲色地一言不發，並希望那個站出來的人能在幾個月後能覺悟起來。
——————
不知道這是不是你的經歷，我經歷過很多次這樣的事。對於很多維護性質的項目，我犯過的錯誤讓我成了一個實實在在的保守派，我幾乎不敢動，那怕看到代碼很不合口味。當然，那些從來沒有寫過代碼的敏捷諮詢師一定會說用TDD或是UT可以讓你的重構更有效也更容易，因爲這樣會讓他們顯得更我價值，但我想告訴你，這種脫離實際的說法很不負責任，這就好比說—— 我在殺豬的時候遇到了一些麻煩，因爲我對豬的生理結構不清楚，或是這本來就是一頭畸形的豬，導致我殺的豬很難看，而偉大的敏捷諮詢師卻告訴我，要用一把更快更漂亮的刀。軟件開發永遠不是那麼簡單的事，殺豬也一樣。