前一阵子的两件事，让我不禁感慨： 世界的本质是个草台班子。
第一件事是看到新闻说，波音公司因为政治正确赶跑了资深的空气动力学专家。
第二件事是看韩国电影《首尔之春》，没想到军事行动也可以这么草率。
回想我职业生涯的经历，似乎也可以作为这个结论的佐证。
A公司是行业领袖，其MES系统被评为首批工业4.0灯塔工厂。但是在锦绣包装下面，也填充了不少烂稻草。我记得用户汇报过一个问题，其个工单的验证出错，我检查了工单验证的逻辑，发现了一个不可思议的SQL查询： 100多行的SQL，没有任何注释，没有格式，没有规范换行。我把这个SQL拆分成10多个视图，才逐渐理解了其中的逻辑，找到了问题所在。造成这个问题的根源是： A公司把开发外包给印度T公司，T公司非常注意文档的规范，但在代码层面放飞了自我。
B公司是行业的奠基者，需要将北美的生产调度系统引进中国，此系统的重点是PLC控制逻辑，基于AB PLC开发，而在中国工厂采用了西门子PLC，因此需要进行代码迁移。此外，北美PLC只控制一个工作站，而中国PLC需要控制多个工作站。B公司将迁移和本地化开发的工作开包给一家小公司。我建议搭建测试环境，以尽可能及早发现问题，但是项目负责人说不用，说人家是专业的，之前从没有这么做。结果上线部署的时候傻眼了：项目包太大，超出了PLC的容量。结果这件事情层层升级，最终由公司中国区CEO联系西门子中国区CEO，从别的客户手里暂时调用319F PLC，以解决容量的问题。最终项目交期超出了一个多月后才具备初步上线的条件。
C公司的安灯系统在业内非常知名，我接到的任务是借鉴其功能，将其实现并应用到中国工厂。我在考察C公司工厂时发现其用了软件PLC而不是通常的硬件PLC，也就是说其PLC功能是安装在WINDOWS PC上通过专用软件实现的，因此稳定性方面远不如硬件PLC，原因是项目包太大，普通PLC下载不了。得到其项目包后我才知道原因：有太多遗留设备需要兼容，相同功能不同产线采用代码复制的方式实现，所有I/O参数采用硬代码实现。我和同事研究以后，采用了以下的优化方案： 用符号寻址代替编号寻址，功能模块用配置的方式调用，I/O用配置表进行映射，用中间表+FC的方式做到功能模块的抽象实现，不同的产线调用相同的FC。经过以下优化后，项目包可以下载到硬件PLC，而且还有多余的空间存储调度系统的项目，并且能够缓存2小时的工单数据、生产记录。
博文
