0613 【万泉河】程序代码哪有什么标准和标准化

包括PLC程序。

我发现，有一些工程师对编程的标准化有一些误区。 误以为可以有一套标准的程序代码，或者标准的程序架构。

所以就会产生一些不切实际的妄念，在学会了写程序三五年，或者干过了三五个项目或者几台小设备之后， 就开始目光高远要搞所谓的标准化了。而其实也就才刚刚掌握基本的编程技能，也仅仅达到能完成设计任务，就觉得自己有身份也有责任为行业或者公司，创造一部编程宪法文件，规定别人写代码的规范，或者程序框架，即所谓的标准化程序。

更有一些人， 拿自己或者别人，或者官方机构所出的一套程序案例，就当成了标准化的模板来兜售，代码有可能是免费的， 那么就兜售学习掌握这套代码的教程。  即称之为标准化教程。 而且还经常冠以天花板，第一，终极目标等抬头。

我就实在不能忍，于是在某一篇类似的链接之后评论回复道：

真服了，从来只字不提做库和库的使用，却总敢吹什么完美，最高水平，终点。不理解这都哪来的勇气

库的应用在你们眼里是属于早就过了这个阶段的小儿科呢，还是还没进化到这一阶段呢？

任何成熟的技能，那就封装为库，然后就可以无限次重复应用，减少工作量，提高效率啊！

而除此之外，做标准化还有什么意义！

然后就引来了众人纷纷评论。 其中有最典型的，模拟鲁迅的语气说话：“世上本没有标准，用的人多了，就成了标准”。

这是典型的胡话，然而却代表了一大堆人的认知。同时也代表了这些只字不提库却兜售标准架构方法的机构团体的思维模式：

卖标准化程序啦！你们都来用我的程序方法，用的多了，我的程序就成了标准了。

然而这里面就出现了一个是先有鸡还是先有蛋的悖论：需要足够多的人采用你这套程序框架， 以拥护抬举它成为标准，然而在无人使用之前，它咋就成为标准，并以标准为旗号宣传和兜售的呢？

所以，所有的所谓的标准化程序代码，都存在造假宣传的问题。 你都不需要看他吹嘘第一完美天花板， 就看他用标准化的标题，就已经是了。

我们从来认为，程序代码是没有标准的。 不存在一个标准的写程序的方法，必须按照某位大神的写程序的方法，严格遵守了，程序就标准。 只要稍微违反，就是不标准。

然后就一定会有读者笑了：你万老师这是自己打自己脸吗？你自己兜售的烟台方法的标准化程序，怎么就敢厚脸皮称之为标准的？

有这种认知的不在少数。 有很多人理解成我在推广编程标准或者标准程序，私下都标定了价码，我得给他多少好处，至少多少赞美或拉拢的话，他才会给我点面子，支持我，投我一票，祝我的方法成为行业标准。

然而殊不知我谁的账都不买。 反而需要人掏出真金白银来才能获得我做的标准化架构下的样板程序。简直让很多人的价值观碎了一地， 甚至不少人彻底黑化成为了喷子。

我们所指的标准化，从来就不是程序代码的标准化，而是设计目标的非标自动化设备可以用标准化的流程设计生产，即生产流程的标准化SOP。如果不了解这个概念的，可以去搜索了解一下SOP的概念。 我在专著《PLC标准化编程原理与方法》的最后一个章节《标准化设计工作的未来》中详尽做了描述。 另外我也在多篇公众号文章中做过阐述。

当然，非标自动化设备来说，其实现SOP的最大的难点在于软件，很多自动化设备公司，其采购、生产、管理，以及市场营销，销售，甚至机械设计电气设计，都可以实现标准化设计流程，用设计的标准的OA流程进行管理。而唯独自动化软件部分，迟迟不能实现SOP，反而要独立于OA系统之外。

这有些相当滑稽，每一个公司，推行办公自动化系统，部署的软件系统，最接近的专业是自动化软件。 如果公司人手不够，往往部署这些系统的过程中还需要自动化工程师的协助。 然而偏偏，给整个公司的SOP流程都搭建起来了，公司的产品中的软件部分却实现不了SOP。

而另一个吊诡之处还在于， 机械装备，电气元件这些硬性的东西，都能实现自动化柔性制造按订单生产，然而自动化软件作为软件产品，反而却一直不能实现自动化。 老板们问起来的时候，我不知道自动化工程师们是理直气壮呢还是会感觉到一些理亏。

经常遇到一些自动化工程师，强调公司的非标项目或者设备订单，每台设备都不一样， 每台都不一样，每台都不一样。 然而有没有想过，所谓的每台都不一样的控制程序，相同之处有多少，差异又有多少，需要相同到多少程度的时候，才会认为是一样。 是百分百吗？如果设备程序百分百相同，比如家用空调机，洗衣机等设备，百分百相同的控制程序，那都不需要太多自动化工程师做设计了。 固定的程序无穷复制即可。

而如果不同设备订单的控制程序，90%甚至95%或99%是相同的，其中只有个位数的差异， 那岂不正是要推行SOP的意义所在的嘛！通过SOP的流程标准化， 实现软件生成过程的自动化，既降低了劳动强度，提高了效率，还保证了工程师的位置一直有存在价值。-------也更为电气工程师的优雅工作生活提供了可能性。

而我们在软件设计方面为SOP能做到的贡献便是程序设计模块化，这种模块化可不是简单把程序分成几个FC模块那么简单。真正的模块化必须是可以重复使用的库模块。在实现模块的标准库之后，可以实现高内聚和低耦合。 即在设备程序设计过程中仅仅需要对库模块的简单实例化调用即可完成。

这其中对库模块的要求就比较高了。 除了需要基础的通用库模版，也包括行业专用库以及工艺库模块。烟台方法实现的便是制作和使用这些库的方法。 其中会有一些已有的通用库， 主要是西门子公司免费提供，可以供我们借鉴使用，甚至也可以迁移到其他的PLC平台。而在此基础上，可以再次封装而成为行业专用库，并通过对这些基础库的调度调用而形成工艺库模块。

所以重中之重的还是对这些基础通用库的消化吸收和利用，而且这部分工作的技术含量并不高，主要还是工作量。比如要将PLC中的库函数移植到其它各品牌的PLC，将HMI/SCADA的画面库移植到其它各品牌的HMI/SCADA，都是不小的工作量。 这是我一直在身体力行做的，也是一直在宣传呼吁的，同时也一直作为对同行的观察指标。

每当看到一些同行长时间宣传标准化的思想而对库模块的开发应用只字不提的时候，不免就替他们替行业感到心焦，你们倒是尽快进化升级到对库的开发应用来呀！

有朝一日只要聚焦于对库模块的开发之后，就会发现什么所谓的代码是否规范，是否标准，是否最优，是否最简洁，系统负载最小，注释是否详尽，全都无足轻重。 因为你整个程序都是高度模块化封装的，因而某一个模块单元都是可以随时升级替换的。 即便其中的某一个模块，暂时使用的不是最优的方法，但只要其功能完整，只要独立封装，就无所谓。 你只要有对它持续改进的计划，只要有空暇，有机会，就随时可以做，做好了替换原有的模块，替换之后无缝切换，如此持续迭代，所有的模块单元都可以最终实现终极的完美。

而这个完美的评价标准由你自己掌握。