在系統重構過程中，系統改造強度一步一步強大，原有程式差異越來越大，引入新的BUG風險越高一步一步加大。 避免有效系統重構帶來風險：時間計劃與版控加強管理。 時間上將重構每個步驟劃分不同時間點(第一步與第二步合併成一個節點)，每個時間點完成該步驟工作，在節點結束時打基線，形成一個獨立版本。 好處：後面重構遇到重大BUG可以回到某個基線點，確保重構工作不至於失敗，同時系統需要發佈，產品經理一步一步逐步發布版本，使重構逐步展開。 在前面步驟解決程式復用率，後續可以考慮系統擴展問題，主要目的可以更輕鬆應付系統需求變更，提升系統易變更性。 程式可擴展性的一般原則 預先進行可擴展性設計不要太多 需要進行設計前，應客觀評估該功能日後的可能性，針對可能性較大需求變更進行預先可擴展性設計。 常見可擴展設計在淤求變更到來才進行 運用兩頂帽子設計模式，先對原程式進行可擴展設計，再加入新的、要實現的功能。 開放—封閉原則與客擴展點設計 OCP設計原則：開發的軟體系統，對於功能是開放的。 當系統需求發生變更時候，可以針對軟體功能進行擴展，滿足新的需求，同時對軟體的修改是封閉。 這邊的意義是修改程式是無可避免，透過修改程式來實現新需求，關鍵新需求修改程式碼時候同時修改原有功能類別，勢必會為原有功能，引入BUG的風險。 上述的解法式，在不修改原有程式碼過的基礎上實現新功能。 常見問題：要實現新的功能必然會改到原有程式碼，但又不能修改原有程式碼，關鍵在於原有程式碼與新程式有效隔離。 為了保證原有功能不受影響，我們不能修改原有程式，但為了新的功能，我們可以增加新的類別，這是OCP原則關鍵所在。 以系統匯出功能為例 if(type =="All") { //全部匯出 } else if(type == "exportChoosen") { //選擇匯出 } else if(type == "exportOnePage") { //本頁匯出 }
大話重構 關於小步快跑 時間緊，少做 時間充裕，多做 發現問題可以退回上一版本，因為有版控 重構步驟：採用一步一步，逐漸小修改向大修改深化，分解大函數在類別內部進行小修改，拆大物件在不動用原有程式下，進行類別之間修改，在原有程式碼基礎提高程式複用率。 關於程式碼重複與DRY原則
大話重構 物件的演進 大物件和大類別的進化過程：遺留系統的大物件(類別)是伴隨業務系統逐漸成長出現)。 筆者覺得有意思的是文中提到，客觀規律-人的大腦認識的事物是一個由簡單到複雜的過程，這是客觀規律。 內容用了開立發票類別的演進，也是筆者最常遇到一個類別的演進過程。 上述演進過程反映出，實際最常見的困境： 超級大類別中的方法越來越多，方法底下夾雜一堆各種條件和迴圈的結構。 程式變得難理解。 看不懂代碼和夾雜一堆程式沒有結構狀況下，交付生產下降。
大話重構 關於遺留系統 筆者看軟體退化重災區挺有感，任何工程師都會遇到遺留系統問題，筆者遇過某個資訊系統，欄位資料表都是用代號以及代號名稱來處理，這是非常嚴重情形，筆者曾經改過小需求，實際修改要半天，一點都不誇張，你覺得改一個欄位很快… 是的，非常快! 但你要知道修改這欄位，會遇到狀況有下列情形： 要牽動多少地方? 花多少時間理解? 改的只是這部份，其他部分異動會有多少?(註記：改的只有這畫面，其他畫面或是其他系統呢?) 改了程式，風險值多大?(要有心理準備被砲的準備)
你不能沒有保險索 書中提及的針對軟體系統進行大範圍的、大幅度改動、就會造成毀滅性的結果，很多人不敢嘗試系統重構的原因。 在筆者實務上很常見系統的祖產是家常便飯，因為這種系統改動幅度風險相當高，即便採用【小步快跑】也一定有風險… 在書上提及的部分：這個保險索就是重構後的正確測試方法。 不改變軟體的外部行為，功能層面來看以下為： 重構前，使用者什麼樣的功能，重構應當提供同樣的功能 重構前，輸入什麼樣的請求得到運算結果，重構後也應得到相同的結果 筆者曾經在改寫vb 6轉移.
該篇開頭提到一點：一名優秀開發人員，重構應當成為一種習慣。 大佈局你傷不起 很多公司都會有維護多年的大系統，會有以下問題 程式碼很亂 開發人員換很多任、維護工作越來越困難 文件不齊全 從過去瀑布開發週期長狀況下，需求→設計→開發→測試→交付，在整整數個月開發，無法知道對不對…成功失敗各佔50% 成功的專案管理，就是將失敗降到最低…