Ullrich: /* Motivation */

2024-11-29T18:50:05Z

Motivation

← Nächstältere Version		Version vom 29. November 2024, 18:50 Uhr
Zeile 11:		Zeile 11:
	Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.		Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.
	Aber was hat das nun mit Software Engineering zu tun?		Aber was hat das nun mit Software Engineering zu tun?
	Zum Äquivalent des Broken Windows Effect im Software Engineering ist hier recht nett beschrieben		Zum Äquivalent des Broken Windows Effect im Software Engineering ist [https://blog.codinghorror.com/the-broken-window-theory/ hier] recht nett beschrieben.
	~~(da ist wohl ein Link verloren gegangen)~~.
	Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.		Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.

Ullrich am 28. November 2024 um 10:24 Uhr

2024-11-28T10:24:18Z

← Nächstältere Version		Version vom 28. November 2024, 10:24 Uhr
Zeile 3:		Zeile 3:
	= Motivation =		= Motivation =
	Zu den Regeln der Pfadfinderbewegung gehört der Satz:		Zu den Regeln der Pfadfinderbewegung gehört der Satz:
	{quotation\|Always leave the camp ground cleaner than you found it.}		{{quotation\|Always leave the camp ground cleaner than you found it.}}
	oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:		oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
	{quotation\|Try and leave this world a little better than you found it.}		{{quotation\|Try and leave this world a little better than you found it.}}
	In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):		In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
	Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren		Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Zeile 85:		Zeile 85:

	Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar		Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
	{quotation\|To me, ''legacy code'' is simply code without tests}		{{quotation\|To me, ''legacy code'' is simply code without tests}}

	= Noch was? =		= Noch was? =

Ullrich am 28. November 2024 um 10:23 Uhr

2024-11-28T10:23:38Z

← Nächstältere Version		Version vom 28. November 2024, 10:23 Uhr
Zeile 3:		Zeile 3:
	= Motivation =		= Motivation =
	Zu den Regeln der Pfadfinderbewegung gehört der Satz:		Zu den Regeln der Pfadfinderbewegung gehört der Satz:
	~~:<q>~~Always leave the camp ground cleaner than you found it.~~</q>~~		{quotation\|Always leave the camp ground cleaner than you found it.}
	oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:		oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
	~~:<q>~~Try and leave this world a little better than you found it.~~</q>~~		{quotation\|Try and leave this world a little better than you found it.}
	In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):		In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
	Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren		Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Zeile 85:		Zeile 85:

	Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar		Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
	~~: Legacy~~ code is code without ~~unit~~ tests		{quotation\|To me, ''legacy code'' is simply code without tests}

	= Noch was? =		= Noch was? =

Ullrich: Die Seite wurde neu angelegt: „Category:Quality = Motivation = Zu den Regeln der Pfadfinderbewegung gehört der Satz: :Always leave the camp ground cleaner than you found it. oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat: :Try and leave this world a little better than you found it. In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen): Liegt irgendwo Müll herum, dann scheint da…“

2024-11-28T10:20:58Z

Die Seite wurde neu angelegt: „Category:Quality = Motivation = Zu den Regeln der Pfadfinderbewegung gehört der Satz: :<q>Always leave the camp ground cleaner than you found it.</q> oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat: :<q>Try and leave this world a little better than you found it.</q> In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen): Liegt irgendwo Müll herum, dann scheint da…“

Neue Seite

[[Category:Quality]]

= Motivation =
Zu den Regeln der Pfadfinderbewegung gehört der Satz:
:<q>Always leave the camp ground cleaner than you found it.</q>
oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
:<q>Try and leave this world a little better than you found it.</q>
In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Müll hinzuzufügen.
Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.
Aber was hat das nun mit Software Engineering zu tun?
Zum Äquivalent des Broken Windows Effect im Software Engineering ist hier recht nett beschrieben
(da ist wohl ein Link verloren gegangen).
Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.

