老板认为插件式开发等于不用写代码，程序员：这是想把我也省了？

有个不懂技术的老板真是灾难！我前老板希望我做个框架，不希望每个项目代码都需要重新写，这样非常耗时间，人力成本非常大，于是我就说那我就写个通用框架吧，把一些通用性的东西封装起来，下次要用的时候直接配置一下最后反射就可以了，但是，在老板心里，他的却想歪了！

老板心里想的是，写过的代码写过一次就不用写了，所以，事情越往最后，写得代码越少，直至最后一行代码都不需要要写，直接配置配置，程序就出来了！

我在上家公司的时候推进了这个事情的发展，并且亲自拟定了框架思路，后来因为项目比较急，这个事情就不在我手上了。

于是，老板花重金招聘了一个“经验丰富”的大龄程序员来搞这个事情，相信您也看出来了，这个“经验丰富”被我打了双引号，明眼人都能看出来这个事情不简单！

其实，所谓通用框架的思路无非就是插件式开发，在我们搞非标设备的程序员眼里，能够被插件化的东西无非就那几样，常用的逻辑、常用的硬件、可动态的配置文件等等。

我们可以将这些逻辑、硬件、配置文件分别继承统一的基类，然后软件在加载时通过加载反射这些基类，然后动态加载基类的实现类，这样就可以做到动态的效果。

这么做的意义是啥呢？比如说我们公司有一些PLC，上位机软件需要跟PLC通讯，但是，不同厂家的PLC它的通讯逻辑是不一样的，那么我们可以找到所有需要跟PLC通讯的共同点，比如说读写一个Int、String、Boolean类型的地址值，这时候所有厂家的PLC我们可以继承PLC读写的基类，然后实现Int、String、Boolean类型的读写函数即可。这样，即使是一个项目中，中途换了PLC的品牌，我们也只需要将对应的实现包丢到软件中，让软件动态加载PLC的实现，从而做到一行代码不改。

说到这里，大部分人应该都可以理解这种思路吧？

但是，越到最后，我发现老板的理解越来越恐怖了！

通过那个“经验丰富”的程序员后面跟我们沟通得到的反馈，老板其实要的是一个“能干掉公司大多数程序员的东西”！

虽然老板嘴上没有明说，但是我们后来理解了老板的意图，说简单点，老板其实要的是一个低代码或者无代码的系统，基本上通过拖拉拽和简单配置就能组装一个上位机软件。

但是，想要彻底不写代码，或者写少量代码，那么必须有一个前提，那就是你得先把所有项目的业务逻辑全部都理清楚，并且提前把相关代码写好，这时候才能够做到所有逻辑通过拖拉拽的方式，以流程的方式去运行。

我不知道大家有没有用过海康的VisionMaste或者康耐视的VisonPro，是的，老板要的其实就是这样的东西，可是，因为VisionMaster和VisionPro对于普通人来说，还是有一些上手成本的，所以，老板的要求还要更严苛，最好是一个普通人都能轻轻松松拖拉拽出一个上位机软件系统来！

那个“经验丰富”的程序员最后直接崩溃了，因为光写一个插件式开发的框架并不难，难的是如何找出所有项目的共通点，然后把所有逻辑封装起来。

干到最后，他发现，我们公司的项目几乎找不出太多的共同点（因为太非标）了，无论怎么搞，其实只能说代码工作量小了，但是编码量顶多也就只能减少一半而已，然后就卡在了业务逻辑这块。

最后，说结果吧，这个“经验丰富”的程序员最后被开除了，因为他写的框架没有达到老板的期望，又因为卡在业务逻辑的整合这块卡了很久，后来甚至都不知道怎么往下写了，然后就摆烂了，而老板又非常关心进度，找他谈了次话，得出的结论就是-这个东西根本不存在，因此，就把他开了！

结语

你说这叫什么事，花好几万请来的大牛，干了几个月，公司白白付了十几万的工资，最后发现是一场空！而且，中途有些人已经反应过来了，老板的最终目的其实还是想省人力成本，假如他期望的系统真的能被实现，我估计最后公司那十几号人能留下的也没多少了！

这也是我前公司人心散了的其中一个大原因吧！

现在想起来，我提插件式开发只是为了后面的项目更加省时省力，但是，如果老板提的思路如果真的能实现，到时候老板可能把我都省了，招几个年轻且工资要得比我少的程序员就把项目给干了！