1、A計劃：平臺版本在v2.1版本基礎上進行遷移，逐個模塊改造，平臺1.0版本，在業務分支3.0版本之前發布，在3.x版本與其他業務版本結合； 
      B計劃：平臺版本不再單獨演進，將現在的平臺技術應用到即將發布的3.0版本中。包括插件結構、動態加載、動態激活，3.0版本中的業務模塊一律按照插件規范開發。

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

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

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

這部分改造是最不情愿的一部分，配置文件怎么會不可靠呢？是會不可靠，所以要做好兩手準備啊。最后被斃掉是因為配置文件保存功能上的一個bug，主要是因為需求不明。斃就斃了，可配置界面的邏輯有點小復雜，很佩服office的設計人員。不可否認，如果有配置文件會帶來都少便利，包括那個讓我引以為豪的預設-激活機制。
做API和做程序完全兩碼事，做程序往往會用一些比較巧妙的手段，讓變成更輕松。做API的話，過分的巧妙反而會讓二次開發的兄弟摸不到頭腦，所以更重要的是清晰、良好定義的調用過程。比如，曾經想在界面一次到位地添加一個三級菜單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);
很清晰，基本不需要解釋。寫的時候能夠多動些腦子，代碼行與一次到位地添加相當。

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