Code review’en, den es nicht gibt

„Wir führen nun Code-Reviews ein“. Dies ist ein Satz, der oft gesagt wird, um den Startschuss für bessere Code-Qualität und eine Wissensverteilung im Team zu geben. Bevor eine Quellcode-Änderung in den Haupt-Entwicklungszweig zurückgeführt wird, wird diese von mindestens einem anderen Entwickler begutachtet und freigeben. Man verspricht sich dadurch, dass eventuelle Fehler identifiziert werden, bevor die Quellcode-Änderung in das Produktiv-System übertragen wird und Schaden verursachen.

(mehr …)

Code löschen

Nach „Wir müssen diesen Code unbedingt neu schreiben“ kommt „Wir lassen den alten Code erst einmal liegen, bis wir alle Stellen auf die Neuentwicklung umgestellt haben“. Nach einiger Zeit sind dann alle Code-Stellen auf die Neuentwicklung umgestellt, sodass der alte Code nicht mehr ausgeführt wird. Zur „Sicherheit“ wird dieser jedoch noch nicht gelöscht. Vielleicht als Fallback, weil es einfach vergessen wurde oder weil niemand den Mut hatte, den Code einfach zu löschen.

(mehr …)

Den Entwicklungsprozess automatisieren

Warum automatisieren? „Dafür haben wir in dieser Projektphase keine Zeit.“, “ Das Projekt ist zu klein dafür“ und “ Jeder Entwickler weiß, was zutun ist“ sind nur einige Ausreden Gründe, warum der Entwicklungsprozess nicht automatisiert wird. Wir haben es oft beobachtet, dass das Team tatsächlich keine Automatisierung benötigt: Es gibt den Entwickler X, der die neuen Software-Artefakte erstellt und auf den Servern verteilt und den Tester Y, der auf seinem zweiten Rechner unter dem Schreibtisch die Tests ausführt.

(mehr …)

Tests für alten Code schreiben

Nachdem der Entwicklungsprozess automatisiert, die Test-Umgebung aufgesetzt und die ersten Tests für neue Klassen entwickelt wurden, stellt sich die Frage, was mit dem bereits bestehenden Code geschehen soll.  Der Code ist teilweise sehr alt, hat viele Abhängigkeiten und scheint untestbar zu sein. Aufgrund des Alters handelt es sich evtl. sogar um Code, der von Entwicklern geschrieben wurde, die schon seit langer Zeit nicht mehr im Unternehmen tätig sind. Niemand traut sich wirklich an den Code ran und Refactoring-Maßnahmen werden vermieden.

(mehr …)

Step-by-Step mit dem Adapter-Pattern

Nehmen wir an, im Rahmen der Software-Sanierung soll eine bestehende Klasse neu entwickelt werden. Dabei soll auch direkt die Schnittstelle (also das Interface) angepasst werden. Wird die Schnittstelle verändert, so sind alle Codestellen, die die Schnittstelle der ursprünglichen Klasse verwenden, nicht mehr mit der überarbeiteten Klasse kompatibel.

(mehr …)

Refactoring-Tipp: Variablen umbenennen

Bekanntlich wird die Code-Qualität in der Einheit WTFs/min gemessen (WTF = What the f**k). Lassen Sie einen fremden Entwickler Ihren Quellcode lesen und zählen Sie die minütlichen WTFs, die diese Person ausspricht.

Diese WTFs werden ausgesprochen, weil der fremde Entwickler den Quellcode nicht versteht und nicht nachvollziehen kann. Er liest ihn und wird ständig durch Unklarheiten aus dem Fluss gerissen.

(mehr …)

Wie erhält man eine Budget-Freigabe für die Software-Sanierung?

Software-Sanierungen sind teuer und die Kosten können nach der Erstellung des Maßnahmen-Plans relativ genau abgeschätzt werden. Anders sieht es bei den Opportunitätskosten aus. Sind die Software-Entwickler größtenteils mit der Fehlerbehebung beschäftigt, haben sie weniger Zeit für die Umsetzung von neuen Features und die Anpassung des Quellcodes an die neuen Gegebenheiten (zu dem Zeitpunkt einfache Refactoring-Maßnahmen). (mehr …)

Wie und wo fängt man an?

Nachdem feststeht, dass Sie Ihre Software sanieren möchten, stellt sich die Frage, wie und wo man denn nun am besten anfängt. Es ist alles so unübersichtlich und verwoben. Es scheint, als wäre es unmöglich die ersten Schritte zu gehen, ohne an anderer Stelle Probleme zu verursachen. Auf der Seite „Wie gehen wir vor?“ haben wir beschrieben, dass wir alle zu erledigenden Aufgaben sammeln und in kurz-, mittel- und langfristige Maßnahmen einteilen.

(mehr …)