Nachdem man die Grundlagen gelernt und ein kleines Projekt gebaut hat, bekommt man womöglich die Idee, dass man es das nächste Mal besser machen möchte. Irgendwas war doof geplant, kompliziert umzubauen etc. Das ist verständlich. Stellt sich die Frage, wie macht man das? Wie baue ich das nächste Mal DAS perfekte System wo alles super ist?
Ehrlich gesagt ist das eine Utopie. Ja, man kann daraus lernen und ein paar Konzepte ändern. Aber im Großen und Ganzen klappt das nicht, einfach weil sich ständig alles ändert. Etwas was ich auch erst begreifen musste: Software ist da um geändert zu werden, ansonsten könnte ich es in Hardware gießen.
Es geht nicht darum etwas einmalig korrekt zu bauen, es geht um Anpassungen. Deshalb werde ich hier einfach mal wild zusammengewürfelt Dinge auflisten die dort Orientierung geben. Sollte jemand andere Erfahrungen gemacht haben, es gibt eine Kommentarfunktion. 😉
Ich werde ein paar Links zu Büchern einstreuen. Nix Affiliate oder gesponsert, im Internet sind Links schlichtweg einfacher als ISBN.
Benamung
Ein definitiv guter Ansatz ist eine vernünftige Benamung von allem. Dazu findet sich häufig Clean Code von Uncle Bob als Referenz. Ich muss aber ehrlich gestehen, so viel Neues hab ich in dem Buch nicht gefunden. Entweder man kannte es schon weil man irgendwo mal gehört hat das z.B. ungarische Notation böse ist, oder die bisherigen Lehrbücher für die Sprachgrundlagen haben es eingebürgert. Tatsächlich sinnvoller fand ich dazu die diversen Vorträge von Kevlin Henney. Er hat immer schöne Beispiele und Vergleiche an denen man gut versteht wieso und wie man etwas strukturieren kann.
Bei der Benamung geht es primär um „wir meinen das gleiche“ und „es ist verständlich was das macht“. Wenn alle Beteiligten etwas ein Model, Wrapper oder View nennen, dann wissen auch alle was gemeint ist und was es macht. Das hängt mit den Design Patterns zusammen oder mit anderen Prinzipien. Wie man in Kevlins Videos erklärt bekommt sind die Suffixe zwar unnütz und verlängern die Wörter, aber für den Programmierer ist es durchaus sinnvoll.
Kommentare
Kommentare sollen den Code verständlich machen. Ist ein Ansatz, aber auch dazu hat Kevlin sehr schön Beispiele die zeigen, dass das häufig der falsche Ansatz ist. Mit guter Benamung und übersichtlichen Methoden braucht es keine Kommentare.
Kommentare sind nur sinnvoll wenn sie etwas erklären, was der Code nicht selbst kann. Zum Beispiel wieso etwas genau so gebaut wurde. Eine Information, die einem anderen Programmierer sagt wieso etwas richtig ist obwohl es falsch oder unnötig aussieht.
// Das Excel Fenster muss mit dem Handler Hwnd verglichen werden, sonst klappt es nicht.
if (_taskPaneHandlerModel.Window is MsoExcel.Window excelWindow)
{
...
}Test Driven Design
Mit TDD soll die Codequalität verbessert werden. Kent Beck hat dieses Prinzip entwickelt und in die Welt getragen. Meine Hoffnung nach dem Durcharbeiten dieser Lektüre war, dass Konzept verstanden zu haben und es aktiv einzusetzen. Das bietet das Buch aber meines Erachtens nicht. Es erklärt zwar die Konzepte, aber ich habe nix gefunden was mir praktisch erklärt wie man an die Thematik rangeht.
Ich habe noch keine Videos dazu gesucht, aber ich vermute auf YT gibt´s praktischere Anleitungen wie man damit arbeitet. Das Konzept ist wichtig und man sollte das beherzigen. Aber das Buch ist dafür unnötig.
Design Patterns
Auch dazu gibt es diverse Bücher, die Urväter sind die Gang of Four. Design Patterns sind schlichtweg typische Lösungen für wiederkehrende Probleme. Also wie baue ich ein paar Klassen so auf, dass sie sinnvoll strukturiert sind. Das Problem was ich persönlich damit habe, ich weiß ja vorher nicht zwingend, welches Pattern es sein könnte. Deshalb ist es viel sinnvoller zu verstehen, wie das Umbauen von bestehendem Code zu einem Pattern funktioniert. Dazu gleich mehr bei Refactoring.
Refactoring
Als Refactoring wird schlichtweg „Umbauen“ bezeichnet. Und das ist das fundamentale Handwerkzeug für die am Anfang getroffene Aussage, dass Software nur deshalb Software ist, weil sie veränderbar sein muss. Und es gilt das gleiche Prinzip wie bei den Design Patterns. Irgendwas ist da und muss angepasst werden. Und dahingehend ist das Buch von Martin Fowler tatsächlich sinnvoll, denn es erklärt wie das funktioniert.
Das Wichtigste was dieses Buch oder seine Vorträge vermitteln ist aber: es gibt immer mehrere Möglichkeiten wie man den Code und die resultierenden Funktionen/Strukturen aufbauen kann. Wenn sich die Anforderungen ändern oder etwas anders aufgebaut sinnvoller ist, dann baut man es schrittweise um.
Beispiel aus meinem Umfeld: Im Outlook AddIn und damit mit Bindung an die Outlook-Objekte gab es einen Dialog der die gewählte E-Mail (MailItem) eingelesen hat. Der Nutzer konnte Informationen anhängen und das ganze wurde in das Dateisystem in eine Projektstruktur exportiert. Nun kam der Wunsch auf, dass auch andere Elemente wie eine Terminanfrage oder eine Notiz exportierbar sein sollen. Ich hatte aber direkt gegen die Klasse programmiert und das ging nicht ohne weiteres. Ansatz Kent Beck: Um eine einfache Änderung zu machen, muss man die Änderung erst einfach machen.
- Die Mailtem-Klasse bekommt ein Interface (zB IMessageItem)
- Änderung des Exports, benutze das Interface IMessageItem anstatt die konkrete Klasse MailItem. Testen!!!
- Neue Klasse für PostItem mit dem existierenden Interface IMessageItem erstellen, alle Methoden angepasst einbauen.
- Im Dialog ein Casting des eingelesenen Objekts machen um zu checken ob es ein Mailitem oder PostItem ist. Testen!!!
Direkt von Beginn an ein Interface zu nutzen war nicht sinnvoll, unnötige Komplexität. Erst als die Anforderung kam war ein Umbau sinnvoll. Und das gilt auch für viele andere Dinge, zB ob Hilfsklassen im Hauptprojekt oder in einer separaten dll (Projekt) liegen oder eine Klasse umbenannt werden sollte. Ein Umbau ist nahezu immer möglich, es geht nur darum zu lernen wie das Umbauen geht und es nicht laut Bummm macht. Moderne Entwicklungsumgebungen unterstützen dort sehr gut.
Zum Schluss
In Zeiten des Internets finde ich Videos deutlich sinnvoller. Die Vorträge von Kevlin Henney sind zwar partiell etwas hoch angehängt, aber sie geben eine gute Übersicht und man sieht extrem viele Dinge die andere Leute gemacht haben, warum sie doof sind und wie man es für sich besser machen kann. Sein Buch fand ich weniger nützlich, das meiste kam schon in den Vorträgen oder in Vorträgen anderer.
Martin Fowler und Kent Beck erklären in ihren Videos öfter, dass es nicht gleich die perfekte Lösung sein muss. Man hat eine Idee, programmiert diese und erst wenn es funktioniert kann man sich Gedanken machen wie man das so umbaut, dass es hübsch ist und gut wartbar. Direkt in hübsch bauen klappt selten bis nie, man muss akzeptieren, dass das zwei Prozessschritte sind.
Später kann man sich gern noch mit Themen wie Lean Software Development oder Agile auseinandersetzen. Diese Themen greifen die Arbeitsgestaltung auf. Nämlich „Ich hacke Aufgaben klein und kann die damit flott fertig machen ohne mich zu verheddern oder groß abgelenkt zu werden.“ Damit wird das Drumherum gestaltet, nicht direkt der Code.
