【成都網(wǎng)站設(shè)計(jì)】擁抱變化—— 可擴(kuò)展性雜談

作為軟件開(kāi)發(fā)人員最擔(dān)心的就是變化，因?yàn)橐坏┳兓馕吨约旱拈_(kāi)發(fā)任務(wù)加重， 輕則修改代碼，重則修改框架，如果不用做任何修改，則皆大歡喜，現(xiàn)實(shí)告訴我們，這是小概率事件，但比買(mǎi)彩票中大獎(jiǎng)的概率還是大很多。于是各種討論開(kāi)始，開(kāi)發(fā)人員開(kāi)始講述修改如何的大，進(jìn)度如何緊張，架構(gòu)師也在一旁不停的嘮叨這個(gè)修改點(diǎn)的重要性，以及對(duì)整個(gè)系統(tǒng)帶來(lái)的好處。

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

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

關(guān)于可擴(kuò)展性， 其本身就是一個(gè)多方面的概念集合。有人說(shuō)程序的可擴(kuò)展性必須建立在對(duì)未來(lái)需求的準(zhǔn)確把握上，也有人說(shuō)程序的可擴(kuò)展性必須建立在能夠?qū)π枨笞兓焖夙憫?yīng)上。不論熟是熟非，其最終目的都是要求，能在需求發(fā)生變化的時(shí)候以最小的代價(jià)去應(yīng)付變化。

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

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

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

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

view plaincopy to clipboardprint?01.void processSwitchEvent(GenMsg *pMsg)  02.{  03.   一些合法性判斷語(yǔ)句  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è)務(wù)處理代碼  11.} void processSwitchEvent(GenMsg *pMsg)
{
一些合法性判斷語(yǔ)句
if(NEMI_SWITCH_EVENT == pMsg->getSwitchEventGrp())
{
MSG_INFO(“Received NEMI Switch Event……”);
return ;
}
//process SWF Switch Event
業(yè)務(wù)處理代碼
}

可能開(kāi)發(fā)人員在進(jìn)行if條件語(yǔ)句編碼時(shí)，可能還考慮了另外一種寫(xiě)法：

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

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

對(duì)于上述的場(chǎng)景，大家編碼時(shí)常會(huì)碰到，覺(jué)得這樣寫(xiě)也合適，那樣寫(xiě)也合適。雖然在一定條件下都很合適，但不一定都合理，那么此時(shí)就需要從其他方面加以考慮，如可擴(kuò)展性，可維護(hù)性，可測(cè)試性等方面，從而確定哪種寫(xiě)法更合理。

場(chǎng)景二：假定存在如下一個(gè)消息類(lèi)，最初類(lèi)中只有一個(gè)成員變量，消息類(lèi)的定義和實(shí)現(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;
};

對(duì)于該消息長(zhǎng)度，基類(lèi)提供了兩種接口，一個(gè)接口是 setPayloadLen ()，另外一個(gè)接口是 setMsgLen ()，該接口是更高一級(jí)的封裝，為所傳入?yún)?shù)減去基類(lèi)消息的長(zhǎng)度，最終結(jié)果還是消息的凈荷長(zhǎng)度。也許有人會(huì)說(shuō)，基類(lèi)就不應(yīng)該提供兩套函數(shù)，讓人迷惑，出錯(cuò)在所難免。

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

或者，意識(shí)到要修改消息凈荷長(zhǎng)度，于是修改成：

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

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

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

通過(guò)以上兩個(gè)例子可以發(fā)現(xiàn)，如果在編碼時(shí)，充分考慮了編碼可擴(kuò)展性，即使需求發(fā)生變更，有時(shí)也可以達(dá)到事半功倍的效果。關(guān)鍵問(wèn)題是如何識(shí)別出這樣的場(chǎng)景，這個(gè)只能靠經(jīng)驗(yàn)了，沒(méi)有捷徑可走！

網(wǎng)站欄目：【成都網(wǎng)站設(shè)計(jì)】擁抱變化—— 可擴(kuò)展性雜談
文章位置：http://jinyejixie.com/news/181479.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、標(biāo)簽優(yōu)化、動(dòng)態(tài)網(wǎng)站、關(guān)鍵詞優(yōu)化、微信小程序、企業(yè)網(wǎng)站制作

廣告

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