1218 【万泉河】谁有资格评价PLC程序对错

谁有资格，答案当然是从事CODE REVIEW的同事咯！

然而众所周知，在PLC行业，绝大部分的公司，是没有CR机制的。 从来都是谁写的程序谁自个儿调试自个儿维护，一杆子负责到底。 没有另外的人帮你CR的。我曾经写文章探讨过关于CR的可行性，以及期待行业中最终能发展出可以通行的CR的标准。 但至少现在，还没有。 所以即便有个别公司和同行同事之间有那么零星的符合CR机制的流程，但在还没有见诸纸面的可分享的CR标准之前，我们只能认为不存在。

那么，除此之外， 还有谁拥有这样的资格呢？

让我们把疑问暂时放在一边， 来看一张图，其实是一段程序。

是我在前面一篇文章《1209 【万泉河】江湖又现万线圈》中引用过的一段程序。原始程序是一名网友贴出的。而后面的红线部分是被我修改之后的，修正了原程序中的bug。

文章发表以及这个图片的程序被转发之后，在同行之间引发了不少争议。我粗略估计下， 支持的和反对的大概各有一半。 有一半同行支持这样的程序写法，甚至其中的错误也是这些朋友们帮忙发现的。 我原本只看了一眼程序的写法，对具体的逻辑根本没关心，有错误去改正即可，不算什么大事。 而反对的同行中则理由各不一致，根据自身预设的立场高低不同，分成了几派，后面逐类分析。

不过在分析之前，先对一种反对声音做出反驳。 有那么几个零星的声音，观点是：这么简单的程序还用得着讨论吗？

这部分的观点表达时语气基本相同，都是用反问质问的语气，然而同时，你又看不出他是在表达支持还是反对。 其实叫我说，这样的语焉不详的表达观点的习惯，恰恰证明了这些人的思考能力和水平。

答案多简单！同行们对这个问题的观点分歧都基本达到旗鼓相当了，还认为不值得讨论。 那么请问， 什么样的问题值得讨论呢？有分歧当然需要讨论了，通过充分讨论，每个人认识到自身认知的差距，然后整个行业的认知水平才可以提高。 那些认为这种小事的分歧不重要，无所谓，没必要投入太多的精力在这方面的，足以见其基本功是没有的。 做事情都是在那儿摸着石头过河，走到哪儿算哪儿的。 当然啦，咱也不是非要坚持自己的观点正确，你如果认为没必要讨论，自己不感兴趣，那你就视而不见不参加讨论即可。没必要阻止别人讨论探讨。 否则就需要好好解释下你用心何在了。

回来看反对派阵营，观点中从高到低主要有三类。

1，  斥责：这是典型的脚踩西瓜皮贴狗皮膏药！

然后甚至不管三七二十一以他自己的习惯方法直接对程序方法做了修改。

2，  表示：如果我的团队中有这样写程序的成员，我会劝其离职。

3，  抱怨：不按常规写别人不容易读懂的程序，将来别人无法维护。非常讨厌。

我对这些观点自下而上逐个回复和探讨：

关于维护的概念有两种理解，可以是甲方的维护工程师，要么是自己公司后来的继承者或者叫做接班人。

如果指的是甲方， 那确实没有办法。收人钱财替人办事，人家作为甲方既然对写程序的姿势有具体的要求， 你当然要全盘满足。这个时候，其实你也不是什么设计师工程师，就是个严格的执行者而已。 甲方单位既然有完整的解决方案， 甚至有模版给你抄，你就老老实实照着抄，也不需要有什么不一样创新想法在里面。遇到这样强大且强势的甲方，做一个温顺听话的执行者也不错。 如果对此有些不满，觉得这种行规限制了自己的自由发展空间，也不要抱怨，要抱怨只抱怨自己命不好，去错了行业。你只要还在这个行业谋生，就遵守他们的行规。 比如整个汽车行业盛行的SICAR标准，就是如此。  

