【万泉河】关于成立PLC程序CODE REVIEW互助小组的构想

国庆节前，月底时，写了一篇文章<【万泉河】浅议PLC编程中的CODE REVIEW>，我本来是对这个技术方向予以厚望，希望可以作为一个比较重要的课题，逐渐开展，积累， 并作为一个开放性的技术普及应用到整个PLC应用行业，以其对整个行业做出些有益的贡献的。

然而实际反馈的效果，离预期相差甚远。

在文中，我做了个投票。有兴趣的同学可以继续投票并查看投票结果。

单独从投票结果看，比例分布基本上符合我最初的预期，即超过95%的PLC工程师，工作中没有遇到过甚至没有听说过CR。所以我并没有感到惊讶。

然而在回复和讨论中，同时出现了两种声音。

一种声音表示，不放心自己的程序被别人看，担心自己的技术成果被别人偷了去。 这从知识产权保护的角度，好像也无可厚非。

而另一种声音表示，抵制看别人的程序，情愿自己从头写程序，都不愿意去读和修改别人的程序。 这是这个行业长久以来的现状，所以有人在这个时候提出来，也算正常。 ZANE版主甚至直接回复：

让我直接笑出来了。 我从来只给大家描述好程序的标准，却从来没有如此赤裸裸地断言整个工控界所有PLC程序都是屎。这让整个行业的同行情何以堪啊！

而至于有一些把自己自诩为ZANE肠子里的蛔虫，非要自我感觉良好理解为ZANE的话只是针对我的，只是在杠我的标准化架构程序是大粪的，都不值一提了。 我甚至都没觉得有必要私信跟ZANE核实。

这两种声音，让我看到了非常不愉快的场景。假设有两个工程师，被安排其中的一位帮忙审核检查另一位的PLC程序，还没开始呢，两边直接干起架来了。

我的程序不想被别人看到，偷了我的技术成果怎么办？

呸！垃圾程序，我看都不想看呢，谁稀罕偷你的？

我不用你看。

我不稀罕看。

原本，在IT领域， CR流程都是一个非常考验人性的工作。对CR的双方，都需要有一副好的心态，程序设计者，要理解到，自己的程序只有经过外人的审核，自己的那些不好的习惯才有机会被发现，才有可能改正提高，而不是自己一辈子一直闭门造车的状态。 而CR员，只有具备了帮他人审核程序的能力和资质之后，对CR驾轻就熟，一套别人做的程序拿到手里，短短个把小时，就有能力读懂整体架构并轻松发现其中的问题，才有可能成长为更高层级的团队管理，系统架构师，而不是一辈子只能做最底层的程序员的岗位。

而出于人性的本能，任何人都会习惯于维护自己的设计习惯，如果有人提出不同意见，提出修改的建议，有时候从理论上虽然觉得有道理，但习惯上仍然会拒绝接受，会认为不拘小节并不是什么大事，而抵触和拒绝改变才是本能。 

所以即便在IT领域，通常CR流程都非常难以真正执行好，能成功执行的公司都只是少数。 这就是之所以天底下的软件公司成千上万，但最后成长为独角兽的大厂只有寥寥可数的几个。而程序员万万千，能成长为大佬，并最终以此财务自由成功上岸的传奇故事主角总是有限的。

而在工控领域，上面描述的两位工程师开口就干仗的情况，CR简直天方夜谭。 俩人各执一词，各有道理。发生这样的情形，显然是拉郎配把他们硬配对到一起的人出了问题。

我不愿意做这个坏人。 出力却两头不讨好。

这几天一直在思考，为什么会出现这样的状况？究其原因，是我提出PLC行业的CR概念，太太太超超超前了。

就好比我提出的PLC标准化编程方法，我这儿都已经成功完成落地应用，甚至在所有PLC品牌中也已经实现，然而在同行中， 还在为最基础的概念争论疑惑不休，这其中的差距，我在开始推广时初步判断有10年，而经过最近大半年的争论甚至被辱骂，我认为10年恐怕还少了，恐怕至少要有20年。

而CR工作，至少要在普遍实现了标准化基础之上才可以展开，真的要形成规范则再推后上10年，跟现在比，则是30年以后的事了。

而对我来说，10年或20年还可以预期，30年则有些太久远了，我能不能活到那个时候都未必，即便能，到时候我已经是耄耋之年的老人，也一定没有精力来从事这些具体的工作了。

所以， 上一篇提出的设计研究通用的PLC程序CODE REVIEW规范的梦想就此搁浅。再过多少年后，再有业界的同行提出这样的设想， 想要重新启动的时候，看过我这里有个纪念碑，再从头出发吧！

然而，我们却仍然可以在小范围内先做一些摸索尝试。

即，在标准化学习营的学员内部。

学员之间，可以自由搭配，一对一自愿形成互相CR的组合，互相拿出各自的作品请对方帮忙审核。

审核的目的有两个，一是互相学习提高，二是在审核的同时摸索审核的原则和方法。即CR的权利、边界以及规范，都需要逐步摸索。

标准化的学员之间做CR，有这样的先天之利， 即大家的编程方法是一样的，都是从我这里学到的，所以如果发生两人互喷对方程序是垃圾的时候，很好办，责任人是我。 你们俩再合伙来喷我好了。我一直期待有学员对我传授的标准化方法提出异议，提出改进意见。一直未能如愿。现在好，有组团来挑战的，你们互相支持，互相鼓气，底气也可以够硬一些。

当然，这个CR组合只能是一对一，私下组队，而不是在所有学员之间公开交流，这样有利于信息的保密，万一有遗失，也容易追朔源头。

而对于比较敏感的各自掌握的行业工艺机密被遗失的问题，也可以协商探讨一些可靠的方法。 比如通过向日葵远程操作，只操作对方的电脑上的软件，来进行CR， 却不具备复制文件的权限。以PLC程序的规模，通常CR的时间也会很短，远程操作完全可以。 双方都在线，随时沟通更是很有必要。

所以，标准化的学员之间先私下沟通（你们应该互相早就加为好友，这是我一直积极倡议支持的）。 达成配对的意向之后，再通知我，我们组成三人CR小组，你们互相做CR的时候，我尽量全程参加，每次CR都要形成书面结果，我们再一起对书面结果进行评价，总结，逐步形成CR规范。

如果有学员比较受欢迎，多个学员都要和你组队怎么办？那就和他们分别组队，组成多个CR队，通过尽量少的交叉，充分保证技术资料不遗失，都可以。

PLC行业的特点， 工程师大部分都是单兵作战，所以能有条件在同事中相互做CR的公司非常稀少。见过的公司，PLC工程师团队能有6个都已经算是规模相当大了，而再大的规模，就有可能分到了多个部门，各自负责不同的行业和设备工艺，与不同的公司没什么两样。

所以，要做CR，要通过CR来实现自我提升，通常内部条件很难具备。所以走外部路线，通过外部渠道帮助自己提升技能，是条件不具备情况下的唯一的选择。

所以，我估计有可能有一些小公司的单兵作战的工程师仍然有这个需求，我仍然可以帮忙搭配组队，但过程我就不具体参与了。

方法是：在本帖回复“我要CR组队”，并留下微信号，其他人见到会加你.。

万一到时候翻脸了闹纠纷了别来找我帮忙调解。