第6章　創造復雜性的方法之一：違反你承諾過的API約定

API是某種形式的承諾：“你可以放心地完全按照我們描述的方式和我們的程序進行交互。”可一旦你的產品發布了新版本，并且在新版本中不再支持舊版本API，那就意味著你違反了這種承諾。

在模糊的哲學理論或道德范疇之外來看這件事，這種做法帶來的技術層面問題是：它給軟件增添了復雜性。

曾幾何時你的API用戶只需要調用一個簡單函數就能完成工作，而現在他們需要對你的應用進行版本檢測，并依據檢測結果調用兩個不同函數中的其中一個。為了同時兼顧新版本函數，他們必須采用和之前完全不同的方式來向函數傳遞參數，導致代碼的復雜性被無辜地加倍了。如果你改變的函數數量過多，為了適應全新API的工作方式他們可能需要將整個應用重寫！

如果你頻繁地打破API約定，那么他們的代碼為了適配也只能變得越來越復雜。唯一的額外選項就是讓他們的產品不再與你的舊版本產品兼容。因為對于用戶和系統管理員來說始終設法保證兩者之間的同步是一項極其困難的工作。想象一下如果你系統中的某款軟件突然宣布不再支持與其他軟件交互所用的API協議，這棘手的情況會讓你多么地焦頭爛額。

即便對于你個人來說，維護舊API也是痛苦的，擺脫它能夠使工作輕松不少。但我們在這里談論的復雜性并非針對你，而是針對其他程序員。

避免這個問題的最佳方案是不要發布糟糕的API。或者（從用戶的角度上看）更恰當的是，在承諾會始終維護舊版API的同時，以其他方式提供可被訪問的全新API。舉個例子，如果你想要訪問salesforce.com某些舊版本的API，只需要在和程序交互時使用不同的URL即可。而每一次在和Salesforce API進行交互時，URL事實上都為你間接地明確指定了你希望使用的API的版本是什么。這套方案在那種對產品發布進行集中管理的應用程序（例如salesforce.com）上實施起來會比較容易，在另一類需要進行分發安裝的應用程序上實現較為困難，因為分發式應用程序需要考慮代碼容量及其他的問題。如果你只擁有一只小規模的開發團隊，那么維護舊API會顯得非常吃力，因為維護這件事需要花費非常多的時間和注意力。

無論在什么情況下，對外發布一組極不穩定或是設計拙劣的API，要么會讓你的工作變得復雜（因為你需要永遠保證向后兼容），要么會讓你API用戶的工作變得復雜（因為他們為了能同時兼顧“好”版本和“壞”版本的API而不得不修改所有的應用）。

如果你選擇違背API約定并且決定不再向后兼容，請別忘了當中的一些API用戶永遠不會為了適配新的API而更新他們的產品。或許他們只是沒有足夠的時間和資源來更新他們的代碼。或許他們在使用第三方工具來和你的產品進行交互，但是第三方工具的維護者已經不再提供更新了。無論是哪種情況，如果他們修復代碼的成本高于適配你的新產品而帶來的收益，他們就會依然選擇使用你的舊版本產品，甚至永遠用下去。

這樣會帶來許多無法預見的后果。首先他們接下來的所有開發工作都會圍繞著你產品的舊版本進行。其次為了保證舊版本產品的正常工作，他們不得不使用某些舊版本的系統類庫。又因為你的產品無法工作在新的操作系統上工作，導致他們無法對操作系統進行升級。鑒于此時操作系統和舊版本產品間接綁定在了一起，那么當舊操作系統出現了一些沒有修復的安全漏洞時，他們該怎么辦？又或者當舊版本產品上出現了一些安全問題時，他們又該如何是好呢？當你選擇打破你的API約定時，你需要對所有的這些情況負責。

還沒完，即使你從一開始不提供API，也會帶來相同的結果。為了設法能夠和你的系統進行交互，開發者們會創建瘋狂的“黑客代碼”，同樣因為黑客技術無法工作在新版本系統上，所以他們也無法對操作系統進行升級。但這種情況不像違背API約定那么糟糕，因為你從沒有對這些黑客技術做出任何承諾。任何人都不應該對這類黑客方案能夠長久工作下去抱有期望。

但如果公司管理層命令他們必須將自家產品和你的產品進行集成，這些聰明的家伙也總能想到辦法的，即使只能和某個特定的版本集成。

所以在研發資源充裕的情況下話還是應該對外提供一組可供訪問的API。但是在實現之前請務必對API進行精心設計。你可以在正式發布之前自己多嘗試使用看看。還可以細心地對你的用戶進行調研并且發掘他們究竟會如何使用你的API。總的來說，在發布之前就需要盡你的全部所能來保證API的穩定。在未來你需要投入多少年精力來維護API并不重要，重要的是在發布之前采取一些明智的手段來了解API在現實場景里應該如何工作。

API一旦發布成功，如果條件允許的話，拜托請千萬不要違背你的API約定。

——Max