公司ERP系統重構那些事

    記一次會議，我提出插件化的想法，有支持也有反對，其中「系統架構師」表示插件化後的項目沒什麼意義，今天來討論項目是否須要插件化的一些觀點。

項目背景

    公司內部「ERP」系統，其職責以遠遠超出ERP，更像公司內部信息管理系統，如下簡稱公司ERP或公司ERP系統。公司ERP系統是C/S架構，除了用戶控件以外系統內部實現沒有分層，以文件夾的形式維護着一個個業務模塊的功能。

    這個系統除了包含了ERP系統的基本功能外，還須要維護公司內部電商網站的數據（網站後臺的一些功能被搬到C/S上），客服管理等等的功能。

    值得一提的是，公司ERP系統爲了安全考慮將數據訪問以Web Services向外部公開，Web Services內部實現安全認證（IP認證、MAC認證等），這樣作的優缺點或者說有用沒用咱們先不考慮，只是讓你們瞭解下有這麼一出事情。

    因爲項目日漸龐大，維護成本極高，編譯時間>3分鐘（不能確保必定能編譯過），致使了開發和測試過程當中嚴重的時間消耗，公司決定重構該項目。

一提插件化想法

    大約在2個月前，我首次提出了插件化的想法，「系統架構師」以咱們的項目不必弄的這麼複雜拋棄了插件化開發模式，當時手上沒有完善的Demo和文檔再加上本人的口才也不是很好，就暫時的沒有捲入與其討論。

二提插件化想法

    距離上一次提插件化已過去了一個多月，這段時間，我努力完善Koala Framework，以儘早的展示出完善的插件機制一次，這一次我作足了工做，畫了當前狀況的 開發 - 測試 - 發佈流程圖和插件化以後的 開發 - 測試 - 發佈的流程圖，寫了一份「插件式開發模式討論會」的PPT，花了一個下午的時間寫了一個ERP Demo。Demo的截圖能夠看：Koala Framework是什麼？我爲何要寫這個框架？中的Koala Framework Demo一節。

現狀發佈流程圖

紅色爲最耗時部分，黃色爲插件化後能夠省去的部分。

插件化後的發佈流程圖

    從圖中能夠看出，插件化以後與其測試、客戶端交互的是插件服務器（實質爲DLL文件），而不需再去依賴代碼，也就是說只有在開發階段纔會依賴代碼，依賴編譯工具，其餘階段用來交互的只是DLL文件，測試無需再去關心，編譯環境，編譯配置，他們所須要作的只是更新來自開發人員的插件，用來進行功能測試，有問題通知開發人員這一過程，我的認爲大大的下降了交流的次數。

提議未果

    插件化後的項目結截圖：

   

    在這一次交流過程當中發現本身已不想再去爭論插件化與日常開發的一些優劣了，或許是對如今的「系統架構師」再也不抱有什麼能夠溝通的指望，也不想再與他爭論些什麼了吧，這一次如今的「系統架構師」仍是以爲插件化沒有必要，當實現有變動的時候把變動的實現類Copy - Paste - 編譯一下發布就行了。想起以往討論的種種實在以爲悲催，一個要跟他去解釋在系統構建中實體優於DataSet、DataTable，同類型不一樣實例的對象的GetHashCode()方法返回的值是不一致、服務端到客戶端通過WCF以後實例是不一致的（省略N件事情）「系統架構師」實在是沒有在溝通下去的必要。

內心的那桿秤

    是否全部的項目都合適去插件化？

    這邊不繞彎子，給出我的的一些想法：若是一個項目須要長期的維護那麼這個項目就應該被插件化。

    上面主要講述了一些插件化的優點，物極必反，任何東西都有好的一面和壞的一面，插件化也不是完美的他也有很差的那一面，若是項目比較小，可能作完之後就再也不須要維護那麼就徹底不須要插件化。

支持插件化不表明所有插件化

舉個例子（可能不太恰當但天資聰慧的大家確定能夠理解，哈哈）

支持插件化：Windows操做系統，你能夠選擇是否去安裝軟件，它自己支持軟件（插件）安裝。

所有插件化：系統自帶的計算器算是Windows操做系統裏面的一個軟件（插件），但裏面的+、-、*、/等算法不必定是插件化方式實現的。

提到的那些文檔

文件：插件式開發模式討論會、發佈流程圖

https://skydrive.live.com/redir?resid=4536D446A0E85208!2338&authkey=!AL-Eafwz09-bZMs

http://sdrv.ms/18EZrP2

PS.這兩個連接鏈向的是同一個地址，第二個爲簡短的Url，在實際使用過程當中可能會被牆。