背景

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

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

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

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

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

防御式編程

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

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

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

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

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

斷言

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

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

異常

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

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

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

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

契約式編程

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

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

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

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

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

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

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

烏托邦

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

警告

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

此文一出，很有可能引發(fā)雙方混戰(zhàn)，紅與黑，天災(zāi)還是近衛(wèi)，聯(lián)盟還是部落，Choose your side。