Entwickler-Bullshit-Bingo! Ja, schon irgendwie. Prototyping hab ich offen gestanden auch nicht bewusst angewendet. Zwar hab ich in irgend einem Entwicklerpodcast mal davon gehört und hinter dem Begriff verbirgt sich letztendlich auch genau das, was er vermuten lässt: Einen Prototypen der geplanten Software, Teilprogrammes oder was auch immer bauen. Da mein Adressbuch in der Einleitung als Desktopanwendung mit grafischer Benutzeroberfläche von mir angepriesen wurde, habe ich, quasi ohne es zu wissen, einen Prototypen erstellt: Ich habe eine Konsolenanwendung erstellt. Das habe ich getan, um zu schauen, mit welchen Mitteln ich überhaupt meine Vorstellungen implementieren kann. Technisch musste ich mich schließlich von einem Ast zum Nächsten hangeln. Hier eine Methode einer Klasse aus dem .NET Framework, dort lernen, was die Syntax
class TimePeriod
{
private double _seconds;
public double Seconds
{
get { return _seconds; }
set { _seconds = value; }
}
}zu bedeuten hat (Auflösung und Quelle: Microsoft | set (C# Referenz)). Wäre ich nach Lehrbuch vorgegangen, hätte ich das möglicherweise auch ohne zu googeln erschließen können. Da ich in meinem Projekt voran kommen wollte, habe ich einfach immer mit dem existierenden Wissen begonnen und mir für meine Hindernisse Lösungen ergoogelt. Hinreichende Kenntnisse über die Funktionen einer Hochsprache habe ich noch aus der Zeit der Umschulung von Java.
Und so habe ich mir einen Prototypen gebaut, der die ersten gewünschten Funktionen in einer Konsolenanwendung abdecken konnten, mir technisch weitere Einblicke in C# und .NET bot, sowie neue Wege aufzeigte und mich bereits realisierte Funktionen infrage stellen ließ. Seit dieser Erkenntnis arbeite ich vorwiegend mit der Konsolenanwendung weiter, um die verschiedenen Funktionen abzubilden und deren Brauchbarkeit zu prüfen. Natürlich ist das ein gewisser Aufwand, weil ich in der Konsole keine Bindungen an Felder in einer grafischen Oberfläche habe. Bedeutet: Für jedes Feld, welches eine Benutzereingabe fordern kann, muss ich mir den/die Feldnamen ausgeben lassen, um an der richtigen Stelle die passende Eingaben machen zu können. So lernt man nebenbei den Inhalt von Arrays, Listen und Enums auszugeben. Als ich beispielsweise ein dynamisch erweiterbares Array einsetzen wollte, stieß ich auf stackoverflow auf einige Aussagen, die den Fragestellenden ans Herz legten, sich stattdessen doch lieber mit Collections zu beschäftigen. So kam ich für mich zu dem Schluss, in einem Anwendungsfall auf ein Dictionary<TKey,TValue> zurückzugreifen. Ich beschäftigte mich daher vornehmlich mit den Möglichkeiten dieses Listentyps und lernte essentielle Dinge darüber. Für dynamisch in der Anzahl um x wachsende Sammlungen sind die starren Arrays tatsächlich reichlich ungeeignet. Dabei konnte ich mich noch an die Umschulung erinnern, in welcher unser Dozent für Java auf die Arrays sehr ausführlich einging. Als ich mich für mein Projekt mit dem Thema beschäftigte, waberten zwar auch Erinnerungen an Listen in Java durch meinen Kopf. Nur schienen mir die damals wohl nicht besonders interessant oder unser Dozent legte keinen großen Fokus darauf. Ich glaube, ihm ging es bei Arrays in der Hauptsache auch darum, wie man Objekte iterieren kann. Das – und grob auch wie – das möglich ist, hat mir natürlich geholfen, als ich mit dem Dictionary zu arbeiten begann. Ich wusste immerhin, wonach ich suchen musste, um eine gute Lösung zu finden und nicht irgend eine, die einfach nur funktioniert.
Und so programmiere ich mich voran, primär das Ziel, die Anwendung funktional zu bekommen, sekundär das Ziel, nicht totalen Mist zu bauen. Da ich mich kenne, würde ich eine einfach nur funktionierende Anwendung nachher nicht mehr grundlegend umbauen. Dann lieber gleich (nach meinem jeweiligen Kenntnisstand) richtig machen. Dabei versuche ich immer vorauszudenken, ohne zu viel Code zu produzieren, den ich möglicherweise später gar nicht brauche. Stichwort: Generischer Code.
i can compute 