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

　　關于軟件或代碼，其實之前我已經寫過一篇寫代碼的四個境界。雖然說能寫出什么樣的代碼這是需要長久的訓練和琢磨的，但是今天講的，是寫代碼人該有的心態以及一些可能是必須的外界規范。

　　這幾天看到一篇文章《有著 1 萬個全局變量的一大坨代碼》，講了這樣一件事：

　　2013 年 10 月，豐田公司匆匆了結了“意外突然加速” 訴訟案。經過數小時的討論，俄克拉荷馬法庭陪審團得出結論：豐田汽車制造商貿然不顧用戶的安全，裁定豐田公司賠償原告 300 萬美元。

　　而在審閱了 2005 版的豐田凱美瑞汽車的軟件開發過程和源代碼之后，兩位軟件專家得出一致結論：豐田公司的系統不但有缺陷，而且達到了危險的程度。因為故障保護機制里充斥著錯誤和不一致，這是導致事故的根源。

　　豐田公司汽車軟件研發過程和源代碼中的各種問題包括：位翻轉(bit flips)，任務終止導致的故障保護機制失效，對爆棧和內存溢出的防護機制不足，單一的故障隔離區域，濫用全局變量(全局變量達上萬個之多)等等。

　　豐田有自己的軟件過程標準，并且和工業標準多少有一些重疊。即使如此，豐田的程序員還是屢屢違反自己制定的標準。他們沒能有效地跟蹤他們偏離標準的程度，并且會為這種偏離行為進行辯解，認為這樣做是符合實際標準的。

　　具體的案例討論我就不一一引用，感興趣的可以點擊文末閱讀原文閱讀。

　　對此，朋友圈有朋友評論：“不僅僅是豐田，好奇其它車廠的控制軟件的質量能有多少差異?各種碰撞測試，安全測試往往還是硬件的比較，在軟件越來越影響安全的今天，軟件的質量卻被極大的忽視。大多時候，我們能依賴的只有程序猿的良心。”

　　很久以前，看到過一段關于工程師的英文，原文不記得了。但用中國話意譯過來大概是這樣的：每個工程師都應該在他已有的水平上盡全力追求完美。我們應該具有一點工匠精神 —— 為我們的工作而驕傲，不斷打磨我們的工具、流程、和技術，以打造出最高品質的作品。

　　理想主義一點，軟件質量最基本的保證應該來自于程序員的素養。比如說：

　　胸有 “成” 竹。即使是在面試中，也會常常遇到一些在沒有把整個問題和程序的全局想清楚就開始動手寫代碼的人。這幾乎是兵家(哦，應該是碼家)第一大忌。從設計到架構到代碼藍圖，前面工作做得越細致，后面省下來的功夫會是加倍的。

　　有效的 tracking。哪些已經做完了，哪些還需要做，一定要有個一目了然且有效的工具幫助跟蹤，尤其是項目其實是多人合作寫代碼的情況。隨時想起來什么東西需要做，一刻也別耽誤，第一時間記錄下來。過分相信自己的記憶力早晚會為自己的一時疏忽買單。

　　誠實。不管你信不信，其實程序里面可能潛在的問題，程序員自己是最清楚的。一個系統、一個模塊，如何實現，里面可能會有什么坑，什么潛在的風險，稍微有經驗的程序員是不可能不清楚的。而如何對待這些，如何在必需做出權衡無法追求完美的情況下(比如 deadline)準確而清楚的將程序里的 “地雷” 打上標簽，不遮不藏，卻也是程序員的良心了。

　　勤快。比如說代碼里見到的 TODO。包括前面說的情況，或是一些后續完成的優化，有時我們會加一個 TODO 注釋說明這個地方自己后面會解決。然而幾乎所有較大的項目這樣一些很重要的 TODO 在很久一段時間都還繼續存在。即使早晚這里的 TODO 會被 done，但有一個很大的壞處就是后面遇到的代碼重用中，這樣的 TODO 可能會被擴散到另一個地方，而注釋可能會丟失。所以， 永遠不要把垃圾掃到地毯下面。 哪怕是加了標簽。能解決的，盡快解決，不要遺留。

　　而另一個類似的情況，是當你在另一個已有文件里改動代碼的時候。常常會遇到一個情況是：已有的老代碼和風格其實是有你能看得出來的問題的。選擇置之不理自然省事。甚至為了保證一個文件的風格一致可以照著舊代碼風格寫，即使這樣是不完美的。而按照正確的方式插入你的代碼并且重新規范已有代碼會增加很多的工作量。那這個時候你是改還是不改呢?

　　完備的測試集。寫代碼的都知道，很多時候，寫出可以測試所有情況的單元測試和綜合測試，需要的工夫可能比寫函數貨程序本身要費勁的多。然而，完備的測試集是代碼持續開發中保證正確性的第一道防護線，不論是后期的修改、重構、移植等，都會事半功倍的幫助發現問題。其重要性也不用我多說了。

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