讓系統很容易就壞掉，比較容易寫出健康的系統

個人非常同意此篇文章

儘量不要做 defensive programming、儘量不要由系統去修正預期外的狀況

當 input 不如期待中的出現時，直接 throw exception 讓系統爛掉，讓用戶來反應問題，再接著修正它，這樣才容易找到一些隱藏在其中、原本沒考慮到的問題

fail fast!

延伸閱讀：

Defensive Programming 防禦性程式設計

defensive 策略是一種 Hide the Problem Programming

太 defensive 的確就像國防布不好，等到發現問題很大再來治療都要花更多的功夫

這在 API 對接的情況比較好做，也很直覺，因為資料流是「一筆一筆」的經過 API，可以比較容易地定出 schema 與各種合法/非法情況

不過我自己的經驗是在大量資料流＋外部資料的過程中，這件事情的難度就直線上升了

比如說 input 從一筆資料變成一張 table，它可以很大

原本大也不是什麼問題，只要他不太會變動，就像研究的 dataset，清過一次就搞定了

但這時候再加上外部的因素（比如 crawler 爬到的資料，或是對接的夥伴提供的 API 等等）

很多時候欄位就只是字串，它不但可以塞任何東西，還很可能每天出現新的未預期的垃圾

做線上服務就像開飛機，需要每天吃新的資料當做燃料，飛機也一直在飛

客戶要求你一定得立刻、現在吃最新的燃料，但我們又不能讓飛機吃到餿水油就爆炸

所以只能在飛機的重要零件都加上某種程度的 defensive programming 做取捨

像你貼的文章裡面有說到「總是有需要檢查的時候，特別是資料第一次輸入進系統的邊界情況」

放在我自己的經驗上比較像是「整間公司都可以算是系統邊界」

當然這跟 business model、公司組織都有很大的關係

有些 business model 比較容易遇到外部垃圾資料，那就要比較多的 defensive 處理

有些公司組織已經比較大、業務穩定、有本錢慢慢來，那在對接之前就可以做很多嚴格的資料管理，甚至談判能力也會提昇（e.g. 你們資料爛掉了是你們的事情，我們不負責）

而前面提到的資料流量與流速，則是從旁讓整件事情變得更複雜

想像一間手工麵包店只有五個師父在揉麵團，跟一間工廠每天產出十萬個麵包，要做好品質控管的難度、出問題之後檢測哪個環節出錯的難度，都是後者遠遠大過前者。

我們會看到食品業有各種制式的品管制度，也是遇到各種食安問題之後加上的機制。食物尚且如此，資料這種摸不著、又還在起步、沒什麼人願意投資的服務（相對於很潮的 AI 應用），更是不容易爭取到資源在品質管控上了。

（寫得有些 random 請見諒）