kite

Una libreria è un contratto diverso da un'app, ed è il punto di partenza di tutto kite. Un'app puoi correggerla a posteriori, il suo bug lo vede il suo autore. Una libreria si inserisce nel codice altrui, quindi il tuo bug diventa il loro, spesso difficile da rintracciare perché sta uno strato sotto il punto in cui esplode.

Per questo kite non è un esercizio di scrittura di funzioni ma un esercizio di progettazione di un contratto. Tutto il suo valore sta in ciò che la libreria promette all'esterno e in come mantiene quella promessa all'interno.

Quando il codice deve inserirsi nel progetto altrui, ogni dipendenza accidentale diventa un peso che qualcuno deve trascinare con la libreria. Ogni API pubblica diventa una promessa che poi non puoi infrangere senza dolore per chi vi ha già fatto affidamento. È un modo di pensare del tutto diverso da quello di un'app, dove sei l'unico utente del tuo stesso codice.

kite è costruita attorno a un nucleo pulito con un'API pubblica chiara e senza dipendenze accidentali. Ciò che è visibile all'esterno è deliberatamente piccolo, perché qui meno è più: una superficie più piccola significa meno promesse da mantenere per anni.

Il confine tra ciò che è pubblico e ciò che è interno è la riga più importante di tutto il codice di una libreria. L'interno lo puoi riscrivere in qualsiasi momento finché il contratto pubblico resta lo stesso. Il contratto pubblico non lo tocchi senza rompere le build altrui. Per questo in kite ciò che guarda all'esterno è stretto e ponderato, mentre tutta la libertà resta all'interno.

Questa divisione è anche ciò che distingue una libreria da un sacco di funzioni vagamente collegate. Quando la superficie pubblica è piccola e coerente, un utente la impara una volta e può farvi affidamento, invece di indovinare quale tra decine di funzioni sia quella giusta.

La copertura di test qui non è un ornamento, è una promessa fatta a chiunque inserisca kite nel proprio progetto: questi percorsi funzionano e continueranno a funzionare dopo la prossima modifica. In una libreria questo conta in modo particolare, perché una regressione non fa male a te, ma a qualcuno che ha costruito sul tuo codice e non ha modo di guardare all'interno.

I test sono al tempo stesso documentazione viva di come la libreria vada usata. Chi prende kite può leggere i test e vedere l'API pubblica in azione, invece di dedurre l'intenzione dalle firme.