為什么開發(fā)者不編寫安全的代碼？我們在這并不是要再一次討論「整潔代碼」。我們要從純粹的實用觀點出發(fā)，討論軟件的安全性和保密性。是的，因為不安全的軟件不僅無用，而且還可怕。我們來看看什么是不安全的軟件。

• 1996年6月4日，歐洲航天局的 Ariane 5 Flight 501 在起飛后 40 秒被引爆。因為導航軟件里的一個 bug，這個價值 10 億美金的運載火箭不得不自毀。
• 
  
•  
• 1991年2月25日，MIM-104 Patriot（愛國者）里的一個軟件錯誤使它的系統(tǒng)每一百小時有三分之一秒的時鐘偏移，導致定位攔截入侵導彈失敗。結(jié)果伊拉克的飛毛腿導彈擊中宰赫蘭（沙特阿拉伯東北部城市）的一個美軍軍營，28 人死亡，100 多人受傷。
• 其他案例，請參見《Bug 引發(fā)的 18 次重大事故》。

這應(yīng)該能夠說明編寫安全軟件的重要性了，尤其在特定的環(huán)境中。當然也包括其他用例中，我們也應(yīng)該意識到我們的軟件 bug 會導致什么后果。

防御性編程初窺

為什么我認為在特定種類的工程中，防御性編程是解決這些問題好辦法？

抵御那些不可能的事，因為看似不可能的事也會發(fā)生。

防御性編程中有很多防御方式，這也取決于你的軟件項目所需的「安全」級別和資源級別。

防御性編程是防御式設(shè)計的一種形式，用來確保軟件在未知的環(huán)境中能繼續(xù)運行。防御性編程的實踐往往用于需要高可用性、安全性、保密性的地方。—— 維基百科

我個人相信這種方法適合很多人參與的大型、長期的項目。例如，一個需要大量維護的開源項目。
我們來探索一下我提出的關(guān)鍵點，來完成一個防御性編程的實現(xiàn)。

永遠不要相信用戶輸入

設(shè)想你總是獲取到你不想要的東西。因為像我們說過的，我們預期的是異常情況的出現(xiàn)，（所以）要時刻防備用戶輸入以及通常會傳入你系統(tǒng)的東西，這是你成為一個防御性程序員的方法。試著做到盡可能的嚴格，確保輸入的值就是你所期望的值。

數(shù)據(jù)庫抽象化

在 OWASP Top 10 Security Vulnerabilities 排首位的是注入攻擊。這意味著有些人（很多人）還沒有使用安全的工具來查詢數(shù)據(jù)庫。請使用數(shù)據(jù)庫抽象包或庫。在 PHP 里你可以使用PDO 來確�；�本的注入攻擊防范。

不要重復發(fā)明輪子

你不用框架（或微框架）嗎？好吧恭喜你，你喜歡毫無理由地做額外的工作。這并不僅跟框架有關(guān)，也意味著你可以方便地使用已經(jīng)存在的、經(jīng)過測試的、受萬千開發(fā)者信任的、穩(wěn)定的新特性，而不是你只為了自己從中受益而制作的東西。你自己創(chuàng)建方法的唯一原因是你需要的東西不存在，或存在但不符合你的需求（性能差、缺失特性等等）。
這就是所謂的智能代碼重用。擁抱它吧。

不要相信開發(fā)者

防御性編程與防御性駕駛相關(guān)聯(lián)。在防御性駕駛中，我們假設(shè)周圍的每個人都可能犯錯。所以我們要留意別人的行為。相同概念也適用于防御性編程，我們作為開發(fā)者不要相信其他開發(fā)者的代碼。我們同樣也不要相信我們的代碼。
在很多人參與的大型項目中，我們有許多方式編寫并組織代碼。這也導致混亂甚至更多的 bug。這也是我們需要加強規(guī)范代碼風格和代碼檢查的原因，讓生活更輕松。