Letzte Woche fiel mir ein sehr interessanter Beitrag (How I Develop Things and Why) zum Thema Entwicklungsstil in die Hände. Der Autor, Kenneth Reitz, vertrat dabei die Meinung, dass man alles sinnvoll designen sollte. Das mag jetzt zwar logisch klingen, ist es aber nicht. Wenn Entwickler von Design sprechen, dann ist meist das Design für den Endkunden gemeint. Die gleichen Regeln sollten aber auch für alle anderen gelten. Sprich, auch ein API oder eine Library sollte intuitiv und nutzerfreundlich sein.
Keneth, selbst ein bekennender Python Fan, geht darauf am Beispiel der http Library für eben diese Sprache ein. Sie tut zwar was sie soll, nervt den Entwickler aber mit unzähligen kryptischen Parametern und viel Schreibaufwand für einfachste Aufgaben. Um diesen Umstand zu verbessern, hat er eine Library geschrieben, die als Schnittstelle zwischen dem Entwickler und der ursprünglichen Library sitzt – spirch, ein Wrapper.
Und somit kommen wir zum Kern dieses Beitrages: Als Designphilosophie für diesen Wrapper wählte er das “Readme driven design”. Häh? So in etwa habe ich auch geschaut, als ich es zum ersten mal las. Das Prinzip ist aber recht sinnvoll: in der normalen Entwicklung fängt man mit einer simplen Idee an, baut das entsprechende API und alles ist toll. Nachdem die Grundfunktionen stehen, erweitert man das ganze, passt das API ein bisschen an, refactored ein bisschen, wieder wird das API angepasst usw. Irgendwann hat man zwar eine Library (bzw. ein Tool), die alles mögliche kann, was aber wiederum mit dem ursprünglichen API-Design nicht mehr realisierbar gewesen wäre. Heraus kommt dann ein Konstrukt aus undurchsichtigen Parametern und umständlichen Vorgehensweisen, um das gewünschte Ergebnis zu erhalten.
Die bessere Alternative ist nun folgende: man schreibt zuallererst die Readme Datei inkl. ausführlicher Syntax und Beispielen – genau so, als ob das Stückchen Software bereits existieren würde und fertig wäre. Und erst dann beginnt man mit der Umsetzung. Der Vorteil ist nun, dass man das API so designt hat, wie man gern damit arbeiten würde – unabhängig von auftretenden Hürden und Problemen. In der Regel sollte ein großer Teil der Entwickler in dieser Hinsicht ein gleiches Verständnis von “leicht” haben. Hinzu kommt: man “überdesignt” nicht – denn der Funktionsumfang ist ja nun genau definiert.
Wie man bereits feststellen kann, eignet sich diese Methode natürlich nicht für große Projekte – dafür macht sie für kleine Scripte oder Libraries umso mehr Sinn.
Was haltet ihr davon? Sinnvoll, oder Quatsch? Oder konntet ihr bereits Erfahrung damit sammeln?
Softwareentwickler, Technik Fanatiker, Apple Fan, Kinoliebhaber, Prokrastinations-Spezialist
