der rote grad

Der Anfang ist der wichtigste Teil der Arbeit.
(Platon)

Eintrag 08.01.2017: Der rote Grad

Die Prinzipien

Einige der Prinzipien waren mir bereits geläufig und diese setzte ich bereits ein: DRY und KISS sind einfach umzusetzen, indem man nach dem erledigen einer Aufgabe kurz überlegt: Ist da noch was machbar? "Vorsicht vor Optimierungen" kann man auch mit dem allgemeinen Prinzip "Wer im Glashaus sitzt, sollte nicht mit Steinen schmeißen" ausdrücken. Es geht hier darum zu hinterfragen, ob eine Änderung denn überhaupt sein muss. Wenn z.B. die Effizienz gerade um eine Sekunde in einem Prozess verbessert wurde, der vorher eine Minute lief, dann ist womöglich die Änderung am Ende eher eine ABM für die anderen Entwickler, die sich hier erstmal wieder reinfuchsen dürfen.

Beinahe neu war für mich das Prinzip Kapselung vor Vererbung (Favour Composition over Inheritance(FCol)) zu befolgen. Es ist generell bei Vererbung die Sache, wenn man es zu viel in die Tiefe betreibt, hat man später eine sehr große Hierarchie zu überblicken, was zuvor.

Neu war für mich das bewusste Beachten von der Trennung von Logik und Integration (also Aufruf von Methoden, die reine Logik enthalten). Hierbei ist die Lesbarkeit und die Testbarkeit ein positiver Zweck hinter diesem Prinzip. Wenn man nur z.B. eine mathematische Formel implementiert, die allerdings selbst nichts weiter aufruft, kann diese mittels UnitTest konkret getestet werden. Zudem können Methoden, die wiederum die Logik-Implementierungen aufrufen, besser überblickt und gewartet werden.

 

Die Methoden

SVN als Versionskontrollsystem einzusetzen, ist bei mir schon in Fleisch und Blut übergegangen. Dies gibt nicht nur eine Möglichkeit nachzuvollziehen, wie, wann und von wem Änderungen eingefügt wurden, sondern viel mehr auch die Möglichkeit, auf einen alten Source-Stand wieder zurückgehen zu können. Das heißt, es gibt dem Entwickler eine gewisse Sicherheit, wodurch Mut Änderungen durchzuführen gesteigert werden kann.

Wiederum unbewusst habe ich schon immer gerne die Rolle von Sherlock Holmes gespielt. "Root Cause Analysis" - herauszufinden, was die Wurzel des Problemes ist, war mir schon immer von besonderem Belang. Oft bekommt man die Quelle bereits präsentiert, wenn man sich traut einige Fragen zu stellen - selbst wenn diese etwas unangenehm sind. Wenn die Datenstruktur, das Datenmodell, die Programm-Routinen von sich aus ausgeschlossen werden können, dann ist vielmehr noch die Frage offen, wie der Anwender den Prozess durchführt. Zwischen UI und UX macht der Anwender den Unterschied. (UI = User Interface => vom Entwickler entworfen, UX = User eXperience => wie der Anwender das Programm sonst noch gebrauchen kann und der Entwickler nicht eindeutig genug entwickelt hat) Hier aber enorm vorsicht. Es ist Unklug gleich "den" oder "die" Schuldige zu suchen. Irren ist bekanntlich menschlich und sich ärgern bringt bekanntlich Bluthochdruck und ganz ehrlich - das hilft weder einem selbst, noch dem Anwender. Immerhin kann man dem Anwender die Information zu dem Problemfall danken!

Die Pfadfinderregel war mir vor dem Clean Code Developer recht neu. Klar, wenn ich etwas im Source sehe, wie einen veralteten Kommentar, habe ich diesen auch schon einfach mal gelöscht. Aber im Weiteren ist hier die Regel gemeint: "Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast.". Es besagt, dass die Werte und Prinzipien des CCD immer befolgt und immer in den notwendigen Schritten verbessert werden sollen.

Refaktorisierung ist eine sehr wichtige Methode, da hier alles bislang besagte Zusammenkommt. Mit SVN kommt der Entwickler zum Mut, Ideen umzusetzen. Die Pfadfinderregel gibt die Idee der kontinuierlichen Verbesserung wieder. Durch DRY und die Trennung von Logik und Integration können weitere Verbesserungen in der Lesbarkeit und Wartbarkeit von Code erlangt werden. Der Einsatz von Refaktorisierungsmustern gibt dem Entwickler die Möglichkeit strukturiert an die Optimierung heranzugehen. Ein StyleGuide oder CodingGuide kann hier durchaus helfen. In Delphi z.B. werden Parameter einer Methode immer mit einem Großen A begonnen. Felder, also Attribute der Klasse, werden normalerweise mit herangehendem F definiert. So ist schonmal klar, was passiert, wenn man folgendes liest: FKundennummer := AKundennummer;

Zuguterletzt gehe ich auf die Methode des täglichen reflektierens ein. Hier soll man sich überlegen, wo man die Prinzipien und Methoden anwenden konnte und wo man noch Potential hat und dies ggf. am nächsten Tag machen kann. Das Armband soll hierbei auch bei der permanenten Reflektion helfen. Ich kenne dieses System als PDCA-Kreis (oder auch Deming-Kreis): Plan-Do-Check-Act. Plane dein Vorhaben, Mache es, Prüfe das Gemachte, Handle entsprechend des Prüfungsresultates.

 

Nachtrag 15.01.2017 - Was ich mir für die Revision merken möchte