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

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

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

　　關于可擴展性， 其本身就是一個多方面的概念集合。有人說程序的可擴展性必須建立在對未來需求的準確把握上，也有人說程序的可擴展性必須建立在能夠?qū)π枨笞兓焖夙憫稀２徽撌胧鞘敕牵渥罱K目的都是要求，能在需求發(fā)生變化的時候以最小的代價去應付變化。

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

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

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

　　場景一：在某嵌入式電信級設備整框分布式環(huán)境中，有NEMI板（管理板），SWF板（業(yè)務板），STU板（業(yè)務板）和LC板（業(yè)務板），每塊板上都有CPU，運行著各自的程序。目前的架構(gòu)僅僅對NEMI/SWF/STU板支持了HA(HighAvailable)功能，在SWF卡上運行的某個業(yè)務，需要關注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  
    業(yè)務處理代碼  
}        

        

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