公司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
PS.這兩個鏈接鏈向的是同一個地址，第二個為簡短的Url，在實際使用過程中可能會被墻。
