Wer kennt das nicht, es soll ein bestehendes Projekt weiterentwickelt werden, aber es gibt keine Möglichkeit nachzuvollziehen, wieso eine Feature so umgesetzt wurde. Warum der Code so aufgeteilt wurde oder welche Idee hinter diesem einen Modul steckt. Alternative auch gerne, wieso ein Stück Code kopiert wurde, statt es einfach wieder zu verwenden.
Wir haben es gerade erst wieder erlebt
Als wir ein Bestandsprojekt übernommen haben und gerade dachten wir hätten den Code jetzt einigermaßen verstanden kam der PO mit einem neuen Feature-Wunsch. Nichts aufwändiges eigentlich. Gut um in das Projekt weiter eintauchen zu können.
Nur dann kam die Realität. Das neue Feature war eine Erweiterungswunsch für den bestehende Funktion. Leider waren der ursprüngliche Projektleiter und auch der ehemalige Entwickler nicht mehr im Unternehmen des Kunden. Dazu kam, die Historie der Versionsverwaltung Git war nicht wirklich aussage Kräftig. Da standen dann Informationen drin wie z.B.:
<...>
f9b06fc2 fix async creatable select, some cleanup
41e18b45 more optimizations
7f9a1044 optimize conversation view part I
<...>
Und natürlich waren da auch alle Möglichen Dateien mit angefasst worden, die nicht unbedingt in Zusammenhang mit den eigentlichen Anforderungen hatten.
Also Ärmel hoch, tief Durchartmen und durch da ...
Am Ende hat es natürlich funktioniert. Auch wenn es sich um Legacy Code handelt, ist es ja kein Hexenwerk. Leider hat es dadurch aber deutlich mehr Zeit gekostet das Feature umzusetzen und sicher zustellen, das es auch so funktioniert wie erwartet.
Mehr Zeit und dadurch auch mehr Kosten für den Kunden. Mehr als das eigentliche Feature in der Umsetzung gekostet hätte.
Deshalb setzen wir in unseren Projekten auf Nachvollziehbarkeit
Auch wenn wir in der Vergangenheit in vielen Teams dadrüber diskutiert haben und über die Für und Wider gerungen haben. Am Ende konnten wir doch oft von den Vorteilen von (link: https://www.conventionalcommits.org text: Conventional Commits rel: external nofollow) überzeugen.
Klar, am Anfang ist es für viele eine Umstellung. Es muss sich überlegt werden, welche Teile der Änderungen gehört zu welchen Feature oder war es jetzt nur ein kurzes Refactoring. Wer würde da nicht einfach gerne einen Commit draus machen und sagen das gehört schon irgendwie alles zusammen zu dem Feature?
Doch am Ende gibt uns die Erfahrung recht, wenn ich die Änderungen und das Refactoring getrennt behandle und beschreibe, haben es alle nach mir deutlich einfacher.
Übrigens auch ich habe es dann einfacher, denn nach einem Monat und fünf weitern Features weiß ich auch nicht mehr 100%-ig wieso ich da noch diese eine Änderung gemacht habe.
Es geht am Ende nicht nur um die Nachvollziehbarkeit, sondern ein großer Vorteil von menschen- **und** maschinenlesbarer Information ist, es können sinnvolle Automatisierungen darauf aufgesetzt werden.
Es kann dadurch z.B. die Versionierung der Projekte automatisiert werden, Stichwort (link: https://semver.org text: Semantic Versioning rel: external nofollow). Dadurch wird das automatisieren von Prozessen wie das Erstellen und Veröffentlichen von Packet deutlich vereinfacht.
