Die letzte Version ist eine Version 2.x. Von eventuellen dringend notwendigen Bugfix-Releases abgesehen – wollen wir hoffen, dass das nicht nötig sein wird – wird es keine weitere Version 2 mehr geben.

Ein Versionswechsel in der sogenannten Majorversion erfolgt in der Regel nur dann, wenn es eine sehr grundlegende Änderung des Softwareproduktes gibt. Beim Versionssprung von 1 auf 2 wurden beispielsweise mit den Dateifunktionen in ihrer Art völlig neuartige Funktionen hinzugefügt, was unter anderem die zusätzliche Berechtigung des Dateisystemzugriffs auf euren Geräten erforderlich machte.

Nun ist der GC Wizard in seinen inzwischen mehr als drei Jahren mehr oder weniger ununterbrochener Entwicklung deutlich größer und komplexer geworden, als es zu Beginn auch nur zu erträumen gewesen wäre. Die stetig wachsende Komplexität führte in der Zeit aber auch zu vielen Problemen bei der internen Entwicklungen. So ist es nun an der Zeit, die zugrunde liegende Codebasis herzunehmen und kritisch zu hinterfragen. Kann die damals gewählte Struktur, damals gewählte Ansätze dem heutigen Projekt noch gerecht werden? Und kann sie weiteres potententielles Wachstum nach wie vor unterstützen?

Softwarearchitektur

Entscheidungen über den Aufbau von Code und die Prinzipien, nach denen man programmiert kann man – grob gesagt – als Softwarearchitektur beschreiben. Die Entscheidungen, die zu der aktuellen Architektur führten, basierten auf Annahmen von deutlich weniger unterstützten Tools und auch der pessimistischen Ansicht, dass außer mir wohl nie wirklich dauerhaft jemand an dem Projekt arbeiten würde, so sehr ich es auch von Anfang an wünschte. Nun wurde ich, Thomas und Mike sei Dank, eines Besseren belehrt und musste auf der anderen Seite aber auch sehen, dass die damaligen Entscheidungen heutigen Anforderungen nicht mehr genügen.

Wir haben viele Stellen, wo die Codebasis nicht mehr den Ansprüchen von sauberem Code genügt. Der gravierendste Teil ist die aktuell vorliegende technische Schneidung. Das bedeutet, dass ich mich urspünglich entschieden hatte, Berechnungslogik und Ausgabe, also die Darstellung in der App, strikt und vollständig voneinander zu trennen, wie es klassische Ansätze in der Theorie der Softwarearchitektur vorsehen. Das führt dazu, dass man für ein konkretes Tool in einen Ordner den Code für die Logik schreibt und in einen Ordner in einem völlig anderen Verzeichnis den Code für die Darstellung. Dies funktioniert gut, solange man in kleinen Maßstäben denkt.

Doch mittlerweile haben wir neben der Programmlogik und der Ausgabe auch noch Übersetzungsdateien, Dateien für die Suche, die Registrierung für das Hauptmenü und mehr. So verstreut sich ein neues Tool, so klein und einfach es auch sein mag, sofort quer über das ganze Projekt, was mittlerweile weit mehr als eintausend Ordner umfasst. Es ist also zunehmend schwer, den Überblick zu behalten, welcher Teil an welchem Ort zu einem Tool gehört.

Die Lösung ist eine sogenannte fachliche Schneidung. Hier hat nicht die technische Sicht „Berechnungslogik vs. Ausgabe“ Vorrang, sondern es wird versucht, alle Teile eines spezifischen Tools, einer in sich geschlossenen Fachlichkeit, zusammen zu halten. Danach kann man darüber nachdenken, wie man die technische Schneidung vornimmt – nur eben in kleinerem Stil, ausschließlich auf Tool-Ebene und nicht projektweit gesehen. Das erleichtert den Überblick für uns und vereinfacht auch den Einstieg für potentielle kommenende Mitentwickler.

Die Schritte

Als erstes müssen natürlich sehr sehr viele Dateien und Ordner umsortiert werden. Hier können wir ein wenig auf die Unterstützung von unserer Entwicklungsumgebung bauen, aber es bleibt bei einem solch komplexen Konstrukt noch viel manuelle Arbeit zu tun.

Danach sollte in dem Zuge auch geprüft werden, ob bestimmte Dateien zusammengeführt werden können oder getrennt werden sollten. Passen sie noch in den Kontext, in den man sie früher eingeführt hat? Dies führt im schlimmsten Fall zu einer manuellen Durchsicht und Prüfung aller Dateien.

Wir haben zwei Dateien, die mehrere tausend Zeilen lang sind – viel zu lang um sie als Mensch noch zu beherrschen -, weil wir dort alle unsere Tools registrieren, z.B. für das Hauptmenü. Ziel ist es, eine Möglichkeit zu schaffen, wo auch hier einerseits die Komplexität dieser Dateien reduziert wird, aber andererseits eben auch die hier ebenfalls vorliegende Streuung der Tools weiter aufzulösen (die Datei für das Hauptmenü ist natürlich nicht irgendwo an einem bestimmten Tool zu finden, sondern bildet eine weitere Streuung). Diese Möglichkeit nennt sich Reflection, die im Bereich anderer Programmiersprachen, wie Java, üblich ist, aber bei unserem Dart-basierten System nicht ganz einfach zu realisieren ist. Es wird technisch gehen, aber unter Umständen könnte dies signifikante Geschwindigkeitseinbußen beim Start der App geben. Dies können wir allerdings nur ausprobieren. Und im Fall der Fälle muss nach einem Kompromiss gesucht werden.

Fazit

Aktuell findet der größte interne Umbau statt, den das Projekt bis jetzt erlebt hat. Viele Dinge sind zu beachten und am Ende sollte für den Nutzer alles beim Alten geblieben sein. Zwar hat der Nutzer bis hierhin keinerlei Nutzen einer Änderung der Versionsnummer, aber für uns als Programmierer stellt diese Sisyphos-Arbeit einen ernormen Schritt dar, um das Projekt zukunftssicherer zu gestalten.

Aber natürlich wird auch aus Nutzersicht nach dem Umbau einiges passieren und tolle Sachen werfen ihren Schatten voraus. Dazu später mehr 🙂