主题：【原创】朗读代码 -- 代码ABC

据说，国外有那么一间大学。

据说，那间大学有一个代码咨询小组。

据说，这个小组专门帮程序员找出其代码中的错误。

据说，在这个小组的门口摆了一只小熊。

据说，每一个过来咨询的程序员都要向这只小熊朗读自己的代码。

据说，许多人还没把代码读完就自己发现了错误。

。。。。。。。

在不太久之前，程序员还在使用文本编辑器输入程序代码。那时候没有集成调试环境；没有变量跟踪；没有单步运行；甚至程序断点也要通过代码来设定。那时候一个有力调试工具就是——打印机！

把程序打印出来，找一个远离键盘、屏幕的地方，自己客串一回电脑，把程序在心里运行一遍（也可以是几遍），实际上就是在心里朗读代码。可能出乎许多人的意外，靠这种方式可以发现大部分的错误。这种类型的错误我后来称之为“肉眼可以发现的错误”。的确许多代码错误可以仅仅通过“肉眼”发现，不需要借助复杂的集成调试环境，关键在于掌握朗读代码的技巧。

技巧在于——不要把自己当人！你就当自己是一个CPU，不要做任何假定，老老实实地计算每一个表达式，记住曾经改变过的变量，计算每一个循环的出入条件，留意每一个函数的“副作用”。实际上很多错误都是程序员对代码的理解和实际运行它的计算机不一致引起的。而代码朗读将训练你把这种不一致降到最低。这样你不但可以发现代码中的错误，而且在以后编写代码的时候自觉地写出错误很少的代码。所以朗读代码还是一个通往高级程序员的修行方式。

这种方法看起来简单，不过在一开始的时候会令人非常沮丧，因为你会发现不管检查多少次都不会发现一个错误。再加上调试环境的诱惑，现在恐怕没有多少人愿意干这种吃力不讨好的事情了。的确在调试环境中单步走一次的时间绝对比你在心中运行一次的时间更短。不过你可以把这两者结合起来，通过比较自己的运行过程和调试环境的运行过程来发现自己思维上的错误，逐渐纠正这些错误。渐渐的你就能用“肉眼”来发现错误了。而更重要的就是你写出来的代码错误也越来越少，当你能确信在五百行以内的代码能够一次通过，那么这项修行业就毕业了。

刚刚花了以后，就上不了西西。跟贴写了半天，全没了。

通过很多实验手段证明运行前先把程序细读一遍可以减少大量bugs。

唉，计算机各分支里最被业内人瞧不起的大概就是软件工程了。

通常是同一组里需要用到你的代码的同事。

可是经常要做这事，还有就是“朗读代码”，差不多天天要读上几段，人生一大苦啊。

做软件的peer review，至少我经历过的，都还好，不知道其他行业是不是更挑剔？关键是和同组里的契合。如果平常讨论和设计的时候，大家沟通流畅，做出的东西就不会离题万里。

至于具体实现中出现的错误让别人给指出来，其实是好事。否则，到了QA那里过不去，还是自己的麻烦。更要命的是如果到了客户手里出了问题，再查出是自己的代码引起的，那才是大祸。所以，我非常热衷于让别人审查我写的代码，至少，出了问题还可以拉个“陪斩”的。

真正实践的时候，软件工程的各项原则往往因为项目延宕而被抛之脑后。

基本上就是控制系统编程，要求千奇百怪，我们就是自己的QA，所以更加要小心。

你们那套东西可错不得，难怪code review压力那么大。

好奇一下，你们怎么联调测试？也有模拟系统吧？总不会直接就上生产系统吧？

电厂是这个名字，不知道石化怎么称呼

这是《红灯记》还是《智取威虎山》里的？

有的地方比较豪华，有仿真系统，可以再那里先试一下。但是仿真系统的系统特性不是100%仿真，有的地方偷工减料的，所以这还不行。有的时候要在DCS上建立一套平行的系统用作测试，但还是不打可能完全平行，牵涉到N多个tag，M多个系统，有的牵涉到机械设备或者工艺过程的物理特性，没法仿真，所以就要有一个commission的过程，可以逐步把feature加上去，加的过程有人看着，要是不对劲赶紧撤。每一个大的application的commisson的时候都是心跳加快手冰凉的。不过成功了，那愉悦远不是学术杂志上发一篇文章能比的。

这不就是没有做到\"职责分离\"嘛?难道你们的内部控制系统没有看出来?

时值接拿生产数据还是自己创造出来的数据去Run？