【万泉河】浅议PLC编程中的CODE REVIEW

PLC作为一大类特殊的工业产品， 是一个相当另类的存在。

你如果把它作为一个普通的电气元件， 它太过复杂。而你如果要把它当作IT产品，在IT家族眼里，它又太过简单。甚至IT行业的很多人，压根没听说过它的存在。要跟他们解释清楚PLC到底是什么，还有些困难，有时候花上大半天时间，都未必能讲的清楚。

总的来说，作为给PLC编写程序，给工厂设备设计工艺程序的PLC程序员，位置也是比较尴尬。在普通的电工和电气同行眼里，我们搞的是IT的工作。而如果把我们在做的逻辑内容描述给IT工程师，他们又会笑掉大牙。

就这，就这也好意思称作逻辑，也好意思称作程序，也好意思自诩是程序员？

大致就是这个意思。

一直以来，我给自己的定位，在只做PLC程序，不包含上位机程序以及更高层面的设计的时候，就认为是个入门级别的IT程序员。

而且，我们平常所用得最多的那些技能，比如计算机数据类型， 数制转换，循环， 分支，跳转等语法，对应到计算机系统，也就是大学里学的那几门编程语言了。有一些细节甚至更简单，更容易上手。

当然，这也是PLC这个产品被各厂家设计出来并推广到整个工业领域大行其道的本意。

所以，学习PLC编程，想要玩的更好， 实现更高的水准，其实诀窍很简单，跟着IT领域来学习，然后融会贯通即可。而且，只需要学习其中的一些皮毛就够了。只需要学习其中外在的思想的部分。再高深的，没必要都学。甚至， 即便学了， 挪到PLC系统中也用不上。因为系统资源、接口、性能等根本不支持，用不上。

这里面关键的词汇是融会贯通。 有许多工作，在一个行业看来很稀松平常，但如果你能跨行业应用到另一个领域，实现了融会贯通，然后就会非常有意义。

这比简单地照抄模仿同行要有意义得多，也更有成就感。

我做PLC标准化编程就是这样。

我在读研期间，做课题期间，做过一些软件开发，数值计算，辅助设计的工作，但最后工作后，没有机会成为专业的IT工程师，并更进一步得到更大的提升。然而当我涉足PLC/SCADA领域后，仅凭当年学的那点三脚猫的编程功夫，就可以游刃有余，任意驰骋了。

PLC标准化编程， 核心思想只有四个字：面向对象。而其实我学过几回C++直到放弃，也都没有做出过像样的C++程序。当然，因为那个时候还没有python和C#，学起来更困难些。

实操能力没有训练好，但思想搞懂了。所以当PLC性能升级之后，再加上自己多年对PLC系统的经验积累，用面向对象做起标准化来就比较容易了。 

然而当我们把整个PLC行业所有品牌所有平台都做过标准化并打通之后，进一步，又一个技术点进入了我的视野。那就是CODE REVIEW，同样来自IT领域的概念， 我认为是时候， 有必要拿到PLC领域来进行一番研究和探讨了。

首先做一个调查，对于CODE REVIEW（以下均简称CR），你的认识：

你的选择是几呢？

如果是1，不需要着急。我估计大部分PLC程序员都在1和2之间。我自己也只是2。从没做过3和4，甚至也从没见过有3 or 4经历的同行。

如果还不知道什么是CR，可以先搜索下网络，比如：

什么是Code Review

https://www.cnblogs.com/wdpp/archive/2011/01/17/2386823.html

（可以通过文末阅读原文跳转）

简单来说，就是一个程序员帮另外一个程序员检查程序。

这其中，大部分情况下是职级比较高的程序员帮助新入门程序员审查程序，同时也存在同级别的程序员互相交换，替对方审查程序。

对于IT行业来说，一个软件项目，动辄几十个甚至几百个程序员协作完成，每人只承担其中的某个模块单元，所以就需要在合并之前进行严谨地确保无误的审查。同时为了后期的维护，代码风格，接口定义也都需要有严谨的规范。

