Entwickler machen Refactorings – auch wenn der Kunde davon nichts sieht!

Hartmut Schlosser

Technische Refactorings durchzuführen, obwohl der Kunde im Frontend davon gar nix merkt – die meisten JAXenter-Leser halten das durchaus für sinnvoll, wenn dadurch bessere Entwicklungsbedingungen geschaffen werden. Das Ergebnis des Quickvote zu unserer Kolumne „Be pragmatic, not dogmatic: Die zwei Gesichter der Agilität“ war eindeutig wie selten zuvor:

Was bringen technische Refactorings ohne fachlichen Mehrwert?
  • Refactorings sollte man auch dann durchführen, wenn für die Entwickler eine bessere Situation geschaffen wird. Es macht keinen Sinn zu versuchen, jederzeit einen fachlichen Mehrwert zu erzeugen, wenn dadurch kritische Produktionsbedingungen entstehen. (88%)
  • Ich stimme dem agilen Grundsatz zu, dass jede Codeveränderung für den Sponsor einen wirklichen Mehrwert bringen sollte. Ein umfangreiches Refactoring ist nur dann sinnvoll, wenn der Kunde unmittelbar Nutzen daraus zieht. (13%)
  • Teilnehmer: 304

Natürlich hängt das Problem auch mit den genauen Umständen in einem Projekt zusammen: Wie groß?, Für wen?, Langfristig oder kurzfristig angelegt? Auch zur Frage, was man denn unter einem Refactoring überhaupt verstehen sollte, gibt es unterschiedliche Auffassungen – die in der interessanten Diskussion zum Thema angeschnitten werden. Diskutieren Sie mit!

Doch wie wäre die Umfrage wohl ausgefallen, wenn wir nur die Kunden – und nicht die Entwickler hier auf JAXenter – gefragt hätten?

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.