-
Problem: Write Once, Touch Never
Autor: /mecki78 11.02.21 - 23:18
Das Szenario kenne ich nur zu gut. Wir schleppen in einem Projekt auch so einen riesigen Batzen Legacy Code mit. Vor einigen Jahren habe ich den damaligen Product Owner überzeugen können, dass wir diese Code neu schreiben sollten. Alleine schon deswegen, da 50% des Codes überhaupt nicht mehr in Verwendung ist, aber dummerweise sind das nicht einzelne Funktionen, die man einfach entsorgen könnte, sondern es sind Code Pfade innerhalb von Funktionen, die aber unter Garantie nie betreten werden, weil sie für Features gedacht waren, die nie vollendete wurden und aktuell gar nicht angeboten werden von der App und das auch nie der Fall sein wird; selbst wenn, wurden diese Code Pfade 10 Jahre lang nicht genutzt, wer weiß ob die noch funktionieren, da sich ja drum herum doch was verändert hat und die Pfade auch nie getestet wurden seit 10 Jahren. Ich war ca. 80% damit fertig, da hat das Management das Projekt gestoppt, weil es zu lange dauert und zu teuer ist... bei 80%(!!!), als gerade die ersten vollwertigen Integrationstests anstanden! Der verantwortliche Manager arbeitet heute nicht mehr für uns fährt Projekte in anderen Unternehmen gegen die Wand.
Aber die wahren Kosten sieht keiner. Weil das ganze Teil nur noch durch Klebeband und Spucke zusammen gehalten wird, ist jede Änderungen wie einen Block bei Jenga raus ziehen. Wenn es schief geht, bricht der ganze Turm in sich zusammen. Deswegen steigen die Kosten auch beinahe schon exponentiell mit jeder Änderung. Features, die in Stunden machbar sein sollten kosten Tage, weil man einen Workaround für einen Workaround für ein Problem aufgrund einer Anpassung einer Änderung die durch einen Workaround nötig wurde basteln musst, damit sich das System minimal anders verhält, ohne dass genau das hier passiert:
Ein Rewrite wäre im Verhältnis viel billiger gewesen, da die Kosten hinterher schon nach kurzer Zeit wieder drinnen gewesen wären.
Der Satz "never touch a running system" wird grundsätzlich falsch verstanden. Der Satz bedeutet: Mach keine Änderung, die unnötig ist. Aber Code zu pflegen ist eine nötige Änderung. Es ist nötig, dass man hin und wieder mal Code verbessert, der z.B. verwirrend ist, der KISS, DRY oder Encapsulation verletzt oder bei dem es sich klar um ein Anti-Pattern handelt. Es ist nötig alte, oft deprecated APIs durch neuere, bessere zu ersetzen. Und niemand kann im ersten Anlauf perfekten Code schreiben, auch wenn er von außen betrachtet fehlerfrei arbeitet. Der Endanwender muss sich schließlich nicht mit dem Code herumschlagen, wenn es einen Bug gibt oder ein Feature verlangt wird. Es ist keine Schande, wenn Code nicht auf Anhieb perfekt ist, aber Iteration für Iteration wird er sich dem immer weiter annähern, nur dazu muss man ihn anfassen dürfen und nicht write once, touch never Code produzieren.
Und ja, Unit Tests können nie alles erfassen, daher muss man dieses ständig erweitern. Baut man was um oder ein und dann bricht etwas, aber kein Test hat das gemeldet, dann muss man das als Chance sehen und genau jetzt den Test schreiben, der dieses Problem erkannt hätte. Damit ist gesichert, in dieses Problem wird man bei künftigen Änderungen garantiert nicht noch einmal laufen. Und so werden auch die Tests besser und besser und es wird immer schwere überhaupt noch irgend einen Fehler zu produzieren, bei dem nicht sofort irgend ein Test anschlägt.
Hier, zieht euch das mal rein:
https://youtu.be/7EmboKQH8lM?t=1475 (bis 32:10, sind nur nur ca. 8 Minuten)
Genau so sieht es in der Realität aus, leider.
Und dann bitte auch noch das hier:
https://youtu.be/Qjywrq2gM8o?t=1558 (bis 31:50, sind nur 6 Minuten)
Genau so und nicht anders sollte das laufen, aber das haben Manager und Product Owner bis heute nicht verstanden und daher gehen diese System eines Tages vor die Hunde.
Die Gesamte Vortragsreihe (6 Teile) ist wirklich sehenswert und auch recht unterhaltsame vorgetragen. Allerdings dauert jeder Teil mindestens 1 Stunden, manch fast 2. Aber wer sich gerade im Lockdown langweilt, hier kann man Zeit sinnvoll investieren.
/Mecki -
Re: Problem: Write Once, Touch Never
Autor: der_onkel 12.02.21 - 17:07
Vielen Dank für die Videos!