WHAT
在防禦式駕駛中擁有這樣一種思維，那就是你永遠也不能確定另一位老司機將要做什麼。爲了防止在其他人做出危險動作時你也不會受到傷害,你要承擔起保護自己的責任，哪怕是其他司機犯的錯誤，這就是所謂防禦性編程的意義所在。
防禦性編程是一種細緻、謹慎的編程方法。爲了開發可靠的軟件，我們要設計系統中的每個組件，以使其儘可能地“保護”自己。 我們通過明確地預見在什麼地方可能會出現問題，然後創建相對應的處理方式來完成防禦性編程
防禦性編程更是一種態度，一種提前包容他人錯誤的態度(做類型轉換後使用全等)，一種對項目負責的態度(功能編寫時兼顧用戶體驗)。
防禦性編程是提高程序魯棒性(Robust)的手段
WHY
- 防禦性編程可以增強程序的健壯性，在不正常的輸入或不正常的外部環境下仍能表現正常的程度，具體表現在
我猜到了，所以我做到了 - 防禦性編程可以節省大量調試時間。
- 防禦性編程可以使生產環境崩潰的概率變小，我們預見並處理了部分可能會導致崩潰的問題
- 防禦性編程寫的好，閒氣生的少
- 在某些高併發場景，任何微小的錯誤都可能會因爲巨大的訪問量而被放大無數倍。編寫防禦性編程是一個求穩的過程。
...
HOW
不信任所有輸入
輸入端用戶是不值得信任的！
作爲數據注入的第一道防線，我們要抱着最大的惡意對待輸入端用戶，對於某些重要的表單場景時，多一些精密校驗是必要的，有時可能用戶本身也不知道自己輸入的問題，總而言之：過程無法阻止，不過我們可以通過強校驗的方式告知用戶輸入正確的合法的數據。
要相信需求會變
在寫代碼時，要時常詢問自己：目前代碼的實現方式是否方便需求更改
相信經歷過的人會懂：
畢竟，代碼是死的，人是活的，但是人是可以被氣死的
多重校驗下優先退出
略略
考慮UI稿的極端情況
作爲設計崗，某些圖總是會按照設計師心目中最好的樣子實現，但在生產場景下作爲前端則要考慮的更多，我們並不能保證事態一定向我們(fe+ui)期望的方向發展，基於此我們同樣要向UI傳遞這種可能，也就是極端場景
不要倉促的編寫代碼
在你完全理解需求之前，永遠不要開始編碼，一定要先考慮清楚:
- 功能的實現
1.要先對功能需求深入瞭解，可以在產品/甲方將需求描述完畢後，將自己對需求的理解複述一次給對方，以確保不會出現認知偏差。這有點像戰爭開發前各個將領在首腦面前校準時間，抹平差異。
- 與後端約定的接口的數據格式
這一點好處多多，我們在約定大致的數據結構後就可以據此mock屬於該模塊的數據，在此掏出一段用以快速mock的代碼：
new Array(6).fill(null).map((_, i) => ({
i,
status: i % 3,
applicant: ['賈明', '張三', '王芳'][i % 3],
channel: ['電子簽署', '紙質簽署', '紙質簽署'][i % 3],
type: ['審批通過', '已過期', '審批失敗', '審批中'][i % 4],
detail: {
email: [
'[email protected]',
'[email protected]',
'[email protected]',
'[email protected]',
'[email protected]'
][i % 5]
},
needed: ['Y', 'N'][i % 1],
description: ['宣傳物料製作費用', 'algolia 服務報銷', '相關周邊製作費', '激勵獎品快遞費'][
i % 4
],
createTime: '2021-11-01'
}))
當與後端對接後，就可以以此將後端的數據格式再進行map一遍後進行重組，這樣則避免了從頁面進行大幅改動
3. 項目內是否有可用的公共組件、工具
略
- 組件的拆分
- 組件拆分的合理性，數據、狀態的存放是否符合最小知識原則。
- 組件的可複用性如何，是否需要可複用性。
- 數據狀態的傳遞方式是否合理。
-
工具/插件的使用是否合理
xx插件是否有必要使用，是否可能滿足未來項目的預期，爲什麼 -
其他
- 異常處理邊界行爲
- 處理弱網絡處理
- 用戶體驗優化
...
幾點提示
當然 凡事有利有弊，提高健壯性也可能會有以下弊端：
- 代碼臃腫，可能會有更多不必要的判斷
- 過度設計
- 降低代碼模塊效率
...
約定大於配置，防禦性編程不代表我們認可有人可以破壞大家的約定，也不代表我們需要編寫大量醜陋的防禦性代碼。一定要小心設計過度帶來的代碼臃腫性。健壯性與便利性總是可以討論的，關鍵在於如何取捨，而這幾點則需開發者認真考量。
以上。