公司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，在实际使用过程当中可能会被墙。