由丰田代码事件引发的软件质量思考(2)

　　代码审核。这里说的是 Code Review，也叫 Peer Review 。 这可能是目前我们能有的对代码质量的保证最重要的环节(之一)了。和很多同事聊天，都有个共同感触：很多写代码的技巧、风格、或习惯都得益于以前工作中在代码审核中同事给出的建议。这比看书或者读别人代码学习来的要有效的多。在面试中也发现一些现象：有些公司的工程师一下手，从敲下的头十行代码开始，你就能看出他的好的编程习惯。而很多刚毕业，或是从毕业一直在一些不是很重视代码审核和代码规范的公司(尤其是小公司)的工程师，很多细节一下子就能暴露很多的问题。

　　记得上一次有个读者留言说，感觉组里大家的水平都一般，这种情况怎么办呢?代码审核还有那么大的用处么?有。首先，更多人会了解代码是做什么的。这种信息共享会保证所有合作的人对全局的代码改动有个全面的了解。其次，多一双眼晴会看到你的一个疏忽，多十双眼睛就能避免你的大部分疏忽。最后，一些语言上的技巧更容易分享，而代码模式也更容易规范化。

　　代码审核会最大程度受益，还需要代码被审核的人能够比较谦卑，以开放、听取的心态对待每一个评论。而参与审核的人要多存质疑的态度，不明白的或者觉得有问题的可以改进的地方都直接说出来，讨论开了，对双方都有益。代码审核中也常常出现意见不统一，产生争论的时候。有效的解决意见不一致的过程，其实也会帮助对系统或者代码更深层的考虑和了解。

　　然而，靠着程序员的良心和素质，对代码或软件质量的维系，对于上面说的软件质量会影响人生安全的情况，却又显得远远不够了。

　　对于车厂的控制软件的质量，丰田这次是因为出了事故再有人去深度调查，花费很多的时间和很牛的人力资源才找到问题的根本。试问又有多少无人察觉的软件 “地雷” 存在于我们的生活里呢?嵌入式软件因为其特有的和底层硬件的紧密耦合，各个公司一定会有自己的接口，因此都会有自己的软件质量审核标准和审核流程。这是现状。然而随着各种智能软硬件结合的机器逐步渗透到人们的衣食住行，会不会有人出来在不同领域定义业界相对比较标准的接口和测试规范，用一个统一的黑盒测试更全面的对软件的质量进行控制，以及一些程序评估模式来对程序质量进行评估(有点类似 Ruby 的 rubocops?)。在未来的十年甚至更久，这样一些有效的外界对软件或程序质量的约束，可能和程序员自己不断打造自己的 “匠心”，都是一样很重要的吧。

　　原文出处：微信公众号——嘀嗒嘀嗒

原文转自：http://www.chengxuyuan.com/post/73.html