PHP 中的防禦性程式設計

菲納格動態逆定律：

會出錯的，終將會出錯 —-  在最糟糕的時刻。

防禦性程式設計（Defensive Programming）是什麼意思

防禦性程式設計，簡單的說，就是在程式設計的時候有目的地預測可能的故障點。目的是在那些可能發生的問題發生前解決它們。你看見了問題，對吧？預測意料之外的事情本來就有內在的難度，當你想要預測意料之外的事情並且解決它就更是難上了好幾倍。

下面我們看幾個實際的例子。

條件語句

這是最容易進行防禦性程式設計的地方之一，也是最容易滿足的地方。在用PHP程式設計的許多情況下你不會需要“else”。

假設，你在寫一個函式並且需要一個條件語句。在這裡，你只需要為你特定的變數使用三個條件語句如下：

if ($var == a) { }
else if ($var == b) { }
else if ($var == c) { }

沒有其他可能性了，你說，並且繼續碼程式碼。但是，讓我們在這裡停一下。我知道你知道這裡沒有其他可能性了。並且我相信你。但有時候（不可預測的）情況會發生。我們忘掉了一些情況。我們檢查錯誤。我們最終重用了一些程式碼，超出了原本的預定範圍。突然我們有了洩露錯誤或者有時候是靜默的錯誤狀態，因為我們沒有使用catch。使用else程式碼塊。在使用switch時要使用default。用它們來返回或者記錄錯誤，這樣你才知道發生了什麼（如果發生了的話）。雖然會多用兩行程式碼，但當一些你無法預測的事情發生時，這是值得的。

絕不相信使用者輸入

你以前有沒有聽說過這個說法？大多數程式設計師聽過。這有一點含糊，通俗點講，理所當然。但它是真理。你絕不應該相信使用者輸入。這不是說你假設所有使用者是瘋狂的駭客，他們使用一些精心設計的命令來摧毀你的應用。沒有必要妄想。但是，你應該假設使用者不知道你的程式碼，他們不知道你需要填寫什麼引數，或者引數應該多長。他們不知道什麼檔案型別或者什麼大小能上傳（即使應用告訴了他們）。偶爾他們會是機器或者駭客並且他們希望在他們的輸入中執行指令碼，有時候甚至是在登陸後的輸入中。你怎麼知道你能相信認證或者驗證碼能在使用者輸入之前提供一個安全的堡壘？

答案：絕不。

你絕不相信使用者輸入。如果你信任的使用者輸入，那麼你永遠不會有一個突破。明白了嗎？所以總是要評估你的輸入，一定要保證你在處理資料尤其是要存入資料庫或者要把它展示出來時使用了合適的技術。因此 – 絕不相信輸入，即使來自不是使用者的輸入的地方 – 輸入驗證永遠是你的朋友。看看 Survive the Deep End: PHP Security 並且使用 validation library 吧。

對你的程式碼的假設

不要假設任何事情。如果前兩個主題教會我們一些事情的話，那就是我們不應該做任何假設。作為程式設計師，尤其是致力於一個專案太久後，我們開始做很多假設。我們假設使用者知道一些我們知道的事情。不一定是技術細節，也可以是程式的功能性細節。我們假設使用者知道檔案能有多大因為。。。我們已經知道。或者他們知道為了讓郵件指令碼。。。但事實不是，他們不知道以上任何東西。這好像更多的是前端的工作，但明顯的是你在後端仍然要處理使用者行為和使用者輸入，所以值得好好想想。

另一個許多程式設計師都會做的驚人的假設是我們在任何時候對於我們的函式，類或者其它程式碼段的明顯的功能屬性。一個具有防禦性的程式設計師會仔細考慮的不僅僅是用一般的文件來描述函式是幹什麼的——他們也將寫下他們對輸入，引數，用例，或任何其他類似的東西做出的任何假設。因為我們都是人，我們過一段時間會忘掉一些事。我們最後也很可能會面臨其他人維護，擴充套件或者替換我們的程式碼。如果沒有別的，回想一下，程式設計是發生在一個充滿技術變革的世界裡。如果你的應用仍然能使用幾年，可能會升級PHP版本並且失去一些功能，或者一些你自己程式碼裡面具有互動的元件之間需要改變。預測這些是很困難的，所以好的註釋和文件是非常重要的。

視野狹窄

另一件可以使我們忘記好的評論實踐以及標準的東西是視野狹窄。許多程式設計師都具有視野狹窄的毛病。你知道這種感覺 - 你解決問題，你處於最佳狀態。你覺得與你的音樂(或沒有)獨立於自己的小世界中，並且你就在編碼，突然兩小時過了，你意識到你已經寫了無數行沒有註釋的程式碼。我們所有人偶爾都會遇到這種事情，但重要的是在某處發現這個情況並且補上應有的註釋。

語法和命名的一致性

一致性是一個灰色地帶 – 它更多的是關於編碼標準之類的，但它和防禦性程式設計也有聯絡。在PHP中，有標準規範你的程式碼格式以便別人檢視，或者你以後使用。但常常沒人讓你的程式碼標準化。但是無論你是否按照標準編碼，你至少要保持一致性 – 這能讓你少犯錯誤。這對於需要大量時間返回並且修復的小的語法錯誤尤其適用。如果你總是使用相同的間隔，格式和語法，命名規格等等你就能更好的避免犯錯以至於誤讀你自己的程式碼。你更可能快速瀏覽程式碼並且找到你需要的東西。

總結

總的來說，除去使用者行為和動作，不要對你的程式做任何假設。假設是具有防禦性程式設計習慣的程式設計師最大的敵人。不要假設你不需要 default 語句或者 else 程式碼塊。儘量使用正確的使用者錯誤資訊，警告，日誌或者任何其它你假設不會用到的程式碼。你的假設通常是正確的 – 但我們不在乎。我們在乎的是它們出錯的時候。一定要計劃得好，準備著你可能需要在幾小時，幾周，幾個月甚至幾年後回顧你的程式碼，或者其他人需要 – 相應的就要好好寫文件。別假設它永遠不需要升級，擴充套件或者維護。那是無知的，在更多的情況下是疏忽。有時候保持一顆防禦性程式設計的心能幫你更有效更安全地估計，計劃和程式設計。