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

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

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

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

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

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