【成都網站設計】擁抱變化—— 可擴展性雜談

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

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

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

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

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

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

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

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

view plaincopy to clipboardprint?01.void processSwitchEvent(GenMsg *pMsg)  02.{  03.   一些合法性判斷語句  04.   if(NEMI_SWITCH_EVENT == pMsg->getSwitchEventGrp())  05.   {  06.       MSG_INFO(“Received NEMI Switch Event……”);  07.       return ;  08.   }  09.   //process SWF Switch Event  10.   業(yè)務處理代碼  11.} void processSwitchEvent(GenMsg *pMsg)
{
一些合法性判斷語句
if(NEMI_SWITCH_EVENT == pMsg->getSwitchEventGrp())
{
MSG_INFO(“Received NEMI Switch Event……”);
return ;
}
//process SWF Switch Event
業(yè)務處理代碼
}

可能開發(fā)人員在進行if條件語句編碼時，可能還考慮了另外一種寫法：

view plaincopy to clipboardprint?
01.void processSwitchEvent(GenMsg *pMsg)
02.{
03.   一些合法性判斷語句
04.   if(SWF_SWITCH_EVENT == pMsg->getSwitchEventGrp())
05.   {
06.       MSG_INFO(“Received SWF Switch Event……”);
07.       業(yè)務處理代碼
08.   }
09.}
void processSwitchEvent(GenMsg *pMsg)
{
一些合法性判斷語句
if(SWF_SWITCH_EVENT == pMsg->getSwitchEventGrp())
{
MSG_INFO(“Received SWF Switch Event……”);
業(yè)務處理代碼
}
}

在最初的需求中，上下兩種寫法都是合適的，但是不是都合理呢？如果一旦需求發(fā)生變更，SWF卡上的另外一個業(yè)務需要關注STU板的倒換事件，那么STU板的倒換事件也會被廣播到SWF卡上，最糟糕的是，這兩個業(yè)務都訂閱了倒換事件（通過消息里面的內容來判斷是哪塊板發(fā)生了倒換），那么上下兩種寫法的區(qū)別就體現(xiàn)出來了，一個能正確運行，而另外一個會把STU的倒換事件當作SWF的倒換事件。不難看出，下面一種寫法更具有可擴展性，達到了以最小的代價去應對變化。正是這樣小的修改，往往會被忽略，隱藏一個很深的bug，導致花大量的時間去定位。

對于上述的場景，大家編碼時常會碰到，覺得這樣寫也合適，那樣寫也合適。雖然在一定條件下都很合適，但不一定都合理，那么此時就需要從其他方面加以考慮，如可擴展性，可維護性，可測試性等方面，從而確定哪種寫法更合理。

場景二：假定存在如下一個消息類，最初類中只有一個成員變量，消息類的定義和實現(xiàn)如下：

view plaincopy to clipboardprint?
01.class FsmFileTransferRequest : public GenMsgHdr
02.{
03.   public:
04.       FsmFileTransferRequest (void)
05.       {
06.           memset (&mFileTransferReq, 0, sizeof(mFileTransferReq));
07.           setMsgType (MTYPE_REQUEST);
08.           setMsgTypeQual (MQUAL_FSM_FILE_TRANSFER_REQUEST);
09.           setPayloadLen (sizeof(mFileTransferReq));
10.       }
11.
12.       // get/set operation
13.       ……
14.   private:
15.       SysPkg::FileTransferRequest   mFileTransferReq;
16.};
class FsmFileTransferRequest : public GenMsgHdr
{
public:
FsmFileTransferRequest (void)
{
memset (&mFileTransferReq, 0, sizeof(mFileTransferReq));
setMsgType (MTYPE_REQUEST);
setMsgTypeQual (MQUAL_FSM_FILE_TRANSFER_REQUEST);
setPayloadLen (sizeof(mFileTransferReq));
}

// get/set operation
……
private:
SysPkg::FileTransferRequest   mFileTransferReq;
};

對于該消息長度，基類提供了兩種接口，一個接口是 setPayloadLen ()，另外一個接口是 setMsgLen ()，該接口是更高一級的封裝，為所傳入參數(shù)減去基類消息的長度，最終結果還是消息的凈荷長度。也許有人會說，基類就不應該提供兩套函數(shù)，讓人迷惑，出錯在所難免。

由于場景變化或者需求變更，需要在該類中添加其他的成員變量，維護者可能是這個系統(tǒng)中的另外一個模塊的開發(fā)者（自己所負責的模塊中，構造函數(shù)里都是用消息總長度函數(shù)，默認其他開發(fā)者跟他一樣），添加了成員變量和實現(xiàn)后，忘記修改消息的凈荷長度，編譯并運行，結果與預想的大相徑庭，于是開始不停的打斷點調試，不斷的在懷疑消息是不是丟了，或者沒有用修改的代碼進行編譯，總之，一切該懷疑的都在腦海中閃現(xiàn)了一遍。

或者，意識到要修改消息凈荷長度，于是修改成：

view plaincopy to clipboardprint?
01.setPayloadLen (sizeof(mFileTransferReq)+sizeof(mSuccessfulFlag));
setPayloadLen (sizeof(mFileTransferReq)+sizeof(mSuccessfulFlag));

如果只是一兩個成員變量，還能忍受。需求一再變更，又增加了幾個成員變量，繼續(xù)修改，setPayloadLen()里面的代碼會越來越長，只是代碼寫的難看而已。

如果類的實現(xiàn)者，在編寫代碼時，考慮一下可擴展性，采用消息的總長度函數(shù)，那么不論怎么添加成員變量，都不用修改消息長度，一勞永逸。如果確認這個消息不會被擴展，采用 setPayloadLen()也是合理的。

通過以上兩個例子可以發(fā)現(xiàn)，如果在編碼時，充分考慮了編碼可擴展性，即使需求發(fā)生變更，有時也可以達到事半功倍的效果。關鍵問題是如何識別出這樣的場景，這個只能靠經驗了，沒有捷徑可走！

本文標題：【成都網站設計】擁抱變化—— 可擴展性雜談
網頁URL：http://m.newbst.com/news29/181479.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網站收錄、搜索引擎優(yōu)化、移動網站建設、做網站、網站策劃

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)