您是否應該編碼以保護您的應用程序免受不良編碼器的侵害？

Question

毫無疑問，我們應該編寫我們的應用程序來保護自己免受惡意，好奇和/或粗心的用戶的侵害，但是對於當前和/或未來的同事呢？

例如，我正在編寫一個基於Web的API接受來自用戶的參數。其中一些參數可能會映射到配置文件中的值。如果用戶使用URL混亂併爲該參數提供了一個無效值，那麼當嘗試從不存在的配置文件部分讀取時，我的應用程序會出錯。所以當然，我在嘗試從配置文件中讀取參數之前擦除參數。現在

，如果在路上，另一個開發適用於該應用程序是什麼，添加了對這個參數會通過洗滌過程中另一個有效的值，但不會添加相應的部分配置文件。請記住，我只保護應用程序免受不良使用者的影響，而不是不好的編碼者。我的應用程序會失敗。一方面，我知道所有的改變都應該在進入生產之前進行測試，而且這樣的測試毫無疑問會在一個體面的測試環節中出現，但另一方面，我嘗試構建自己的應用程序來抵制失敗。儘可能最好。我只是不知道在可能的故障點列表中包括修改我的代碼是否「正確」。

對於這個項目，我選擇不檢查，如果配置文件的相關部分存在。作爲當前的開發人員，我不會允許用戶指定會導致失敗的參數值，所以我期望未來的開發人員不會將行爲引入可能導致失敗的生產環境中......或者至少消除這樣的在測試過程中。

您認爲如何？

懶惰......還是哲學上的聲音？

Answer 1

「我只是不知道這是否是‘正確的’通過潛在的故障點的列表同事，包括我的代碼修改。」

防止你的同事破壞事情是不對的。

你不知道你的軟件將被用於什麼新目的。你不知道將來如何修改它。

取而代之，請執行此操作。

寫入簡單正確的軟件，投入生產，並停止擔心有人「打破」的東西。

如果您的軟件實際上是簡單，其他人可以維護它而不會破壞它。

如果弄得太複雜，他們會（一）打破它反正，不管你做的和（b）恨你使它複雜的一切。

因此，儘可能簡單地完成這項工作。

Answer 2

我認爲這是未來開發者的責任，以確保她不會引入錯誤或故障點到你的代碼。當您從項目中籤名（如果曾經？！），那麼簽名過程的一部分至少應該是代碼儘可能沒有錯誤地出現，這會限制您爲將來的問題承擔的責任。

如果您的代碼保存在版本控制系統中，那麼創建一個標記可以標記您移交代碼的位置，從而使您可以將當前代碼庫與原始代碼進行比較一些人可能會試圖責怪你（如果這是你來自的角度！），所以你可以證明它是你的原始實現所引起的這些錯誤所做的修改。 （當然假設這些實現確實會引起意外的行爲，並且不會修復你的「無bug」代碼grin）。我已經在過去使用，以確保數據的完整性（它也不是省油的證明），

一種方法是在特定值的特定偏移來檢查輸入，確保輸入的是不被污染。

希望有所幫助。

Answer 3

這聽起來像你採取合理的措施防止不稱職做輸入一些擦洗。我不認爲您有責任保護您的代碼不被濫用或輸入錯誤。我會更進一步，並說只要你的代碼明確地記錄什麼是和不是一個可接受的輸入，那麼你已經做得夠多了，尤其是如果添加的「白癡錯誤檢查」代碼臃腫或（特別是）較慢。

準確記錄哪些輸入可接受的過程對於內部api是合理的。話雖如此，我經常在防守方面進行編碼，但這主要是由於我所處的環境以及我對其餘代碼的信任程度。

Answer 4

這兩種方式都很好，哲學上講。我會根據你認爲這會發生的可能性做出判斷。如果你幾乎可以肯定有人會以這種方式破壞你的代碼，那麼提供一個能夠在事情發生時就能捕捉到的檢查可能是有禮貌的。

如果看起來不太可能，那麼這只是他們工作的一部分，以確保他們不會破壞代碼。

在這兩種情況下，雖然，你的技術說明（或其他適當的文檔）應清楚地表明，當一個變化了時，還需要其他的改變。

Answer 5

我會用一個行內註釋爲未來的開發者，或者像我這樣的開發誰往往忘記了什麼事在應用程序的每一個部分後，我還沒有了幾個月的工作。

不用擔心實際的編碼會影響未來的編碼器，這是不可能的。只需添加所需的所有信息即可支持或擴展您在源代碼環境中執行的操作。

這是文檔，正如Steve B.提到的。我只是確保它不是外部的，因爲這有一種迷失的傾向。

Answer 6

懶......或哲學的聲音？

懶......和傲慢。通過使錯誤很快顯示出來的方式進行編碼，您可以保護應用程序免受自己的錯誤的侵害，同時也可以避免與其他錯誤一樣的錯誤。每個人犯的錯誤超出他們的想象。

當然，如果參數檢查是基於配置文件，而不是添加更多代碼來檢測配置文件和參數檢查是否匹配，那麼只會添加一個新值的地方並且不一致是不可能的。