Dość często miewam dyskusje o backward compatibility i wersjonowaniu API.
Jestem z obozu, który uważa, że każda breaking change to moment, gdy ktoś zabija kotka. Ja nie chcę, by kotki ginęły, więc staram się projektować API czy struktury danych tak, by były one jak najbardziej otwarte na ewolucję bez konieczności stosowania specjalnych narzędzi.
Preferuję jak najbardziej low-levelowe API, uznając, że klient powinien móc je obudować w dowolny sposób. Najlepiej, jeśli takie API nie wprowadza pojęć typu projekty czy dokumenty, tylko operuje na danych na jak najniższym poziomie. Jeśli użytkownik chce mieć projekty, to po prostu sam sobie je stworzy.
Nie lubię enumów. Jeśli jednak są już potrzebne do zaprezentowania pewnych stanów, chętniej dodam nowe pole dla większej granulacji, niż będę zmieniał istniejącą listę enumów. Choć szczerze mówiąc, ponieważ preferuję API samowystarczalne, te stany zwykle mają charakter czysto informacyjny.
Oczywiście zawsze może pojawić się konieczność wprowadzenia breaking change. Lata pracy pokazały mi jednak, że prawie zawsze można tego uniknąć. A to oznacza, że użytkownik API nie zabije żadnego kotka.
Podobne postybeta
WWŚ i wielkie hałdy książek
Case insensitive OS ma pewne problemy ;-)
Ile z obligacji... odsłona 2 ;-)
"Dziennikarze" to debile
Czytelnictwo ;-)
Brak komentarzy:
Prześlij komentarz