kite

Biblioteka to inna umowa niż aplikacja i to jest punkt wyjścia całego kite. Aplikację możesz poprawiać po fakcie, jej błąd widzi jej autor. Bibliotekę wpina się w cudzy kod, więc twój bug staje się ich bugiem, często trudnym do namierzenia, bo leży warstwę niżej niż miejsce, w którym wybucha.

Dlatego kite nie jest ćwiczeniem z pisania funkcji, tylko ćwiczeniem z projektowania kontraktu. Cała wartość siedzi w tym, co biblioteka obiecuje na zewnątrz i jak pilnuje tej obietnicy w środku.

Kiedy kod ma być wpięty w cudzy projekt, każda przypadkowa zależność staje się ciężarem, który ktoś musi wciągnąć razem z biblioteką. Każde publiczne API staje się obietnicą, której później nie złamiesz bez bólu dla tych, którzy już na nim polegli. To zupełnie inny sposób myślenia niż przy aplikacji, gdzie jesteś jedynym użytkownikiem własnego kodu.

kite jest budowana wokół czystego rdzenia z jasnym publicznym API i bez przypadkowych zależności. To, co widoczne na zewnątrz, jest celowo małe, bo mniej znaczy tu więcej: mniejsza powierzchnia to mniej obietnic do dotrzymania na lata.

Granica między tym, co publiczne, a tym, co wewnętrzne, jest w bibliotece najważniejszą linią w całym kodzie. Wnętrze możesz przepisać w każdej chwili, dopóki publiczny kontrakt zostaje ten sam. Publicznego kontraktu nie ruszysz bez złamania cudzych kompilacji. Dlatego w kite to, co na zewnątrz, jest wąskie i przemyślane, a cała swoboda zostaje w środku.

Ten podział jest też tym, co odróżnia bibliotekę od zbioru luźno powiązanych funkcji. Kiedy publiczna powierzchnia jest mała i spójna, użytkownik uczy się jej raz i może na niej polegać, zamiast zgadywać, która z dziesiątek funkcji jest tą właściwą.

Pokrycie testami nie jest tu ozdobą, tylko obietnicą złożoną każdemu, kto wepnie kite do swojego projektu: te ścieżki działają i będą działać po kolejnej zmianie. W bibliotece to szczególnie ważne, bo regresja nie boli ciebie, tylko kogoś, kto zbudował na twoim kodzie i nie ma jak zajrzeć do środka.

Testy są jednocześnie żywą dokumentacją tego, jak biblioteka ma być używana. Ktoś, kto sięga po kite, może przeczytać testy i zobaczyć publiczne API w działaniu, zamiast domyślać się intencji z sygnatur.