這里的接口指的是團隊開發(fā)中，模塊間的函數(shù)接口，或者跨進程的協(xié)議接口。
俗話說有人的地方就有江湖，在軟件開發(fā)當中，有人的地方就有接口，有接口就要考慮兼容性問題。平心而論，一般新軟件，前面的版本，考慮太多接口兼容性問題不現(xiàn)實，因為前面的版本改動特別大，兩個版本之間面目全非的情況比比皆是。但是到了一定階段，接口就急需要穩(wěn)定，因為不兼容的接口帶來的成本太高了。
最簡單的接口兼容性方案就是永遠只新增接口，然后老老實實的等著舊接口自然消亡，當然這個過程非常痛苦，但是習慣了也沒有什么。這里還是有幾條建議，可以緩解這個痛苦的。
既然選擇了新增接口來支持兼容性，就不要再去嘗試其他方案，也就是將這條路走到黑，避免多種接口兼容性策略同時生效，反而讓使用者糊涂。
項目團隊中形成共識，每當新接口和老接口有替換關(guān)系時，就盡量在主分支主動升級到新接口，然后讓新接口自然在未來某個版本中自然生效。
新接口和老接口在命名上應該有一個自然的替換關(guān)系，比如說老接口叫 GetBigBook，新接口叫做GetBigBook2,雖然很俗氣，一旦團隊內(nèi)都采用類似風格，也可以接受。將來排查那些GetBigBook沒有替換完畢的時候也很方便。
如果新增了參數(shù)，盡量將新增的部分放在尾部或者頭部，別頭部放一個，尾部放一個，減少使用者更換接口時的不適感。好的新接口設計，甚至可以實現(xiàn)批量替換。這里不詳細描述了。跨進程的接口協(xié)議，可以在使用側(cè)先用函數(shù)封裝一下組裝報文的部分，后面報文格式變了，最終也就變成了函數(shù)的替換。
