记一次会议，我提出插件化的想法，有支持也有反对，其中“系统架构师”表示插件化后的项目没什么意义，今天来讨论项目是否需要插件化的一些观点。
项目背景
公司内部“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，在实际使用过程中可能会被墙。
