Refactoring

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 …)
Von mario.van-zadel, vor

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 …)
Von mario.van-zadel, vor

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 …)

Von mario.van-zadel, vor