der orangene grad

Es ist kein Drama, wenn das Projekt nicht nach Plan läuft. Es ist ein Drama, wenn der Projektmanager nichts davon weiß.
(Peter Hobbs)

Eintrag 21.03.2018: Der orange Grad

Die Prinzipien

Kapselung von Verantwortlichkeiten (Single Responsibility Principle (SRP)) gibt die Möglichkeit, genau diese Verantwortlichkeit gegenzuprüfen. Dabei ist die Herausforderung, dass die Methoden entsprechend einer Verantwortung gebaut werden. Somit erstellt man zwar viele Methoden, aber reduziert die Zeilen pro Methode enorm und bekommt eine Steigerung der Lesbarkeit und übersichtlichkeit. Ein weiter Nebeneffekt ist die bessere Wart- und Testbarkeit. Umsetzbar ist das Ganze nach dem Prinzip des Teile und Herrsche. Wenn eine Methode Werte aus der Datenbank laden und variablen initialisieren soll, diese dann noch umrechnen muss und anschließend die Ausgabe auch noch übernimmt, wird das schnell unübersichtlich. Als erster Schritt wäre denkbar eine Aufsplittung nach dem EVA-Prinzip durchzuführen. E = Eingabe => aus Datenbank laden und in ein Objekt O packen. V = Verarbeitung => Methode, die das Objekt in den Zustand O' transformiert und zurückgibt. A = Ausgabe => O' entsprechend ausgeben. Der Nächste Schritt ist die Prüfung der Generalisierungsmöglichkeiten für das Auslesen aus der Datenbank. Kann ich hier mittels einer Schnittstelle das Laden der Daten vereinfachen? Ein eigenes Datenbankobjekt, was wiederum funktional gekapselt ist? Kann die Ausgabe über eine einheitliche Schnittstelle laufen, damit die Ausgabe auch schnell variiert werden kann? Besteht die Bearbeitung aus n Schritten, die jeweils getrennt werden können?

Separation of Concerns (SoC) besagt kurz gesagt, dass Themengebiete getrennt werden müssen. Bestimmt ist der Begriff "Spaghetti-Code" schon einmal in irgendwelchem Kontext gefallen. Hier kann ein erster Schritt dagegen gewirkt werden: Struktur reinbringen. Anstatt "Themengebiet" benutzt der Autor von CCD den Begriff "Belange", was ja der übersetzung von "Concerns" am direktesten kommt. Ich wähle hier absichtlich Themengebiete, da das die Unterscheidung zu der in "Single Responsibility Principle" hinterlegte "Eine Verantwortlichkeit" nochmal besser abgrenzt, da es um ein Gebiet geht von Verantwortlichkeiten. Wenn in einem Code z.b. eine Umformatierung definiert wird, EFA -> Parameter Object rein, Aufruf von einer Object2Array-Methode, anschließend Aufruf einer Array2JSON-String-Methode, dann könnte man zwischen diese beiden ein Logging legen, so dass man prüfen kann, was die Array-Methode in einem Bestimmten Objekt ausliest und anschließend in JSON umgewandelt wird. Die Concerns, also Themengebiete die hier zu Trennen sind, wären dann das Logging und die tatsächliche Transformation. Wenn das Logging am Ende gestellt wird, bleibt der Code lesbar und somit weit übersichtlicher.

Konventionen helfen dabei, dass der SourceCode für Alle verständlich bleibt. Es vereinheitlicht z.B. die Benennung von privaten gegenüber öffentlichen Feldern in Klassen oder lokalen sowie globalen Variablen in einer Methode bzw. im ganzen Sourcecode. (Letztere sollten sowieso nie existieren). Ein gutes Schnittstellendesign ist dabei genauso wichtig wie die Prozesse in der Entwicklung. Es es Konvention ist, ein Mal in der Woche über alle Punkte zu sprechen, dann ist hier die Schnittstelle für produktive Kommunikation. Wenn es Konvention ist, möglichst alle Parameter mit p_ anfangen zu lassen, sollte die Konvention beibehalten werden. Konventionen helfen in Teams die Kommunikation untereinander verständlich zu halten. Dabei darf man es nicht schlimm finden, wenn etwas für jemanden erstmal aufwendig aussieht. Mit der Zeit findet sich die Gewohnheit ein, dass man die Konvention auch einhalten kann.