== Über das Problem ==
Wer lange genug programmiert hat, weiß wie schlimm schlechter Code aussehen kann. Und immer wenn man
denkt man hat schon alles gesehen tritt man in eine Java-Klasse die alles dagewesene in den Schatten stellt. Der
erste Reflex ist meistens "weg damit, alles neu machen". Man bezeichnet dieses Refactoring-Vorgehen auch mit
dem treffenden Namen "Big Bang". Die Umsetzung bereitet in der Praxis allerdings eine ganze Reihe von
Problemen. Das größte ist, daß eine umfassende Refactoring-Maßnahme Aufwände generiert die aus keinem
Budget zu bekommen sind. Das liegt nicht nur an knausrigen Budget-Verwaltern, das liegt auch in der Natur der
Entstehung solcher Code-Höllen. Wer sich beim Codieren nicht um die Qualität kümmert schafft technologische
Schulden, für die keine Deckung existiert und für die in der Regel keine Rücklagen gebildet werden. So kommt Müll
zu Müll und aus kleinen dreckigen Code-Ecken werden langsam aber sicher riesige Müllhalden.
Ein anderes Problem verbirgt sich hinter der Metapher vom Abreißen und Neuaufbau des Systems. Diese aus dem
Hausbau stammende Metapher läßt sich nicht eins zu eins auf die Software-Entwicklung übertragen. Denn das
neue System wird ja nicht einfach aus "neuem" Material gebaut, sondern soll die Substanz des abgerissenen
Systems wiederverwerten. Oder auf den Code bezogen: Die Business-Logik, die sich im Müllhaufen verbirgt – und
das ist ja das eigentliche Kapital der Software, das was das System wertvoll macht – muß erhalten bleiben. Das
funktioniert – vielleicht – wenn man eine exzellente und erschöpfende Dokumentation des Systems hat die genau
die im System enthaltene Fachlichkeit dokumentiert, aber zu welchem System hat man eine solche
Dokumentation?

Der einzige Weg ist dann das akribsche Analysieren des bestehenden Codes und das Übertragen in die neue
Anwendung. Und da es sich um eine vollständige Neuentwicklung handelt muß jede Zeile im Rahmen der
Neuentwicklung untersucht werden; dazu gehört veralteter, nicht mehr verwendeter Code ebenso wie Code-
Gewölle deren Analyse aufgrund der Komplizierteit sehr zeitaufwändig ist. Es gibt keine Möglichkeit, auf
irgendeinen Teil dieser Analyse zu verzichten, denn mit der Migration muß sämtliche Funktionalität übertragen
werden. Sei sie nun offensichtlich oder unter hunderten verschachtelter Klassen vergraben.
Damit ist in vielen Fällen das Migrationsprojekt mangels Budget gestorben. Und weil die Komplettlösung nicht
umsetzbar ist, passiert meistens gar nichts. Dabei muß noch nicht einmal die gesamte Anwendung betroffen sein,
Oft geht es nur darum wesentliche Teile einem Refactoring zu unterziehen, was dann – Budget! Budget! – ebenfalls
nicht geschieht.

= Über die Lösung =
Wenn also der Big-Bang-Ansatz nicht durchführbar ist, was dann? Die kleine, mühsamere und weniger beglückende
Lösung ist der Weg der kleine Schritte. Und wenn man vor lauter Chaos nicht weiß wo anfangen, fängt man am
besten da an wo man gerade steht: Wann immer der Entwickler ein Stück Code bearbeitet oder reviewt – und sei es
noch so klein – dann habe er dabei immer die Frage im Hinterkopf
: Was kann ich hier ohne viel Aufwand besser machen?
Das scheint erstmal für lange Zeit gar nichts zu bringen und es ersetzt auch nicht das kostenintensive
Refactoring größerer Programmteile – besonders, wenn die Architektur Probleme verursacht – aber es hilft auf
lange Sicht Aufwände zu senken und kann den Code so vorbereiten, daß große Refactoring-Maßnahmen überhaupt
erst möglich werden.

