作為軟件開發人員最擔心的就是變化，因為一旦變化，意味著自己的開發任務加重， 輕則修改代碼，重則修改框架，如果不用做任何修改，則皆大歡喜，現實告訴我們，這是小概率事件，但比買彩票中大獎的概率還是大很多。于是各種討論開始，開發人員開始講述修改如何的大，進度如何緊張，架構師也在一旁不停的嘮叨這個修改點的重要性，以及對整個系統帶來的好處。

　　在業界曾經有一句很經典的話：“在軟件開發領域中，唯一的不變就是變化” 。一旦變化，就有人遭殃，不是開發人員，就是設計師或架構師。無論誰遭殃，都不得不擁抱變化。

　　擁抱變化是極限編程（eXtreme Programming）里面一個非常重要的概念，代表了敏捷陣營對于變化的一種態度，那就是不拒絕，而且還主動求變。本文不想探討敏捷方面的知識，如何去擁抱變化，而是想要探討程序的可擴展性，如何在編碼過程中，以最小的代價來應對程序未來的變化。

　　關于可擴展性， 其本身就是一個多方面的概念集合。有人說程序的可擴展性必須建立在對未來需求的準確把握上，也有人說程序的可擴展性必須建立在能夠對需求變化快速響應上。不論孰是孰非，其最終目的都是要求，能在需求發生變化的時候以最小的代價去應付變化。

　　可以從兩個緯度對可擴展性進行討論，一是設計可擴展性，二是編碼可擴展性，前者從宏觀上考慮，后者從微觀上考慮，當然編碼也是一種設計活動。本文重點論述編碼的可擴展性，對于設計可擴展性，是一個系統性工程，由于作者還沒有達到那個高度和境界，所以不敢瞎寫，本文基本上不做介紹。

　　《UNIX 編程藝術》一書中有一條關于擴展原則的描述：設計要著眼于未來，未來總比預想快。 關于設計可擴展性， 對于系統架構師或者系統工程師不僅僅要考慮在實現用戶需求的基礎上如何構建系統，還要考慮計算資源的可擴展、應用規模的可擴展，以及對技術換代的可擴展和性能等。

　　近期發生的干旱和水災，每次都能找到人為的因素。本文開頭提到的場景，如果進行代碼回溯，也能找到一些人為的因素。如果當時的編碼者在寫代碼時充分考慮了代碼可擴展性，在一定條件下，可以達到用最小的代價去應對變化。如果當時只是為了完成任務，交差，后續的維護者可能面對的不是擁抱變化，而是擁抱痛苦！

　　場景一：在某嵌入式電信級設備整框分布式環境中，有NEMI板（管理板），SWF板（業務板），STU板（業務板）和LC板（業務板），每塊板上都有CPU，運行著各自的程序。目前的架構僅僅對NEMI/SWF/STU板支持了HA(HighAvailable)功能，在SWF卡上運行的某個業務，需要關注SWF卡的主備倒換事件。 運行在SWF卡上的程序可以收到來自NEMI和SWF卡的主備倒換事件，于是進行了如下編碼：

void processSwitchEvent(GenMsg *pMsg)  
{  
    一些合法性判斷語句  
    if(NEMI_SWITCH_EVENT == pMsg->getSwitchEventGrp())  
    {  
        MSG_INFO(“Received NEMI Switch Event……”);  
        return ;  
      
    //process SWF Switch Event  
    業務處理代碼  
}        

        

        
        
      
        
it知識庫：擁抱變化—— 可擴展性雜談，轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。