Die Idee zu dieser Kolumne entstand über viele Jahre hinweg durch Gespräche mit Entwicklern, Senior-Entwicklern und Software-Architekten - oder Menschen, die dies sein wollten oder sollten. Ja, oftmals wird einem solch eine Rolle einfach aufgestempelt, unfassbar, oder? :-) Aber auch die Menschen in den Anzügen sollen hier ihr Recht erhalten. Ich werde das eine oder andere Thema aufgreifen, bei dem sich sicherlich manch ein Manager, der mit den vorhin genannten zu tun hat, bestätigt fühlt. Lasst euch überraschen...
Ich habe aber auch die gegenteilige Erfahrung gemacht! Entwickler, die die gennanten Rollen einfach annehmen, wenn sie bemerken, dass sich ein Loch auftut. Sie schließen diese Löcher, ohne zu lamentieren und ohne auf Titel, Rechte und dergleichen zu pochen. Wenn diese Entwickler nun auch noch faul sind, entsprechen sie meinem persönlichen Ideal! Denn Faulheit ist aus meiner Sicht der beste Ausgangspunkt, pragmatisch zu handeln, solange sie dazu führt, wiederkehrende Dinge zu automatisieren. Die Qualität sollte natürlich nicht unter der Faulheit leiden.
Noch ein wichtiger Punkt, der unbedingt angemerkt werden muss: Alles, was ich hier schreibe, ist meine persönliche Meinung und spiegelt auch nur diese wider. Diskussionen sind herzlich willkommen, die Themen eignen sich meiner Meinung nach hervorragend dafür! Und falls sich der eine oder andere Kollege angesprochen fühlt - natürlich ist alles frei erfunden und etwaige Ähnlichkeiten sind rein zufällig... :-)
"Best Tool for a Problem" versus "If you only have a hammer, every problem is a nail..."
Kommen wir also zum ersten fiktiven "Erfahrungsbericht", den ich niemanden vorenthalten möchte.
Ich kam zu einem Entwickler, welcher wild fluchend und gestikulierend vor seiner Spring-Konfiguration saß und nicht recht weiter wusste. Er arbeitete in einem Projekt, welches bislang komplett mittels dem Spring-Stack realisiert war. Eigentlich denkt man ja "Klasse Sache, endlich ist alles nach Schema-F". Jeder Spring-erfahrene Entwickler wird sich sofort zurecht finden und kann innerhalb des Projekts schnell performant arbeiten.
Der fluchende Entwickler jedoch fand innerhalb des Spring-Stacks keine Lösung für sein aktuelles, konkretes Problem, die ihm einfach genug erschien. Spring lieferte keine einfache Lösung, was zugegebenermaßen eher selten vorkommt. Er sprach mit dem für die Architektur verantwortlichen Kollegen, wie er denn nun vorgehen sollte, und schlug eine Lösung vor, welche mit ein paar wenigen Zeilen zusätzlichen Codes, rein auf dem für das Projekt eingesetzten JDK, funktionierte.
Der verantwortliche Mitarbeiter jedoch bestand darauf, dass die Lösung "ordentlich" mittels Spring realisiert werde, da sonst ja das Schema nicht eingehalten und dadurch die Wartbarkeit des Projekts gefährdet würde. Weiterhin könnte es ja sein, dass man noch öfters innerhalb des Projekts "auf das gleiche Problem stoße".
Eigentlich, so denke ich, ist das die richtige Vorgehensweise des verantwortlichen Mitarbeiters. Nachdem ich allerdings das konkrete Problem - ich gehe bewusst nicht darauf ein, da es sich hier nicht um ein technisches sondern um ein methodisches Problem handelt - mit dem Kollegen zusammen analysiert und diskutiert hatte, wurde klar, dass in diesem Fall die Konfiguration derart umständlich und dadurch schwer zu warten wurde, dass man sich mehr Ärger ins Boot holte als man damit vermied. Es war also letztlich nachteilig, die Architekturvorgaben einzuhalten.
Meine Meinung zu diesem kleinen Dilemma:
Es hilft nur bedingt, Mustern und Schemen bedingungslos zu folgen. Man sollte sich Alternativen, die einem vorgetragen werden, genau anhören. Gute Architekten hören ohnehin immer mehr auf das Team als auf ihren Bauch ;-) Wenn die Alternative darin besteht, andere Bibliotheken ins Boot zu holen, sollte man sehen, ob sich diese gut mit den bereits vorhandenen integrieren lassen. Dann kann das durchaus eine Lösung sein.Im konkreten Fall wurde als Alternative jedoch der Einsatz des Java-Standard-API vorgeschlagen. Somit wäre es aus meiner Sicht kein Problem gewesen, dieses einzusetzen, da Spring selbst auch oft genau diese nur ordentlich nutzbar wrapped und bereitstellt. Wenn hier das Wrapping aber nicht gelungen ist – ja, das gibt’s manchmal! -, dann sollte man die Scheubrille absetzen und einfach mal Fünfe gerade sein lassen und das Problem pragmatisch lösen.
Die "spätere mögliche Nutzbarkeit" ist für mich sogar ein Showstopper. Dieses Argument habe ich schon so oft gehört, dass es mir in den Ohren klingelt. An dem Tag, an dem diese Wiederverwendbarkeit wirklich greifen würde, kann man immer noch das Refactoring anstoßen und sich zu diesem Zeitpunkt den Mehraufwand einholen. Anderenfalls ist der Code solange unnötig, verschmutzt die Codebasis und erhöht die Komplexität in der Wartung, bis er gebraucht wird. Bis dahin ist der Code so einfach wie möglich zu halten - und somit wäre aus meiner Sicht die Lösung über das Java-Standard-API die beste. Sie demotiviert den Entwickler nicht, und sie hindert nicht daran, dass es später dennoch refactored wird.