而如果指的是后来的继承者，这个指责和抱怨就非常没有道理了。等于是后来者给先行者下了紧箍咒。 而且有可能先行者在开发设备程序逻辑的时候，这个后来者还不存在， 还没有来到公司。 却要求先行者提前预料到后来者的智商和理解力水平，需要包容他们有可能看不懂学不会，所以在系统设计中要避免。 那么这样的话，设计中想要应用什么新功能新技术都要好好掂量下了。 如果未来的接班人是个笨蛋，学不会咋整呢？

总之，后来的学习者给先行的导师提要求设框框，是不可理喻的。

而第二档的以团队头目出现的， 对与自己的习惯不同的同事而容不下的，我的评价是：这不是典型的武大郎开店嘛！容不下比自己个头高的。

如果这个新同事，设计方法完全错误，一团糟，根本不能运行，而又不听话，如我在上篇文章中所讲述的， 最后还需要你这个老大来主导所有设计从头再来，导致非但没能给与帮助，反而帮了倒忙，那么这个助手在这个团队中确实没啥必要存在了。可以在给予几次机会后酌情考虑请其另谋高就了。

但现在的情况是， 程序设计方法明明是可行的， 设备是可以正常运行的， 甚至有可能最终的设计比你遵从传统方法的更有优势。 但现在仅仅是因为不符合你的习惯， 甚至可能是因为做出了你看不懂的更高级的设计，你就容不下，就要千方百计排挤下属出局，那说明你这个团队小头领是不称职的，公司领导把团队交到你手里，让你来带，是需要你不断挖掘培养创新人才，提高团队创新水平的。而不是任人唯亲，以己度人，把团队带到武大郎的烧饼店一般越来越窝囊。

所以，真正需要卷铺盖走人的，或者把位置让出来的，应该是你自己。

对上述所有观点的综合看法，我的评价是：

我非常惊讶的是这个行业的普遍现象， 不善于吸取别人的长处。 明明是自己看不懂的设计，却不肯承认， 然后能按自己的价值观给出各种各样奇谈怪论的评论。

表达一下自己的谦卑和学习欣赏态度就那么难吗？

讨论中，倒是有一位群友的态度非常坦诚：凭直觉觉得这段程序是错的，然而研究下来它偏偏能正确运行。不懂怎么回事。

这位群友以前搞过技术，现在已经放弃技术去搞市场销售了。 对于这样的开放心态的人，我就十分欣赏。说明他并不是技术搞不好而转行去做销售，而恰恰是技术搞得好之后，才有能力从事更富有挑战性的工作。

我曾经写过好多篇关于评价程序好坏的标准，当然， 那些标准都是基于效率的，评价一个好的程序和坏的程序的标准是有利于效率的提高。

那个时候，总有一些人冒出来总结到：能够正确运行的程序就是好程序，这回，有一个能正确运行的程序出来了，先不论它是否够效率高，按这些人的观点，首先应该接受，而不是否定，更不是不加分析直接要消灭它呀！所以在没有CR之前， 除了程序的设计者自己，无人有资格评价程序。检验程序对错（注意不是好坏）的唯一标准是机器。程序只要在机器上能运行正确，就无人有资格说错。

最后分析下这个程序的缺点。

从常理来讲，大家通常建议编写程序的风格方法要有一致性。这个程序，前面手动部分用的是SR，而后面的自动部分用的启保停。风格极其相悖，也难怪导致众多老工程师勃然大怒。

我曾经尝试过要把它们风格统一，要么全都SR， 要么全都启保停。 然而反而有些困难。 把前段改为启保停实现难度相当大，改完以后的逻辑反而不如现在容易阅读。

而把后段改为SR，难度稍低了一些，也比原来容易阅读， 出错的机会也低多了。 至少，自动状态不再干扰手动模式的逻辑了

原本T37的条件中隐含了自动模式的条件，现在重复使用一下，逻辑就比较通顺了。

如果程序最初的作者，用这样的方式写程序，或许就不会引来那么多反对声音，甚至一不小心得罪老大丢掉饭碗的风险了。

然而，两种程序写法是等价的，能实现的功能是一样的。