而这些前提条件，在PLC行业貌似根本不存在。除了极少数（我估计少于万分之一）的项目， 一套PLC内的程序需要多人协作完成，绝大多数情况下，通常都是一个人完成一套程序从诞生到成熟结果落地的过程，大部分情况下不需要协作，不需要考虑升级维护，甚至还要通过加密阻止后人进行任何读取和改动。

所以，在PLC行业，大部分的程序是没有审查的。

要说有审查，也是通过设备的运行效果来审查。只要设备运转正常， 能达到预先设定目标， 那就通过。只要不正常，未达到预想目标， 就不通过，就继续修改，重复调试，测试，直至满意。

这也导致很多同行，常年工作中养成的习惯，观念上根本没有程序质量好坏的区分。我在提出好的PLC程序评判标准的时候，就有人提出形形色色的观点反驳。比如：

能让设备运转的程序就是好程序。

条条大路通罗马。

不管黑猫白猫，抓住老鼠就是好猫。

。。。。

总之，对这些同行，他们的程序只有非黑即白2个状态，要么好到成功运行， 要么失败到设备不能运行。没有中间过渡地带。

如果有领导提出，需要在公司范围内推行CR，他的程序需要被别人做CR的时候，一定会像被捏住了蛋蛋一样痛得跳起来了：程序已经在设备中完好运行了，已经证明质量优秀了， 你R什么R， R个毛啊！

XX领导。

所以，如果你对PLC程序的认知还停留在黑猫白猫层级的话，那说明你还不足以理解CR， CR对你无效。

当然我们回过头看整个IT行业， 成功推行CR制度的软件公司都只是少数。其中的为数不少的软件公司， 即便有CR也流于形式。所以这也最终成为这些软件公司的软件系统发展多年后逐渐垃圾成山的原因。

所以PLC行业PLC工程师们会习惯性地抵触CR，也是必然的。

将心比心， 如果换作我， 好不容易写个程序，辛辛苦苦调试完成，设备终于正常运转，甚至已经出差回来，又有人因为我编程习惯的问题，对我指手画脚，让我改这儿改那儿，而如果改出来毛病， 设备运行逻辑出了问题，他还不负责任， 还需要我自己再从头查错，重新调试，那我杀了他的心都有。

至少，到老板那里告他一状，指责他浪费人力，浪费公司资源，做无用功，甚至破坏正常生产，是最轻的。

然而，一个公司，尤其是软件方面的技术工作占到了相当的比重，要想技术进步， 要想不断发展成熟，而不是所过之处留下的全是不重样的，不具备可重复利用价值的垃圾山，CR肯定是需要的，也只有不断的CR，不断的互相促进提高，不断优化，最终公司才能实现产品最优。性能最优，效率最优。通过CR， 项目不再严重依赖于某个个人，而是所有工程师都可以随时接手互换替代。

而其实，我现在这个时刻提出做CR， 主要还是我们标准化架构下已经具备了CR的基础条件，CR已经不再是天方夜谭， 更不是逼人杀人，而是切切实实地可以做到帮助企业持续优化产品，更简单说，是工程师可以有精力有那个闲心来做那方面的工作了！

在标准化框架下， 一个项目做完，到下一个项目的时候， 原本上一个项目的程序库函数，都可以照搬拿来直接使用，然而现在有充裕的精力的情况下，就可以对上一个已完成项目做些总结和改进，通过引入外来力量，进行CR，帮助提高，逐渐规范，实现规范统一的公司标准。

这部分需求已经很迫切了，需要有章可循。

然而具体怎么做，我还一头雾水，我看了IT领域的一些CR规范，但对于如何融会套用到PLC程序中来，还没有形成完整的思路。

这也是我把这篇文章名字只是叫做《浅议》的原因。就是希望有经验的同行上述选择题中选择了3和4的朋友，尤其是有资源，有机会接触正宗的IT软件工作，现在又从事一部分PLC编程工作，可以提出更完善，更具体的建议。

对于提高我们整个行业的技术水平和认知水平，都会是大有裨益。

待我吸取够足够多的营养，有了更丰富的认知，再写出更具体的有针对性的PLC程序CODE REVIEW的干货文章。