事后諸葛亮：如何寫出沒有bug的軟件
網上對蘋果iOS7操作系統中 ***暴露出的一個嚴重安全漏洞的討論讀起來十分有趣。如果你還沒有讀過 Alex Langley對此的分析，那現應該讀一下，寫的非常好。
附帶說一下，是一個TLS v1.2 SSL連接問題上的bug，簽名認證沒有被檢查，使偽造簽名成為可能。原因是代碼***的直接跳到了方法的結尾處，沒有實際檢查哈希結果是否正確。
是什么導致了這樣一個弱者的bug？我四處看了一下，下面是網友們總結出的幾個原因：
- 用C語言很難寫出正確無誤的程序
- 蘋果公司的程序員不用心
- 編碼風格中允許忽略大括號
- 蘋果公司里沒有正規的代碼審查
- 使用了goto語句
- 使用了自動代碼合并
- 沒有開啟編譯器對死代碼的警告
- 沒有使用靜態分析工具
- 沒有好好測試
所有的這些原因看起來都像是在這個bug的產生中扮演了一定的角色。但有一個主導原因嗎？
對代碼的差異對比給不了多少有用的信息，在631行上的這個bug看起來怎么產生的都有可能。也許是一次代碼合并錯誤，也許是愚蠢的拷貝/粘貼造成。
事實上，你很難，或許不可能找到一個單一的為此bug負責的原因，那我們能有什么良方？很多人說是指代碼上沒有用花括號包圍的原因。例如Zed說：
很顯然寫這段Apple SSL C 代碼的家伙沒有讀過我的C語言書：永遠使用花括號！
— zedshaw (@zedshaw) February 23, 2014
這就是帕金森瑣碎定理的一個很好的例子：花費大量時間討論無關緊要的瑣事。引起這個bug的根源不是缺少花括號。有沒有花括號不會成為這個多余的goto的產生的原因。
為什么我們，程序員們，總是抱怨編碼風格問題，但卻不重視代碼審查對程序正確性的決定作用呢？雖然不好的編碼風格會隱藏程序bug，但并不是編碼 風格產生的問題。我們太重視代碼布局視覺上的問題，卻故意逃避正確性問題。如果更注重正確性，絕對不可能讓這種關鍵代碼中未經測試的情況下發布。
好的編碼風格并不能防止大部分的bug的產生——盡管有點作用。簡單的編程語言能夠減少bug的產生。代碼審查的作用更大。靜態分析能讓你避免大量的bug。
認真的測試可以捕捉并防止很多bug的產生。這就是為什么對于關鍵的軟件，比如cryptography library，有100%的測試覆蓋率。這種一眼就能看出來的bug絕對不會在這種軟件里出現。
未經測試的加密代碼是用來解密的代碼。
所以說，抱怨花括號是愚蠢的做法。相反，在這種情況下花括號會讓問題更難發現，花括號不是問題的根源，也不是問題的解決方案。大家找錯了方向。
