由豐田代碼事件引發的軟件質量思考(2)

　　代碼審核。這里說的是 Code Review，也叫 Peer Review 。 這可能是目前我們能有的對代碼質量的保證最重要的環節(之一)了。和很多同事聊天，都有個共同感觸：很多寫代碼的技巧、風格、或習慣都得益于以前工作中在代碼審核中同事給出的建議。這比看書或者讀別人代碼學習來的要有效的多。在面試中也發現一些現象：有些公司的工程師一下手，從敲下的頭十行代碼開始，你就能看出他的好的編程習慣。而很多剛畢業，或是從畢業一直在一些不是很重視代碼審核和代碼規范的公司(尤其是小公司)的工程師，很多細節一下子就能暴露很多的問題。

　　記得上一次有個讀者留言說，感覺組里大家的水平都一般，這種情況怎么辦呢?代碼審核還有那么大的用處么?有。首先，更多人會了解代碼是做什么的。這種信息共享會保證所有合作的人對全局的代碼改動有個全面的了解。其次，多一雙眼晴會看到你的一個疏忽，多十雙眼睛就能避免你的大部分疏忽。最后，一些語言上的技巧更容易分享，而代碼模式也更容易規范化。

　　代碼審核會最大程度受益，還需要代碼被審核的人能夠比較謙卑，以開放、聽取的心態對待每一個評論。而參與審核的人要多存質疑的態度，不明白的或者覺得有問題的可以改進的地方都直接說出來，討論開了，對雙方都有益。代碼審核中也常常出現意見不統一，產生爭論的時候。有效的解決意見不一致的過程，其實也會幫助對系統或者代碼更深層的考慮和了解。

　　然而，靠著程序員的良心和素質，對代碼或軟件質量的維系，對于上面說的軟件質量會影響人生安全的情況，卻又顯得遠遠不夠了。

　　對于車廠的控制軟件的質量，豐田這次是因為出了事故再有人去深度調查，花費很多的時間和很牛的人力資源才找到問題的根本。試問又有多少無人察覺的軟件 “地雷” 存在于我們的生活里呢?嵌入式軟件因為其特有的和底層硬件的緊密耦合，各個公司一定會有自己的接口，因此都會有自己的軟件質量審核標準和審核流程。這是現狀。然而隨著各種智能軟硬件結合的機器逐步滲透到人們的衣食住行，會不會有人出來在不同領域定義業界相對比較標準的接口和測試規范，用一個統一的黑盒測試更全面的對軟件的質量進行控制，以及一些程序評估模式來對程序質量進行評估(有點類似 Ruby 的 rubocops?)。在未來的十年甚至更久，這樣一些有效的外界對軟件或程序質量的約束，可能和程序員自己不斷打造自己的 “匠心”，都是一樣很重要的吧。

　　原文出處：微信公眾號——嘀嗒嘀嗒

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