1、A計劃：平臺版本在v2.1版本基礎(chǔ)上進(jìn)行遷移，逐個模塊改造，平臺1.0版本，在業(yè)務(wù)分支3.0版本之前發(fā)布，在3.x版本與其他業(yè)務(wù)版本結(jié)合； 
      B計劃：平臺版本不再單獨演進(jìn)，將現(xiàn)在的平臺技術(shù)應(yīng)用到即將發(fā)布的3.0版本中。包括插件結(jié)構(gòu)、動態(tài)加載、動態(tài)激活，3.0版本中的業(yè)務(wù)模塊一律按照插件規(guī)范開發(fā)。

改變的原因及影響：
      認(rèn)為3.0版本再遷移到平臺上，就是變相的返工，現(xiàn)在強制遷移到平臺，可以節(jié)約這部分工期。
      現(xiàn)在強制3.0按照平臺插件規(guī)范開發(fā)，在一定程度上會拖緩進(jìn)度，也是要考慮的。
      在3.0規(guī)范中使用的是平臺最成熟也是最核心的成果，風(fēng)險相對較低。
      對平臺版本的要求，從原來的Kernal插件化要求，改為業(yè)務(wù)模塊插件化要求。原來最棘手的解耦和和插件化改造，變得不再緊急。這是一個相對成熟的改變，因為Kernal的插件化是在沒有必要。                 
      原來位于Kernal范圍的功能，部分剝離到業(yè)務(wù)相關(guān)的部分。比如工程管理、數(shù)據(jù)庫，全部改造成注冊、通知機(jī)制，而不再承擔(dān)具體的業(yè)務(wù)。這在很大程度上降低了平臺的設(shè)計復(fù)雜度和業(yè)務(wù)相關(guān)度。我認(rèn)為，這是本次修改中最有意義的部分。

      新需求的開發(fā)中比較棘手的是新業(yè)務(wù)類型的支持，要求平臺不單可以支持預(yù)定義的業(yè)務(wù)類型，還要支持業(yè)務(wù)類型擴(kuò)展（也是通過注冊機(jī)制）。從一定程度上來講，業(yè)務(wù)類型注冊和模塊的動態(tài)加載之間是有矛盾的。因為之前的設(shè)計思路并不是Eclipse的那種Lazy Load，而是PreLoad。
      如果模塊不加載，如何注冊業(yè)務(wù)呢？如果不知道支持了哪些業(yè)務(wù)，如何知道加載那些模塊呢？這中間有一個斷檔，就是預(yù)定義基礎(chǔ)上的擴(kuò)展。我想，還是通過配置文件實現(xiàn)，在原先的插件節(jié)點基礎(chǔ)上增加一級節(jié)點，用于指示業(yè)務(wù)類型。平臺掃描這一級節(jié)點，從而確定自己需要支持哪些業(yè)務(wù)類型，而并不加載。只有在工程打開確實需要那些業(yè)務(wù)類型的插件才加載，模塊加載能否成功，取決于對軟件的授權(quán)。這樣，又識別出一個對象，用于保存業(yè)務(wù)類型的狀態(tài)。
      基本業(yè)務(wù)流程是：業(yè)務(wù)類型記錄對象掃描配置文件->保存配置文件中的業(yè)務(wù)類型列表到內(nèi)存中，關(guān)閉配置文件。（有一個用于運行時切換工程業(yè)務(wù)類型參數(shù)的界面狀態(tài)，其中的業(yè)務(wù)類型是否可用的狀態(tài)，取決于該類型記錄對象的狀態(tài)。“另外，由于部分業(yè)務(wù)類型之間是互斥的，所以這部分內(nèi)容需要寫入配置文件中。”——經(jīng)確認(rèn)同行的這種互斥做法是沒有根據(jù)的。）
                                      工程打開->通知Dll Loader->Dll Loader根據(jù)工程的業(yè)務(wù)類型配置，查找內(nèi)存配置文件，加載、激活對應(yīng)模塊。
                                      工程參數(shù)修改->通知Dll Loader->Dll Loader根據(jù)工程業(yè)務(wù)類型，卸載停用模塊，加載激活、新增模塊。
                                      工程關(guān)閉->通知Dll Loader->Dll Loader卸載業(yè)務(wù)模塊。
                       

2、A計劃：CCB管理配置文件，規(guī)范插件對主界面的配置。
      B計劃：必須為界面配置文件準(zhǔn)備替代方案，防止因為配置文件損壞造成的程序加載失敗。

這部分改造是最不情愿的一部分，配置文件怎么會不可靠呢？是會不可靠，所以要做好兩手準(zhǔn)備啊。最后被斃掉是因為配置文件保存功能上的一個bug，主要是因為需求不明。斃就斃了，可配置界面的邏輯有點小復(fù)雜，很佩服office的設(shè)計人員。不可否認(rèn)，如果有配置文件會帶來都少便利，包括那個讓我引以為豪的預(yù)設(shè)-激活機(jī)制。
做API和做程序完全兩碼事，做程序往往會用一些比較巧妙的手段，讓變成更輕松。做API的話，過分的巧妙反而會讓二次開發(fā)的兄弟摸不到頭腦，所以更重要的是清晰、良好定義的調(diào)用過程。比如，曾經(jīng)想在界面一次到位地添加一個三級菜單UIConfig->AddMenu("File", "New", "New Filetype1");，這樣使用起來倒是方便，但是似乎掩蓋了過多的中間過程，比如如果"File"或者"New"不存在等等，需要諸多的解釋。
如果分成三步來做，就清晰多了。
int iFileID = UIConfig->AddSubMenu(0, "File");
int iNewID = UIConfig->AddSubMenu(iFileID , "New");
int iNewFT1ID = UIConfig->AddSubMenu(iNewID , "New Filetype1");
再來一個UIConfig->ConfigMenu(iNewFT1ID, ResponceResource);
很清晰，基本不需要解釋。寫的時候能夠多動些腦子，代碼行與一次到位地添加相當(dāng)。

對外清晰、良好的定義，可以有效降低實現(xiàn)的難度，并有助于消除bug，原因是清晰定義的函數(shù)邊界明確，有利于設(shè)計、實現(xiàn)和測試。
界面上元素的相對位置，完全靠內(nèi)部編碼邏輯結(jié)構(gòu)，直接解析出其的位置。
配置文件，可以在后續(xù)使用，作為界面調(diào)整的依據(jù)，比如供最終用戶Customize，將是很炫的功能。