Clean Code Development: Die Grade
Clean Code Development ist in verschiedenen Graden unterteilt, die man als Entwickler eine nach der anderen erklimmt und in einem ewigen Kreislauf wiederholt
Softwarelösungen sollen im Normalfall über einen längeren Zeitraum bestehen und mit vertretbarem Aufwand kurzfristig weiterentwickelbar sein. Allerdings bleibt die Zeit nicht stehen. Rahmenbedingungen ändern sich, sei es die IT-Infrastruktur, das Betriebssystem oder die eigentlichen Anforderungen, für die die Software entwickelt wurde oder die technischen Innovationen und Neuerungen. Softwarelösungen müssen auf diese Änderungen reagieren können - und das nachhaltig. Denn je älter eine Software ist, desto komplexer und damit teurer werden Änderungen am Quellcode. Und hierbei handelt es sich um exponentielles Wachstum. Wie aus dem Namen bereits ersichtlich wird, beschreibt Wandelbarkeit die Fähigkeit auf externe Veränderung flexibel und nachhaltig reagieren zu können. Allerdings kann diese Fähigkeit nicht nachträglich in eine Softwarelösung implementiert werden,sondern muss von Anfang in den Entwicklungsprozess Einzug erhalten.
Fazit: Es gibt keine Softwarewartung und keine pro-aktive Wartung! Die Codestruktur muss Änderungen ermöglichen und begünstigen und die Kosten für ein Feature dürfen nicht(exponentiell) steigen!
Software muss funktional korrekt sein, wie auch zum Beispiel eine Tabellenkalkulation richtig rechnen muss. Und auch die nicht-funktionalen Anforderungen müssen erfüllt sein. Das Programm muss schonend mit Ressourcen wie Speicher, Prozessorzeit,Plattenplatz etc. umgehen und die Antwortzeiten müssen in einem definierten Rahmen liegen. Erst wenn alle Anforderungen erfüllt sind, ist die erstellte Software korrekt. Die Frage ist, was konkret für die Korrektheit getan wird. Es reicht unserer Ansicht nach nicht aus, Software nach deren Erstellung durcheine Testabteilung zu leiten, deren Aufgabe es ist, Fehler zu finden. Wir meinen, Korrektheit muss bereits während der Entwicklung berücksichtigt werden.Alle Entwickler müssen sich mit der Frage der Korrektheit auseinandersetzen und damit sie das überhaupt können, muss ihnen klar sein, was die Anforderungen sind. Entwickler werden beauftragt ein Feature zu implementieren, ohne dass ihnen präzise gesagt wird, was die Abnahmekriterien für das Feature sind. Hier ist es die Aufgabe des Entwicklers, bei unklaren Anforderungen nachzufragen und diese fest zu definieren. Denn erst wenn alle Anforderungen erfüllt sind, ist die entwickelte Software korrekt.
Fazit: Eigentlich klar, aber die Korrektheit muss während der Entwicklung berücksichtigt werden und dafür müssen die Anforderungen klar definiert sein.
Am Ende spielen auch die Entwicklungszeit und der Preis der Software eine Rolle. Und der ist höher,wenn die Produktion der Software nicht effizient erfolgt. Das beginnt bei manuellen Arbeitsschritten, die nicht automatisiert werden und endet bei hohen Fehlerraten, die mehrmaliges Nachbessern erfordern. In letzter Konsequenz bedeutet Produktionseffizienz, dass die Software über Jahre oder gar Jahrzehnte weiterentwickelt werden kann, statt irgendwann wieder von vorne beginnen zu müssen. Gleichzeitig reduziert eine hohe Produktionseffizienz die Anfälligkeit für Fehler. Die Produktionseffizienz als Wert ist ferner wichtig, um die anderen Werte in ein maßvolles Verhältnis zu setzen. Wer unendlich viel Aufwand für die Korrektheit betreibt, macht am Ende auch etwas falsch.
Fazit: Maximale Automatisierung anstreben!
Ohne Reflexion ist keine Weiterentwicklung möglich. Nur wer reflektiert, wie er eine Aufgabenstellung gelöst hat, kann feststellen, ob der gewählte Weg einfach oder beschwerlich war. Lernen basiert auf Reflexion. In einer jungen Wissenschaft wie der Informatik ist es wichtig, stets neue Erkenntnisse zu berücksichtigen.Dazu ist Reflexion auf allen Ebenen erforderlich. Angefangen beim Reflektieren über die Implementation beim Pair Programming oder Code Review, das tägliche Reflektieren des Teams, die Reflexion nach jeder Iteration, bis hin zur Reflexion der gesamten Branche über ihr Tun. Ohne Reflexion keine Weiterentwicklung.
Fazit: Clean Code Developer lernen basiert auf der Reflexion, die sich über alle Ebenen erstreckt sowie beim Pair Programming und Code Review.
Prinzipien sind grundlegende Gesetzmäßigkeiten für die Strukturierung von Software. Code sollte immer im Einklang mit einer maximalen Zahl von Prinzipien sein. Wo ein Prinzip nicht eingehalten wird, tritt also nicht unbedingt sofort ein negativer Effekt ein, aber kurz- bis mittelfristig bleiben Zuwiderhandlungen nicht ohne Schmerz. Ob ein Prinzip eingehalten wurde, kann man dem Code immer ansehen.
Praktiken sind Techniken und Methoden, die ständig zum Einsatz kommen.Sie beschreiben, was Clean Code Developer praktisch umsetzen. Motto der Praktiken: „Tue es immer so. Jeden Tag, jederzeit.“ Es sind handfeste Handlungsanweisungen, die manchmal des Einsatzes von Werkzeugen bedürfen. Ob einer Praktik gefolgt wird, kann man dem Code nicht immer ansehen.
Clean Code Development ist in verschiedenen Graden unterteilt, die man als Entwickler eine nach der anderen erklimmt und in einem ewigen Kreislauf wiederholt
Um Clean Code Developer zu werden, gilt es eine Reihe von Tugenden zu verinnerlichen: Schätze Variation, Tue nur das Nötigste, Isoliere Aspekte etc.