kite

Une bibliothèque est un contrat différent d'une application, et c'est le point de départ de tout kite. Une application, vous pouvez la corriger après coup, son bug est vu par son auteur. Une bibliothèque s'insère dans le code d'autrui, donc votre bug devient le leur, souvent difficile à tracer parce qu'il se trouve une couche en dessous de l'endroit où il éclate.

C'est pourquoi kite n'est pas un exercice d'écriture de fonctions mais un exercice de conception d'un contrat. Toute sa valeur réside dans ce que la bibliothèque promet à l'extérieur et dans la manière dont elle tient cette promesse à l'intérieur.

Quand du code est destiné à s'insérer dans le projet d'autrui, chaque dépendance accidentelle devient un fardeau que quelqu'un doit tirer avec la bibliothèque. Chaque API publique devient une promesse que vous ne pourrez pas briser plus tard sans douleur pour ceux qui s'y sont déjà fiés. C'est une façon de penser totalement différente de celle d'une application, où vous êtes le seul utilisateur de votre propre code.

kite est construit autour d'un cœur propre avec une API publique claire et sans dépendances accidentelles. Ce qui est visible à l'extérieur est délibérément petit, car ici moins vaut plus : une surface plus petite signifie moins de promesses à tenir pendant des années.

La frontière entre ce qui est public et ce qui est interne est la ligne la plus importante de tout le code d'une bibliothèque. L'intérieur, vous pouvez le réécrire à tout moment tant que le contrat public reste le même. Le contrat public, vous n'y touchez pas sans casser les builds d'autrui. C'est pourquoi dans kite ce qui fait face à l'extérieur est étroit et réfléchi, tandis que toute la liberté reste à l'intérieur.

Cette séparation est aussi ce qui distingue une bibliothèque d'un sac de fonctions vaguement liées. Quand la surface publique est petite et cohérente, un utilisateur l'apprend une fois et peut s'y fier, au lieu de deviner laquelle de dizaines de fonctions est la bonne.

La couverture de tests n'est pas ici une décoration, c'est une promesse faite à quiconque intègre kite dans son projet : ces chemins fonctionnent et continueront de fonctionner après le prochain changement. Dans une bibliothèque cela compte particulièrement, car une régression ne vous fait pas mal à vous, mais à quelqu'un qui a construit sur votre code et n'a aucun moyen de regarder à l'intérieur.

Les tests sont en même temps une documentation vivante de la manière dont la bibliothèque est censée être utilisée. Celui qui prend kite peut lire les tests et voir l'API publique en action, au lieu d'inférer l'intention à partir des signatures.