如何行之有效分析别人写的PLC程序

读别人的程序是比较痛苦的，尤其那种调试修改很多次之后的，唯宏运建议指梁从总体绝腔上看—整理思路，具体细节—不要太过纠蚕，规范的程序都是成块的，每个模块实现某些功能，看多了就行了，没什么好办法的

I/O表流程图敏粗派都简单要太懒自手问题答案用贴桥贺 起： ld m吧00二 set s0 stl s0 ld s0 and x0 set s一凳槐一 ani x0 set s四0 ret s一一s四0流程支写先写哪路随情,考虑设备安全性需添加些保护或自检控制输提

前言

程序存在失控风险，请反复测试，

使用IDE提供的功能，

透彻地阅读你的代码，

做到心中有数。

看不懂别人的代码

看不懂非常不解，不懂只是暂时的禅罩陪，

既然都有源代码了，

还愁看不懂吗？

编程语言的那些语法、关键字抛开不说，

重要的是解决了什么贺蠢问题，

怎么解决的，

为什么这样写？

抛出异常

如果调试程序过程中，

抛出了异常，

那么先恭喜你，

你离看懂这个方法已经非常接近了。

写程序怕的是“抛出异常”，

最怕的是测试不抛出异常，

上线抛出异常。

没有一个错误信息支持，

几乎想破脑袋也很难分析出来龙去脉。

正确认识Bug

编程写代码，固然非常重要，

考验的是一个程序员抽象业务功能，

分析逻辑，并使用方法实现的能力。

然而，

我们并不能保证，敲写的代码“绝无Bug”。

要知道，

Bug是神一般的存在，

只要你深入地剖析，

总能对一些方法进行绕过，

从而达到你提权、取数据、改数据的目的。

Bug暂时没发现，

仅仅是合适的条件被触发而已。

掌握高超而全面的调试技巧

能写程序，非常好；

如何将你的程序调试通过，

且在出现异常的时候，

能够使用巧妙的方法，

将问题复现，

这是很了不起的事情。

一旦重现了Bug，

相当于你的狙击步q，

已然瞄准了猎物，

剩下的，一击必中。

写在最后

俗话说：“书读百遍其义自见”。

代码也一样，

就想查账一样，

事无巨细，亲自上阵，

拿出绣花针的功夫，

反复阅读，不厌其烦。

大胆修改，勇于改错，

调试错误，追溯流程。

相信你不久就会对程序的功能

烂熟于胸。

对闷扰了，记得把梳理的过程用文档记录，

这样初期的时候，

你不用每次都要痛苦地重来一次。

我是@程序员小助手，持续分享编程与程序员成长相关的内容。

---