Entweder Berechnungen oder Ablauflogik soll in Methode gekapselt werden. Das besagt das Prinzip Single Level of Abstraction (SLA) Sobald ein Methodenaufruf existiert, ist Ablauflogik das Einzige was da sein darf. Ansonsten muss Rest auch ausgelagert werden. Resultat sind viele kleine aber überschaubare Methoden. Die Strukturierte Reihenfolge der Methoden in einer Klasse sowie eine Konvention der Unterscheidung dieser Methoden ist hier Pflicht.

 

Die Methoden

In der Teamarbeit wird oft über aufgetretene Probleme gesprochen. Es kommen Bugs vor, die bearbeitet und bereinigt werden. Nach der Korrektur ist schon wieder alles besser. Wenn nun 4 Wochen später der gleiche Fehler wieder auftritt, dann passiert das eben mal. Pustekuchen. Ein ordentliches Mitschreiben und eine Basis für die Analyse von Problemfällen (Bugs/Vorkommnisse/Issues, wie man es auch immer nennen mag) ist hier die Lösung für die Zukunft. Wie im Roten Grad bereits das "Ursache"-Beheben (Root-Cause-Analysis) eine wichtige Praxis war, ist nun das notieren und "Taggen" von Problemfällen wichtig. Wenn ein Fehler aufgetreten ist und man nun aufgrund der geringen Wahrscheinlichkeit für erneutes Auftreten einfach ein Workarround beschrieben wurde, wäre es sinnvoll zu sehen, wie oft dieser Workarround tatsächlich bearbeitet werden musste. Das Prinzip hierbei ist einfach: Wer schreibt, der bleibt. Nur dadurch, dass ich mir die Probleme erneut anschaue, kann ich sagen, dass sich der Workarround gelohnt hat. Wenn die Information unter den Usern sich ausweitet, dass eine Software auch "anders als vorgeschlagen" bedient werden kann, dann wird da auch die Möglichkeit sein, die Software "falsch" zu bedienen und man wird die Daten in einem nicht vorhergesehenen Zustand wiederfinden. Je nach Aufbau der Abteilung kann das auch zu enormen Streitigkeiten führen: Aber, um dafür zur Erleuchtung beizutragen noch ein Satz: Auch der interne Prozess und die Abteilungsstruktur sind optimierbar.

In der Industrie ist schon lange der Vorteil von Automatisierung bekannt. Bei der Herstellung von Autos, hat Henry Ford die Fließbandfertigung eingeführt. Damit konnten die Liegezeiten minimiert werden und die Produktion wurde auf ein damals als Maximum bekannte Produktionszeit verkürzt. Mittels Just-In-Time und Just-In-Sequence ist später die ganze Produktionswelt nochmal quasi revolutioniert worden. Industrie 4.0 wird immernoch als Buzzword für die Digitalisierung der Prozesse für die Informationshaltung benutzt. Nun fast vom Thema abgeschweift kommen wir zur nächsten ära: Computerprogramme vom Fließband? Prinzipiell ja, denn letztendlich helfen dem Programmierer heutzutage etliche Frameworks dabei, Lösungen schneller fertig zu stellen und damit auch schneller auf den Markt zu bringen. Da hierbei eine Modularisierung eingesetzt wird, können Unittests helfen, die Code-Basis im Blick zu halten. Wenn es dann zwischen DEV-Umgebung über TEST-Umgebung zur PROD-Umgebung iterativ überprüft wird, wäre es praktisch auch diesen Zyklus automatisiert getestet zu haben. Durch das Erstellen von automatisierten Integrationstest kann sichergestellt werden, dass die Live-Umgebung auch Live bleiben kann, oder zumindest erstmal Schaden vermieden werden kann. Bestimmte Techniken können dabei helfen, den Aufwand für das Test-Erstellen gering zu halten. Eine Technkik ist die Einhaltung des Single Responsibility Principles.

