Ein Blick auf ihren Code

Mein Code ist der Beste

Jeder hält den eigenen Code für den Besten und sich selbst für einen guten Entwickler. Wie in vielen Situationen gilt: Es ist manchmal besser eine zweite Meinung zu hören. Sie haben das Gefühl, dass in Ihrer Entwicklungsabteilung unflexibel ist, zu viele Fehler entstehen und alles zu lange braucht. Ich sehe mir ihren Code an und helfe ihnen Strategien zu erarbeiten, die ihnen helfen wieder richtig Fahrt aufzunehmen.

"Ich hatte keine Zeit es ordentlich zu machen"

Was auf den ersten Blick nach einer Ausrede aussieht, entpuppt sich schnell als Kommunikationsproblem oder Mangel an Vertrauen in die Entscheidungsprozesse. Manchmal fehlt eine Person, die für die Qualität des Codes einsteht und dafür einen realistischeren Zeitrahmen einfordert. Code sauber zu schreiben darf keine Frage der Zeit sein. Aber zeitlicher Druck kann einen enormen Einfluss auf die Qualität des Codes haben. Auch Reviews brauchen Zeit und Ihre Mitarbeiter brauchen Zeit für Reviews gewissenhaft durchzuführen. Nicht nur Entwickler müssen hier umdenken, auch Projektleiter und Führungskräfte. Für diese ist es mitunter schwerer als für die Entwickler. Oft können hier Kompromisse helfen: Wir lösen das Problem bis zum Termin, erhalten dann aber nochmal Zeit es sauber zu lösen.

Den Entwickler mitnehmen

Einfach Regeln und Vorschriften zu definieren kann keine Lösung sein. Die Entwickler mitzunehmen und ihnen zu erklären, warum ein etwas anderes Vorgehen besser ist, ist effektiver. Nur wenn der Entwickler, die Einsicht hat, dass er an seiner Art Programme zu schreiben etwas ändern muss, kann sich auch langfristig etwas ändern.

Positive Erfahrungen sind ein wichtiger Bestandteil meiner Arbeit. Guten Code zu loben ist genauso wichtig wie konstruktive Hinweise zu geben schlechten Code zu verbessern. Dabei ist es auch extrem wichtig zwischen kleinen Hinweisen und absoluten No-Go's zu unterscheiden und das auch gegenüber dem Entwickler zu kommunizieren.

Tooling ersetzt keine Kommunikation

Oft reicht es nicht entsprechende Tools zu etablieren und per Review-Kommentaren mit dem Entwickler zu kommunizieren. Für den Entwickler ist es wichtig einen Ansprechpartner zu haben, der ihm hilft, den Kommentar zu verstehen. Mitunter werden Hinweise auch als harte Kritik interpretiert und sorgen für Unverständnis bei dem Entwickler. Um hier nicht unnötig Frust aufkommen zu lassen, ist direkte Kommunikation wichtig.

Kompetenzen aufbauen

Damit sie nicht permanent von externen Dienstleistern abhängig sind, helfe ich ihnen, die Mitarbeiter mit gutem Code in ihrem Unternehmen zu identifizieren und mit diesen intern eigene Kompetenzen für Reviews aufzubauen. Die Möglichkeiten von Mitarbeitern zu stärken, für die es nicht nur wichtig ist, Anforderungen möglichst schnell umzusetzen, sondern denen auch die Qualität des Codes wichtig ist und dafür einstehen.

Wirtschaftlichkeit als Totschlagargument

Oft erkennen einzelnen Entwickler Probleme im Code schon frühzeitig. Aber es fehlen ihnen die notwendigen Argumente, ein umfangreiches Refactoring in die Wege zu leiten. Den wirtschaftliche Nutzen, können sie schlecht in Zahlen fassen und auch die Kosten für das Refactoring zu benennen fällt ihnen schwer. Die Kosten für schlechten Code sind ebenfalls schlecht greifbar. Sie lassen sich nicht von den eigentlichen Entwicklungskosten für eine neue Funktion trennen. Von Führungskräften werden Refactorings, die der Codequalität dienen, daher häufig als unwirtschaftlich und unnötig angesehen und abgelehnt. Doch meist reduziert genau dieses Vorgehen unmerklich die Wirtschaftlichkeit des Produktes. Neue zusätzliche Mitarbeiter werden eingestellt um die sich reduzierende Geschwindigkeit zu kompensieren. Meist ist der Erfolg jedoch wesentlich geringer als erhofft.