= Was kann man konkret tun? =
Erlaubt ist alles, was die Code-Qualität verbessert, dabei aber die Funktionalität nicht beeinträchtigt und solange
man die Schnittstellen nicht anfaßt, ist praktisch alles erlaubt.
* Unit-Tests schreiben
* Dokumentation schreiben
* Kommentare korrigieren und ergänzen
* Methoden- und Klassennamen umbenennen
* Toten und auskommentierten Code entfernen
* Literale durch Konstanten und Konstanten durch Enums ersetzen
* Zweifelhafte Stellen als TODO oder FIXME markieren
* Ungenutzte Teile als "deprecated" markieren
* Code-Blöcke in Methoden auslagern
* Mehrfach verwendete Blöcke in Klassen auslagern
* if-Bedingungen umformen
* ...

= Worauf sollte man achten? =
Entscheidend ist, daß durch das Refactoring nichts kaputt geht. Bevor man also anfängt den Code umzukrempeln
muß man sich darüber klar werden, welche Auswirkung die Änderung hat. Wenn kein eigenes und ausreichendes
Budget für die Überarbeitung zur Verfügung steht, gestaltet man die Änderungen so defensiv wie möglich. Am
besten sichert man die Änderungen immer durch automatische Unit-Tests ab.

Aus diesem Grunde stehen die Unit-Tests in der Aufzählung oben auch ganz oben. Jeder Entwickler sollte immer
alles durch Unit-Tests abdecken – so die Theorie. Die Erhöhung der Testabdeckung ändert zwar überhaupt nichts
an der Code-Qualität, ist aber trotzdem sehr wertvoll. Tests sichern den Code gegen Änderungen ab. Bei der
nächsten Änderung, Erweiterung oder dem nächsten Refactoring merkt man hoffentlich sofort, wenn etwas kaputt
gegangen ist.

Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
: Legacy code is code without unit tests

= Noch was? =
Der brave Pfadfinder kümmert sich nicht darum, wer nach ihm kommt. Er sorgt einfach dafür, daß sich der Nächste
wohler fühlt wenn er sein Zelt aufschlägt. Wenn er aber weiß, daß demnächst eine große Gruppe zum Camping
anrückt, dann kann er – mit seinen Genossen – schon mal vorarbeiten. Was heißt das für den Softwerker?
Wenn man weiß, daß irgendwann die großen Refactorings anstehen, daß zum Beispiel das Datenbank-Modell
überholt wird oder ein anderes Framework verwendet werden soll; wenn man also planvoll auf irgendetwas hinarbeiten
möchte, dann kann man die Reinigungsarbeiten schon vorneweg in die richtige Richtung lenken. Hierzu konkrete
Anweisungen vorzugeben ist schwierig, am besten setzt man sich mit dem Team mal hin und überlegt, welches die
schlimmsten Probleme sind, wie man sie beseitigen möchte und wie man da hinkommen kann.

Dazu ein einfaches Beispiel:

Sind beispielsweise Zugriffe auf eine bestimmtes Modul (eine Datenbank oder ein Service) überall im Code verteilt
und auf unterschiedliche Weise implementiert, kann man ein Interface definieren, bei der nächsten Gelegenheit
den ersten Zugriff aus dem Code lösen, damit das Interface mit einer Klasse unterfüttern und verwenden. Kommt
der nächste Entwickler an anderer Stelle auf einen ähnlichen Zugriff, übernimmt er entweder die Implementierung
seines Vorgängers oder er implemetiert eine neue Klasse für das Interface und stellt sie neben die erste.
Irgendwann – wenn zeit ist – nimmt man sich die verschiedenen Implementierungen der Interface vor und konsolidiert die
Implementierungen.

Boy Scout Principle - Versionsgeschichte

Ullrich: /* Motivation */

Ullrich am 28. November 2024 um 10:24 Uhr

Ullrich am 28. November 2024 um 10:23 Uhr