Lesen bildet - so kann es z.B. sein, wenn man sich Fachliteratur widmet. Ein Buch, was ich mir geleistet habe, was ich wärmstens für den "Anfang" empfehlen kann, ist "97 Things Every Programmer Should know". Hier findet der Leser 97 "Kurzgeschichten" für den Entwickler von heute und von morgen. Viele Themen sind umstritten, können aber bei Interesse dann durch die Bücher der ursprünglichen Autoren (Viele sind Buchautoren) Vertiefung finden. Was die Methode "Lesen, lesen, lesen" allerdings auch verinnerlicht ist: Einstellung: PRO Weiterbildung! Falls sich jemand die Frage stellt und sagt: "Wieso sollte ich mich weiterbilden? Ich hab doch meinen "Abschluss" X!" Dann sei ihm die Wandlung der Gesellschaft mal so dahergelegt: Wenn jemand gelernt hat, Großrechner zu bedienen und konfigurieren. Schöne mittlerweile in die Jahre gekommene UNIX-Server von IBM. Dann muss derjenige heute eingestehen, dass es immer weniger solcher Großrechner gibt. Viel mehr läuft über Virtualisierungstechniken und Cloud-basierten Lösungen. Wer hier glaubt, Fortbildung sei nur eine Mode-Erscheinung, dem sei mal die überlegung nahegelegt, was passiert, wenn wir eine KI züchten, die Programmieren kann. Entwickler scheinen momentan nicht aussterben zu können, da implizites Wissen, was wir in der Gesellschaft uns beigebracht bekommen, bei KIs an ihre Grenzen stößt. Was ist aber, wenn jemand auf die Idee kommt, eine KI "großzuziehen"...???!!!

4 Augen sehen mehr als zwei! Das ist ein allseits bekanntes Sprichwort. Es stimmt. Das liegt vor allem auch daran, dass zwei Individuen für sich betrachtet, stets unterschiedliche hintergründe haben, wie sie die Welt an sich sehen. Kommunikation kann z.b. in 4 Ebenen eingeteilt werden:
1. Die Sachebene - "Was wird inhaltlich gesagt?".
2. Die Selbstoffenbarungsebene - "Was habe ich erlebt, was mich zu der Aussage bringt?"
3. Die Beziehungsebene - "Was halte ich von dir und wie stehe ich zu dir?"
4. Die Appellebene - "Wie sollst du meiner Meinung nach handeln?"
Dabei kommen die 4 Ebenen stets in unterschiedlicher Gewichtung zu trage. Bei dem Source Review ist hier stehts sich auf die Sach-Ebene zu konzentrieren, damit der gemeinsame Erfolg im Blick bleibt und man nicht - wie man so schön sagt - "ins Quatschen" kommt. Source Review ist - finanziell betrachtet - auch eine Gewinnsteigerung für die Firma. Wissen gehört heutzutage zum Anlagekapital des Unternehmens. Wird Wissen geteilt (!) multipliziert sich dieses Anlagekapital! Somit ist das Beste was man als Abteilung machen kann - auch bereits in den Daily-Standups sein Wissen in kurzer prägnanter Form zu teilen. Ein weiterer Blickwinkel ist die Verfügbarkeit. Explizites Wissen kann zwar über Dokumentationen "gelesen" und dann angewendet werden, aber meist liegt das notwendige Wissen was genau jetzt in diesem Moment benötigt wird, doch nur "implizit" vor. Daher ist es ungemein wichtig, dass man gegenseitige Reviews durchführt und somit durch Fragen und Erklärung das implizite Wissen in explizites Wissen transformiert - Ok, hier ist dann auch notwendig, dass sich wirklich jemand darum kümmert und die notwendigen Informationen aufschreibt.