版權聲明：本文爲博主原創文章，遵循 CC 4.0 by-sa 版權協議，轉載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/zhaoenweiex/article/details/73724658
前言
上週組織團隊對一個遺留系統進行架構重構，發現了一個模塊是典型的大泥球架構，極難重構，本文將回顧大泥球的形成的主要過程，以便大家儘量避免大泥球架構帶來的傷害。
大泥球？
大泥球，是指雜亂無章、錯綜複雜、邋遢不堪、隨意拼貼的大堆代碼。
儘管涌現出各種鼓勵、促進良好結構代碼的開發方法，軟件技藝運動也在不斷成長，但是“大泥球”仍然是最常見的軟件設計，即使人們已經從過去惡劣的設計中學到了東西，但在新的開發過程中，大泥球仍未消失。
爲什麼不？
爲什麼大泥球的架構不好呢？下面是幾個最爲直接的因素：
1. 可維護性，什麼會阻止你修復系統bug，大泥球架構是一個很好的理由，牽一髮而動全身的感覺不是一般的酸爽。
2. 可靠性，如果軟件的全部耦合在一起，牽一髮而動全身那麼其面對異常情況是是很難做到高可靠的。
3. 可修改性，對於軟件來說唯一不會變化的事情就是變化本身，因此軟件的修改或調整是不可避免的，大泥球架構會令你望而卻步。
4. 可繼承性，軟件不可能由同一個軟件團隊一直維護下去，人員的更替是不可避免的，大泥球架構往往意味着人員掌握着軟件真實的設計，新團隊接手後往往選擇重新開發。
大泥球的是如何滾動的？
說起我們的這個大泥球項目可是有歷史了，項目在13年就開始了，在14年底上線，經過近三年的更新維護，在不知不覺中就滾成了一個讓人歎爲觀止的大泥球。
項目分爲兩個階段:
開發階段
作爲一個典型的政府主導的新型行業性項目，在需求沒有一片模糊的情況下，直接上馬也是斯通見慣了。
由於缺乏有效輸入，也沒有專人負責，用戶方只有高級領導的情況下，我們採用了原型設計的方式啓動了項目，通過mockup構建示意性界面梳理業務模式，在通過Axure製作高保真的界面確認需求，經過長達半年的需求分析和討論，我們又用了三個月構建出了系統的第一個版本，又經過幾輪討論和三個月的時間，系統順利驗收和開始試運行，這時一切都美的如同神話。我們高效，深得用戶歡心。
維護階段
項目開始試運行就不是那麼順利的了，由於前期在需求分析時完全不知道還有一幫實際使用系統的丙方的存在，在推廣會上被一通噴，直接用戶也是立即變了臉色要求系統快速更新以適應業務需求。沒辦法這個鍋確實應該背，做了近半年的需求分析竟然沒有徹底摸清干係人，也是醉了。
於是大泥球開始滾動起來了，根據用戶的強烈反應，我們制定了高強度快節奏的開發計劃，每週進行迭代，每週進行系統更新和收集用戶反饋。
就這樣每週都有新的業務需求變更涌入開發功能列表，每天都有新的開發任務，在高強度的業務壓力下，其他的一切都不那麼重要了。
於是下面的現象開始出現：
- B模塊出現了A模塊類似的業務需求，時間那麼緊顧不了那麼多了，直接把代碼copy過來改一下就ok了；
- 什麼單元測試？哪有時間搞那玩意，明天系統就要更新了，我這還有一個功能點沒實現呢，最後人工測一下好了。
- 什麼C模塊也要實現空間統計分析功能，什麼明天有領導要看，好吧，那我就直接把A的代碼直接複製到C這好了，數據結構也跟A保持一致就好了。
- 這段代碼這麼寫好像有問題，加個註釋吧，以後再來解決。
時間的力量是驚人的，直接到一個月之前我發現代碼重複度至少達到了20%，能把整個系統結構說清楚的人不超過1個，對系統瞭解超過50%的人不超過2個，系統要依賴源碼來運行因爲tomcat總是因爲不知名的原因掛掉。
好在上天還是眷顧我們的，這個系統表面上還是正常。
原因回顧
需求碎片式增長
只關心是否能夠運行
高強度的業務壓力
導致結果：
沒有精力關心質量
Copy/paste導致問題轉移（有問題的代碼被複制到很多地方，不斷蔓延）
我們不知道現狀到底有多糟糕
應對架構變化過晚
總結
除非你能確定你的軟件不會有任何修改或任何人使用，那麼大泥球的軟件是可以接受的。
最後的總結
- 別把計劃排的太滿
- 防止溫水煮青蛙，任何大泥球都是經過長時間的滾動形成的，沒人想設計一個大泥球架構的軟件。
- 設置代碼質量監控，不要留破窗戶
- 保持代碼整潔，離開時要比進入時乾淨
---------------------
版權聲明：本文爲CSDN博主「zhaoenweiex」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zhaoenweiex/article/details/73724658