kite

Una biblioteca es un contrato distinto de una aplicación, y ese es el punto de partida de todo kite. Una aplicación puedes corregirla después, su bug lo ve su autor. Una biblioteca se integra en el código ajeno, así que tu bug se convierte en el suyo, a menudo difícil de rastrear porque está una capa por debajo del lugar donde estalla.

Por eso kite no es un ejercicio de escribir funciones sino un ejercicio de diseñar un contrato. Todo su valor reside en lo que la biblioteca promete por fuera y en cómo mantiene esa promesa por dentro.

Cuando el código va a integrarse en el proyecto ajeno, cada dependencia accidental se convierte en una carga que alguien tiene que arrastrar con la biblioteca. Cada API pública se convierte en una promesa que luego no podrás romper sin dolor para quienes ya se apoyaron en ella. Es una forma de pensar totalmente distinta de la de una aplicación, donde eres el único usuario de tu propio código.

kite está construida en torno a un núcleo limpio con una API pública clara y sin dependencias accidentales. Lo que es visible por fuera es deliberadamente pequeño, porque aquí menos es más: una superficie más pequeña significa menos promesas que mantener durante años.

La frontera entre lo que es público y lo que es interno es la línea más importante de todo el código de una biblioteca. El interior puedes reescribirlo en cualquier momento mientras el contrato público siga siendo el mismo. El contrato público no lo tocas sin romper las builds ajenas. Por eso en kite lo que mira hacia fuera es estrecho y meditado, mientras que toda la libertad se queda dentro.

Esa división es también lo que distingue una biblioteca de un saco de funciones vagamente relacionadas. Cuando la superficie pública es pequeña y coherente, un usuario la aprende una vez y puede apoyarse en ella, en lugar de adivinar cuál de docenas de funciones es la correcta.

La cobertura de pruebas aquí no es un adorno, es una promesa hecha a quien integre kite en su proyecto: estos caminos funcionan y seguirán funcionando tras el próximo cambio. En una biblioteca eso importa especialmente, porque una regresión no te duele a ti, sino a alguien que construyó sobre tu código y no tiene forma de mirar dentro.

Las pruebas son al mismo tiempo documentación viva de cómo se debe usar la biblioteca. Quien recurre a kite puede leer las pruebas y ver la API pública en acción, en lugar de inferir la intención a partir de las firmas.