Auto Code Review的重要性

软件公司的代码Peer review与汽车电子中的代码评审的区别还是很大的。自动代码的出现，使得系统与软件工程师合二为一。即使对C语言一窍不通的系统工程师也能用Simulink生成近乎完美的自动代码，这个是嵌入式软件开发中的巨大进步。

但有了Simulink后，真的就不需要了解生成的代码了吗？老胡的一篇《MEB开发嵌入式软件的C语言基础》，这个让我意识到，有许多系统工程师确实对代码不太感冒。

我个人的观点是，即使是系统工程师也至少要对C语言，亦或者说对生成的自动代码有所了解。工程师在集成代码前必须对生成的代码进行最基本的Code review，而在并入代码库前的把关Reviewer更必须是这方面的专家。

我这边不会对建模规范进行过多讲述，而是对后续的Auto code generation进行Code review能给我们带来什么好处做出一些简要分析。对Auto code进行充分的评审有如下优点：

（1）发现功能评审或者建模规范中遗漏的项目，这是对前者的一种补充。

（2）Auto code review能帮你发现许多代码中出现的低端错误。自我Review可以在代码预集成的前夕就发现这些问题，及早的进行修复。

（3）代码生成工具失效。100次代码失效，可能有99次是画模型的配置错误的Human error，但是也有可能1次失效，是代码生成工具的问题（谁也保证不了Simulink每次都是对的）。此类问题往往隐藏较深并且难以发现，即使Test阶段也很难识别，这时候往往资深的Code review专家就能发现此类问题。

（4）减少测试工作量，这么说其实有点误人子弟，理论上即使是最简单的代码，也必须要经过测试的。但在软件开发过程中确实有一些无法测试的工况，比如初始化进程，这就只能依靠Code review来把关。其次，这里更多指的是无意义的反复测试，如果在Code review阶段就能发现的低级错误，何必要流入到Testing阶段再报出来呢？

（5）知识的传承，对于Coding或者建模规范，刚刚入职的新员工并不会很熟悉。通过Code review能尽快的帮助他们提高这方面的认识。

有人会质疑，Auto code相比于手工代码而言更加晦涩难懂。其实不是的，代码之所以能够自动生成，就是因为在其背后有着一整套规则和套路。当你熟悉了这一套路之后，就会觉得其实这并不是什么难事。正所谓自动代码千篇一律，手工代码风格迥异。给人一种看惯了自动代码后，就不想再看手工代码的感觉 ~