Es gibt viele Faktoren, die Entwickler dazu bringen, sich der Verantwortung für die Qualität ihres Codes zu entziehen. Einer davon ist der tatsächliche oder vermeintliche Druck, die Arbeit effizient zu erledigen. Ich habe von Geschäftsleuten gehört, dass sie sich Sorgen darüber machen, dass Software-Entwickler und -Teams Over Engineering betreiben. Diese Befürchtung ist berechtigt, und dafür sind wir technischen Fachleute verantwortlich.
Over Engineering: Abstraktion vs. Pragmatismus
Ich habe einmal an einem Projekt für einen Kunden, eine große Versicherungsgesellschaft, gearbeitet. Es handelte sich um ein »Rettungsprojekt«. Ich arbeitete für ein Beratungsunternehmen, das dafür bekannt war, effiziente Lösungen für Projekte zu finden, die nicht vorankamen oder bei früheren Versuchen gescheitert waren.
Dieses Projekt war ziemlich spektakulär gescheitert, und zwar bereits zweimal. Es befand sich seit mehr als drei Jahren in der Entwicklung und man hatte nichts Brauchbares vorzuweisen.
Wir begannen mit der Arbeit und machten gute Fortschritte bei einem Ersatzprojekt. Ein Architekt aus der »Strategiegruppe« oder so ähnlich trat an uns heran. Er bestand darauf, dass unsere Software mit der »globalen Architektur« übereinstimmen müsse. Also habe ich als technischer Leiter des Projekts nachgeforscht, was das bedeuten würde.
Sie verfügten über einen eindrucksvollen Plan für eine verteilte, servicebasierte Komponentenarchitektur, der ihr gesamtes Geschäft abstrahierte. Es gab sowohl Services für technische Dinge als auch nützliche Verhaltensweisen auf Domänenebene. Ihre Infrastruktur sollte sowohl für Sicherheit und Persistenz sorgen als auch die vollständige Integration der Systeme im Unternehmen ermöglichen.
Wie Sie sicher schon vermuten, war das alles nur ein Hirngespinst. Es gab jede Menge Dokumente und eine Menge Code, der, soweit ich sehen konnte, nicht funktionierte. Dieses Projekt wurde von einem Team aus mehr als 40 Personen entwickelt und war etwa drei oder vier Jahre im Verzug. Alle Projekte waren verpflichtet, diese Infrastruktur zu nutzen, aber kein einziges Projekt tat dies jemals!
Es klang wie Magie, weil es Magie war; es war imaginär.
Wir lehnten höflich ab und beendeten das System, das wir aufbauten, ohne die Konzepte oder die Technologie dieser Architektur zu verwenden. Auf dem Papier sah die Architektur gut aus, aber in der Praxis war sie reine Theorie.
Gegen Over Engineering – der einfachste Weg zum Erfolg
Wir sind Technologen. Folglich haben wir bestimmte Tendenzen. Eine dieser Tendenzen, der wir uns bewusst sein und vor der wir uns hüten sollten, ist die Jagd nach »technisch glänzenden Ideen«. Ich bin genauso schuldig wie jeder andere, mich für technische Ideen zu interessieren. Das macht einen Teil des Reizes unserer Disziplin aus, die Art des Lernens, die wir schätzen. Wenn wir jedoch Ingenieure sein wollen, müssen wir einen gewissen Pragmatismus, ja sogar Skepsis an den Tag legen. Ein Teil meiner Definition von Engineering beinhaltete die Formulierung »im Rahmen wirtschaftlicher Zwänge«. Wir sollten immer an den einfachsten Weg zum Erfolg denken, nicht an den coolsten, nicht an den Weg mit der meisten Technik, die wir in unseren Lebenslauf einbauen können.
Halten Sie sich auf jeden Fall über neue Ideen auf dem Laufenden. Seien Sie sich neuer Technologien oder Ansätze für Ihre Arbeit bewusst, aber bewerten Sie deren Einsatz immer ehrlich im Kontext des Problems, das Sie zu lösen versuchen. Wenn Sie diese Technologie oder Idee anwenden, um herauszufinden, ob sie nützlich ist, dann erkennen Sie diese Tatsache an und führen Sie Ihre Erkundung schnell und effizient als Versuch, Prototyp oder Experiment durch, nicht als Grundstein Ihrer neuen Architektur, von der die Zukunft des Unternehmens abhängt. Seien Sie darauf vorbereitet, sie zu verwerfen, wenn sie sich nicht bewährt, und riskieren Sie nicht die gesamte Entwicklung für eine Technologie, die cool aussieht.
Meiner Erfahrung nach ist es eher wahrscheinlicher als unwahrscheinlicher, dass wir am Ende etwas Cooles machen, wenn wir dieses Konzept des »Strebens nach Einfachheit« ernst nehmen. Und es ist eher wahrscheinlicher als unwahrscheinlicher, dass wir damit auch unsere Lebensläufe aufwerten.
»Das brauchen wir jetzt vielleicht nicht, aber in der Zukunft wahrscheinlich schon«
Es gibt noch etwas anderes, durch das wir oft dazu verleitet werden, unsere Lösungen zu sehr zu technisieren. Nämlich um sie zukunftssicher zu machen. Wenn Sie jemals gesagt oder gedacht haben: »Das brauchen wir jetzt vielleicht nicht, aber in der Zukunft wahrscheinlich schon«, dann haben Sie es »zukunftssicher« gemacht. Ich habe mich dessen in der Vergangenheit genauso schuldig gemacht wie jeder andere auch, aber ich betrachte es inzwischen als ein Zeichen der Unreife von Design und Engineering.
Wir nehmen diese Art von zukunftssicherem Design in Angriff, um uns eine gewisse Absicherung zu verschaffen, dass wir in der Lage sein werden, mit zukünftigen Erweiterungen oder veränderten Anforderungen fertigzuwerden. Das ist ein gutes Ziel, aber die falsche Lösung.
In Kent Becks Buch Extreme Programming Explained wurde mir das folgende Konzept vorgestellt:
YAGNI: You Ain’t Gonna Need It!
Kents Rat war, dass wir Code schreiben sollten, um das Problem zu lösen, mit dem wir gerade konfrontiert sind, und nur dafür. Ich wiederhole diesen Ratschlag nachdrücklich, aber er ist Teil eines größeren Ganzen.
Wie ich bereits mehrfach in diesem Buch gesagt habe, ist Software eine ungewöhnliche Sache. Sie ist fast unendlich flexibel und extrem fragil. Wir können jedes beliebige Konstrukt im Rahmen der Software-Entwicklung erstellen, aber wir laufen Gefahr, dieses Konstrukt zu beschädigen, wenn wir es ändern. Das Problem, das die Menschen zu lösen versuchen, wenn sie ihre Lösungen übertechnisieren, indem sie sie zukunftssicher machen, ist ihre Angst, den Code zu ändern.
Als Reaktion auf diese Nervosität versuchen sie, das Design rechtzeitig zu reparieren, während sie es noch im Blick haben. Ihr Ziel ist es, dass sie in Zukunft nicht mehr überarbeiten müssen. Wenn Sie dieses Buch bis hierher gelesen haben, wissen Sie inzwischen, dass ich das für eine sehr schlechte Idee halte, was also könnten wir stattdessen tun?
Wir könnten unseren Code so designen, dass wir in der Zukunft jederzeit darauf zurückkommen und ihn ändern können, wenn wir etwas Neues gelernt haben. Wir können uns diese nahezu unbegrenzte Flexibilität zunutze machen. Das Problem, das wir nun lösen müssen, ist die Fragilität unseres Codes.
Was muss geschehen, damit wir darauf vertrauen können, dass wir unseren Code in Zukunft sicher ändern können? Es gibt drei Ansätze, und einer davon ist dumm.
Der Held rettet den Tag
Wir könnten so klug sein, dass wir den Code und alle seine Auswirkungen und Abhängigkeiten vollständig verstehen, sodass wir Änderungen sicher vornehmen können. Das ist das Modell des Heldenprogrammierers, und obwohl es das Dümmste ist, was man machen kann, ist es auch eine der gängigeren Strategien, soweit ich das beurteilen kann.
In den meisten Unternehmen gibt es eine kleine Anzahl von »Helden«, die »den Tag retten«, wenn etwas schiefläuft, oder die für schwierige Änderungen, die vorgenommen werden müssen, herangezogen werden. Wenn Sie einen Helden in Ihrem Unternehmen haben, muss er daran arbeiten, sein Wissen zu verbreiten und mit anderen zusammenzuarbeiten, um das System verständlicher zu machen. Dies ist wesentlich wertvoller als die üblichen Notfallmaßnahmen, die »Helden« üblicherweise durchführen.
Die wirklichen Lösungen für das Problem, Angst davor zu haben, den Code zu ändern, sind Abstraktion und Testen. Wenn wir unseren Code abstrahieren, verbergen wir definitionsgemäß die Komplexität in einem Teil des Systems vor einem anderen. Das bedeutet, dass wir den Code in einem Teil des Systems mit größerer Sicherheit ändern können, und zwar mit einem viel größeren Maß an Vertrauen, dass unsere Änderung, selbst wenn sie falsch ist, keine negativen Auswirkungen auf andere Teile haben wird. Um dies noch sicherer zu machen, brauchen wir auch Tests, aber wie üblich ist der Wert von Tests nicht so einfach zu ermitteln.
Dieser Artikel ist ein Auszug aus dem Buch „Modernes Software Engineering“ von David Farley. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe findet ihr bei uns im Shop.