程序可修改性非常重要，畢竟世界總是動態變化的，以前寫的程序在新條件下可能不滿足需求，也有可能程序需求在初始階段並沒有搞明白，后來就越來越清楚了。總之，程序需要被修改或者直接重寫。如果總是重寫，從零開始，成本是很大的。如果有之前的積累，至少和別人相比，起點也會高些。但是，如果程序可修改性太差，也有可能會讓我們陷入泥潭，還真不如輕裝上陣來的自在！
首先，怎么才算可修改性高呢？我覺得有兩個指標：
一、修改本身實現起來容易
二、修改不影響程序其他部分
下面，我們看看為了實現這些目標，都有什么策略。修改本身容易，我覺得分為兩種情況：
(1) 任務量減少了
(2) 任務量不變，但效率提高了
減少任務量
怎么讓一個修改的任務量減少呢？可能是一個好的主意讓任務量減少，比如說《五軍之戰》，目標是矮人要擊敗半獸人，怎么辦，可以硬抗，但是任務量大，還不一定抗得住；電影里面，是擒賊先擒王，任務量不知道少了多少個等級，結果還勝了。還有一個辦法就是復用，利用以前的工作，使得本次任務量降低。總結起來就是：
a) 一個好主意，使得任務量變低
b) 復用，總任務量不變，但本次任務量降低了
一個好主意，可遇而不可求，我們也不做苛求，所以減少任務量的主要辦法就是復用。復用說起來容易，實現起來實際上很難的，並且要克服自己的直覺習慣，每次實現的時候，要想想哪些可以復用。可以參考設計模式來獲得更多復用的靈感。
提高效率
任務量不變情況下，提高效率，我覺得有兩種辦法：
a) 自動化
b) 並發
自動化，是利用工具或者腳本來代替我們工作，從而提高效率。甚至有一些更高級的，比如說一些uml工具可以自動生成代碼等等。要支持並發，其實也離不開自動化工具，多個自動化工具同時進行，效率會大幅提升。只不過需要任務的基礎架構支持並發。
依賴穩定
第二個指標是修改不影響程序其他部分，可以把它分為三種情況：
(1) 修改和其他部分獨立
(2) 就是不獨立，想連部分保持不變
(3) 實在要變，把影響降到最小
我們先來說第一個，修改和其他部分獨立，換種說法就是其他部分不依賴修改部分。這里有一些基本原則，可以遵守：高層模塊不應該依賴底層模塊，抽象不應該依賴細節，細節應該依賴抽象。簡單來說就是容易變的應該依賴不怎么變的。比如說有兩個不同對象a,b。它們如果要互相通訊，有三種辦法：
a) a 調用b，b調用a
b) a 調用b，a 監聽b事件，收到b的信息
c) b 調用a, b監聽a事件，收到a的信息
如果圖簡單方便的話，a）是首選，也是直覺上的自然選擇。如果稍加考慮，看看依賴關系，比如說b是容易變的，此時不應該讓a依賴b發生，所以最后就應該選c）。
接口編程
如果實在要依賴，那么就要依賴接口，並且保持修改的時候，接口保持不變。在設計模式中，實現了變化，但是接口卻保持不變的有幾個相關模式，比如：適配器、裝飾器、代理等等。
影響最小化
最后，實在沒辦法，接口也要變。一種辦法是把變化封裝到一個模塊內，這就涉及到基本功，類設計的時候，按照職責分配，提高內聚性，並把模塊粒度控制在一個合理的大小范圍內。第二個辦法是基於外部的，利用中介把外部幾個都依賴修改的轉換成都依賴中介，然后讓中介一個依賴修改。不過，這個設計需要前期判斷，覺得哪個地方出現變化的概率大，不然會出現很多無用功。