背景

事情的來由還要從幾十幾億年前的一次星球大爆炸說起，sorry，背錯臺詞了，是從幾天前討論接口返回數據和幾個月前討論課件本地數據結構說起，簡單的說，就是碰到約定好的內容出現異常，是我們在程序中內部作兼容處理，還是拋出去。

打個比方，我們要解析一段json，約定這個json的格式，只能是正常格式，或者是空，那么一旦返回json的方法返回了一個『既不是正常格式，又不是空的異常值』，程序該如何處理呢?

小花：一旦碰到約定異常，程序必須兼容處理，一定不能讓程序Crash小Fa：一旦碰到約定異常，就必須拋出去，告知約定有誤，找出具體錯誤原因

這個問題，相信只要是程序猿基本都遇到過，舉個最常見的栗子，NullPointerException，假如我們要從json中取一個字段，突然發現發生了NullPointerException，一些開發者認為是數據問題，那么把json中的這個字段改正確就行了;還有一些開發者認為是程序問題，認為程序需要做非空判斷，再去使用。我相信這兩種程序猿都有自己的理由，***種程序簡潔明了，代碼邏輯干凈，但一旦出錯，就會崩潰，第二種程序耐操，隨你數據怎么錯，我都能不Crash，但代碼中到處存在非空判斷，臃腫、重復。

生存還是毀滅，這是一個問題!

防御式編程

就在我們為了這個問題而爭論的時候，突然有一個姓康的同事，施法祭出了一塊磚頭(《代碼大全2》，近900頁，相當于3本《Android群英傳》)，我一度以為他想砸在我的臉上，正當我準備閃避的時候，他翻到了這塊磚頭的第八章，幾個大字赫然印入了我的視線——『防御式編程』。 

果然是老司機，居然可以從防御性駕駛中悟出防御性編程，說好的編程不開車，開車不編程呢?

這位作者編程厲不厲害我不知道，但我知道，論開車，一定沒有何老師diao!

OK，《代碼大全》給我們提供了一個定義——『防御式編程』，說白了，就是『人類都是不安全、不值得信任的，所有的人，都會犯錯誤，而你寫的代碼，應該考慮到所有可能發生的錯誤，讓你的程序不會因為他人的錯誤而發生錯誤』

在書中，作者告訴我們，程序需要對可能的錯誤輸入，做出兼容，例如一個除法的函數，你必須判斷分母可能為0的情況，從而給調用者返回錯誤提示。另外，一般的高級編程語言，都提供了『斷言』和『異?！粌煞N方式來進行錯誤處理。

斷言

斷言，是一種在開發階段使用的，讓程序在運行時進行自檢的代碼，斷言為真，那么程序運行正常，斷言為假，那么程序運行異常退出。等等，防御式編程不是說好的要兼容異常嗎，為什么會退出?實際上，作者的意思是，先斷言、后處理錯誤，而斷言是在開發環境中的，正式上線后是不會有斷言的。 

但實際上，這是一個悖論，開發階段的錯誤處理代碼在開發階段被斷言給攔截掉了，但錯誤處理代碼也是人寫的，那么如何去檢測『錯誤處理代碼可能發生的錯誤』呢?

異常

當代碼出現問題時，可以通過拋出異常來進行通知，如果你無法處理，則可以交給外界進行處理。這個不多說，畢竟大部分代碼，如果有異常，最簡單的就是try catch了，我甚至見過把所以代碼直接try catch的，你是有多不相信人類。

所以我覺得防御式編程用久了，會不會開始懷疑人生，果然，在往后翻幾頁，作者也給出了建議。 

借用奇異博士的一句臺詞——『你TM居然把警告寫在咒語的下一頁』!

簡而言之，防御式編程，就是持懷疑態度審視所有的代碼，但這個和我們討論的主題還是略有不同的，我們討論的主題是『已經有了約定，但返回了約定之外的內容』。

契約式編程

就在我們討論的時候，天空突然飄來五個字——那都不是事，哦不對，是『契約式編程』。

這個好像有點像!我們先來簡單的看下什么是契約式編程，簡單的說，契約作用于兩方，每一方都會完成一些任務，從而促成契約的達成，但同時，每一方也會接受一些義務，作為制定契約的前提，有任意一方無視了必盡義的義務，則契約失敗。

契約式編程要求我們在『前提條件』、『后繼條件』和『不變量條件』進行契約的檢查。類似的，例如檢查參數，一旦參數不對，當即撕毀契約。這一點，現在很多新的語言都支持了，例如Swift，就支持對參數進行約束檢查，這就是一種類契約式編程。

契約所約束的，是『一個為了確保程序正常運行的條件』，一旦契約被損毀，只有一個原因，那就是程序出了Bug，例如一個數據字段，在我處理的時候，必須保證是不為空的，那么誰來保證這一點呢，一定是我的調用方(或者說是其它模塊)，所以，一旦出現問題，應該有調用方來檢查，確保調用的時候，必須是不為空的。

這讓我想到了剛開始在面向日本人編程時期的一些事，日本人的做事風格是出了名的謹慎和詳細，每一個方法、函數，在詳細設計的時候，就已經把參數、返回值，已經它們的類型和所有可能的值都設計好了，每個方法之間有著明確的界限，如果你的方法因為傳入的參數不在設計范圍內而導致錯誤，你完全可以去找調用方，要求他按照設計來進行調用。不得不說，這應該是契約編程的***實踐。日企普遍使用這種方式其實還有一個原因，那就是可以嚴格區分責任，讓每個人都不必為了遷就他人的錯誤而進行『艱難的編碼』。每個人按照契約處理好自己的事情，讓損毀契約的人承擔責任。

再引申一下，這和現在的『面向接口編程』也非常類似，兩個模塊之間，定義好調用、處理的接口，而具體的實現，對方都不用關心，只要安裝協議的接口來進行開發就可以了，但光有接口也不夠，還需要契約來做進一步的約束，例如參數、返回值的約束。

無獨有偶，在《代碼大全》中，作者也提出了『進攻式編程』，其實和契約編程，有異曲同工之妙。 

烏托邦

OK，夢醒了，讓陽光照進現實。以上兩種編程方式，都是非常理想化的編程，但在一般的公司里面不論是防御還是契約，實現起來都是比較困難的，例如前端與后端的接口、不同部門同事的交流，按照契約式編程，沒人Care你的契約，按照防御式編程，代碼慘不忍睹，還容易漏掉防御。那么到底該怎么辦呢，我認為，如果能在公司層面推廣契約式編程，首先是對開發效率的提升，讓每個人都對自己寫的代碼負責，在開發者之間建立良好的信任關系，同時也能減少不必要的溝通成本和精力。但同時，必要的防御式編程也是不能少的，這是保證程序健壯、穩定的前提。怎么說呢，中國人民秉承了千百年的傳統——『中庸之道』，契約還是防御，視情況而定，這是平衡的藝術。

警告

本文請使用防御式閱讀，每個人都會犯錯，歡迎留言交流。

此文一出，很有可能引發雙方混戰，紅與黑，天災還是近衛，聯盟還是部落，Choose your side。