Kann ich diesen Code ändern?

2 Kommentare

Kann ich diesen Code ändern?“ klingt nach einer ganz üblichen Frage im Projektalltag, aber meiner Meinung nach bringt diese Frage ein großes Problem im agilen Entwicklungsprozess ans Tageslicht.

Vorab: Die Frage ist sehr gut, zeigt sie doch die heeren Absichten ihres Stellenden: Verbessere gefundenen Code. Ständige Verbesserung ist eine der wichtigsten Grundsätze bei der Erstellung von sauberem Code. Aber die Frage an sich zeigt, daß etwas dem Fragesteller besorgt. Etwas steht in seinem Weg, ansonsten hätte er den Code einfach geändert. In Scrum nennt man dies ein „impediment“ welches gelöst werden muss, aber auch nicht Scrum Projekte sollten dieses Problem lösen. Nebenbei sei erwähnt, daß das Lösen konkreter Fallbeispiele nicht reicht. Das Problem sollte grundsätzlich angegangen werden damit die Frage nicht mehr gestellt werden muss.

Im Folgenden einige von mir als Problemursachen identifizierte Sachverhalte und Lösungsideen:

  • Der betroffene Code ist nicht zugänglich oder aus politischen gründen tabu ⇒ Überzeugt Eure Teams, daß gemeinsame Verantwortlichkeit für Code vorteilhaft für alle ist. Es geht insbesondere nicht darum bestimmte Verantwortlichkeiten anderer Teams zu übernehmen. Außerdem sind die meisten Entwickler sowieso vorsichtig bei solchen Änderungen. Insofern braucht man sich nicht vor der „common code ownership“ zu fürchten.
  • Das Refactoring bricht existierende API ⇒ Für die meisten Projekte ist das garkein so großes Problem wie oft dargestellt. Normalerweise wird die API nur intern verwendet und eine neue API könnt auch viel besser benutzbar sein. Selbst wenn die API extern verwendet wird ist eine kontrollierte Änderung durchaus möglich.
  • Der Entwickler traut seinen Fähigkeiten nicht ⇒ Die IT Welt verlangt nach kontinuierlichem Lernen und Veränderung und eigentlich mögen es sogar viele Entwickler an neuem Unbekannten zu arbeiten. Es ist völlig okay zögerlich zu sein, aber frische Ideen können alten Code besser oder robuster machen. Pair Programming mit dem ursprünglichen Ersteller des Codes, oder einem anderen erfahrenen Entwickler im Team hilft hierbei oft die Angst vor Änderungen zu nehmen. Und für den Fall, daß doch etwas passiert gibt es ja Tests…
  • Nichtvorhandene Tests machen Änderungen riskant ⇒ Es ist wichtig Zeit in das Schreiben von Tests zu investieren um das aktuelle Verhalten des Codes zu verifizieren und sicherzustellen, daß es mit dem Verhalten nach der Änderung identisch ist. Schwieriger ist es, wenn in der Änderung auch Verhalten geändert werden soll. Dann hilft es meist nur mit einem Architekten mögliche Implikationen zu diskutieren oder herauszufinden wer den Code aktuell überhaupt verwendet.
  • Die genaue Verwendung des Codes ist unbekannt ⇒ Ein möglichst umfassendes Architekturbild und so viel Code abhängiger Projekte wie möglich helfen die Auswirkungen von Änderungen abzusehen. Für Entwickler wäre ein Refactoringsetup der Entwicklungsumgebung mit sämtlichem Code hilfreich. IDEs bieten viele Refactoringtools und können die meisten Verwendungen von Code aufspüren. Größere Refactorings können auch auf eigenem Branch und unter Beobachtung durch ein Continous Integration system durchgeführt werden.
  • Aber es gibt kein Backup… ⇒ Oh, immer noch kein Versionskontrollsystem? Dies sollte schleunigst geändert werden.

Code verändern ist gut, da wir alle Code besser oder schöner machen wollen. Es hilft Lösungen verständlich und einfach zu halten. Wenn man die Ursachen wie Fehler oder Designschwächen nicht verbessert werden andere Entwickler anfangen diese mit Workarounds in ihrem Code zu umschiffen. Dies führt zu einer unschönen und nicht wartbaren Verschwendung von Bytes.

Mein Appell an alle Entwickler:
Scheut Euch nicht mit guten Absichten fremden Code zu verbessern.

Mein Appell an Projektleiter und Scrum Master:
Macht das Ändern fremden Codes schmerzfrei

Um mit einer aktuell allgegenwärtigen Phrase die Frage im Titel dieses Betrages zu beantworten:
Yes, you can!

Fabian Lange ist Lead Agent Engineer bei Instana und bei der codecentric als Performance Geek bekannt. Er baut leidenschaftlich gerne schnelle Software und hilft anderen dabei, das Gleiche zu tun.
Er kennt die Java Virtual Machine bis in die letzte Ecke und beherrscht verschiedenste Tools, die JVM, den JIT oder den GC zu verstehen.
Er ist beliebter Vortragender auf zahlreichen Konferenzen und wurde unter anderem mit dem JavaOne Rockstar Award ausgezeichnet.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.