記一次會議，我提出外掛化的想法，有支援也有反對，其中“系統架構師”表示外掛化後的專案沒什麼意義，今天來討論專案是否需要外掛化的一些觀點。
專案背景
公司內部“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，在實際使用過程中可能會被牆。