kite

Eine Bibliothek ist ein anderer Vertrag als eine App, und das ist der Ausgangspunkt von ganz kite. Eine App können Sie nachträglich reparieren, ihren Fehler sieht ihr Autor. Eine Bibliothek steckt im Code eines anderen, also wird Ihr Bug zu ihrem Bug, oft schwer aufzuspüren, weil er eine Schicht tiefer sitzt als die Stelle, an der er hochgeht.

Deshalb ist kite keine Übung im Schreiben von Funktionen, sondern eine Übung im Entwerfen eines Vertrags. Sein ganzer Wert steckt darin, was die Bibliothek nach außen verspricht und wie sie dieses Versprechen im Inneren einhält.

Wenn Code in das Projekt eines anderen eingebaut werden soll, wird jede zufällige Abhängigkeit zu einer Last, die jemand mit der Bibliothek hereinziehen muss. Jede öffentliche API wird zu einem Versprechen, das Sie später nicht ohne Schmerz für die brechen können, die sich schon darauf verlassen haben. Das ist eine völlig andere Denkweise als bei einer App, wo Sie der einzige Nutzer Ihres eigenen Codes sind.

kite ist um einen sauberen Kern mit klarer öffentlicher API und ohne zufällige Abhängigkeiten herum gebaut. Was nach außen sichtbar ist, ist bewusst klein, denn weniger ist hier mehr: eine kleinere Oberfläche bedeutet weniger Versprechen, die man über Jahre halten muss.

Die Grenze zwischen dem, was öffentlich ist, und dem, was intern ist, ist die wichtigste Zeile im gesamten Code einer Bibliothek. Das Innere können Sie jederzeit neu schreiben, solange der öffentliche Vertrag derselbe bleibt. Den öffentlichen Vertrag rühren Sie nicht an, ohne fremde Builds zu brechen. Deshalb ist in kite das nach außen Gerichtete schmal und durchdacht, während die ganze Freiheit im Inneren bleibt.

Diese Aufteilung ist auch das, was eine Bibliothek von einem losen Sack von Funktionen unterscheidet. Wenn die öffentliche Oberfläche klein und stimmig ist, lernt ein Nutzer sie einmal und kann sich auf sie verlassen, statt zu raten, welche von Dutzenden Funktionen die richtige ist.

Testabdeckung ist hier keine Zierde, sondern ein Versprechen an jeden, der kite in sein Projekt einbaut: Diese Pfade funktionieren und werden nach der nächsten Änderung weiter funktionieren. In einer Bibliothek zählt das besonders, denn eine Regression schmerzt nicht Sie, sondern jemanden, der auf Ihrem Code aufgebaut hat und keine Möglichkeit hat, hineinzuschauen.

Die Tests sind zugleich lebendige Dokumentation, wie die Bibliothek benutzt werden soll. Wer nach kite greift, kann die Tests lesen und die öffentliche API in Aktion sehen, statt die Absicht aus Signaturen zu erschließen.