Читать книгу Prinzipien des Softwaredesigns - John Ousterhout - Страница 15

Die meisten Menschen gehen die Softwareentwicklung mit einer mentalen Haltung an, die ich als taktische Programmierung bezeichne. Dabei geht es ihnen vor allem darum, etwas zum Laufen zu bringen, wie zum Beispiel ein neues Feature oder einen Bugfix. Auf den ersten Blick ist das total vernünftig: Was könnte wichtiger sein, als Code zu schreiben, der funktioniert? Trotzdem sorgt taktische Programmierung dafür, dass ein gutes Systemdesign nahezu unmöglich wird.

Das Problem bei der taktischen Programmierung ist ihre Kurzsichtigkeit. Programmieren Sie taktisch, versuchen Sie, eine Aufgabe so schnell wie möglich fertigzustellen. Vielleicht haben Sie eine harte Deadline. Dann hat zukunftsorientiertes Planen keine so hohe Priorität. Sie wenden nicht viel Zeit auf, nach dem besten Design Ausschau zu halten – Sie wollen nur, dass etwas schnell funktioniert. Sich selbst beruhigen Sie damit, dass es in Ordnung ist, ein bisschen Komplexität ins System zu bringen oder ein oder zwei kleine schmutzige Tricks anzuwenden, wenn die aktuelle Aufgabe damit schneller abgeschlossen ist.

So werden Systeme komplizierter. Wie im vorherigen Kapitel besprochen, ist Komplexität inkrementell. Es ist nicht diese eine besondere Sache, die ein System komplizierter macht, sondern das Aufsummieren Dutzender oder Hunderter kleiner Dinge. Programmieren Sie taktisch, wird jede Programmieraufgabe ein bisschen zu dieser Komplexität beitragen. Jeder Schritt scheint ein vernünftiger Kompromiss zu sein, um die aktuelle Aufgabe schnell abzuschließen. Aber die Komplexität wächst schnell, insbesondere wenn alle taktisch programmieren.

Über kurz oder lang werden einige der Komplexitäten für Probleme sorgen, und Sie beginnen, sich zu wünschen, sie hätten frühere Workarounds nicht genutzt. Aber Sie werden sich einreden, dass es wichtiger ist, das nächste Feature fertigzustellen, als einen Schritt zurückzugehen und den bestehenden Code zu refaktorieren. Refaktorieren mag Ihnen langfristig helfen, aber es verlangsamt definitiv die aktuelle Aufgabe. Also suchen Sie nach schnellen Korrekturen, um Probleme zu umgehen, denen Sie sich gegenübersehen. Das sorgt für noch mehr Komplexität, was weitere schnelle, schmutzige Fixes erfordert. Ziemlich schnell ist der Code ein großes Durcheinander, aber jetzt ist alles schon so verworren, dass es Monate brauchen würde, das Ganze aufzuräumen. Solch eine Verzögerung würde Ihr Zeitplan nicht zulassen, und das Beheben von ein oder zwei Problemen scheint keinen großen Unterschied auszumachen, also bleiben Sie bei der taktischen Programmierung.

Sofern Sie sehr lange an einem großen Softwareprojekt gearbeitet haben, ist Ihnen taktische Programmierung vermutlich bereits begegnet, und Sie sind auch schon über die Probleme gestolpert, die diese verursacht. Haben Sie einmal den taktischen Weg eingeschlagen, ist es schwer, die Richtung zu ändern.

In so gut wie jeder Softwareentwicklungsorganisation gibt es mindestens eine Person, die taktische Programmierung ins Extrem treibt: ein taktischer Tornado. Diese Person ist sehr produktiv und wirft Code schneller als alle anderen aus, geht aber vollkommen taktisch vor. Geht es darum, mal eben ein Feature zu implementieren, ist keiner so schnell wie der taktische Tornado. In manchen Organisationen behandelt das Management die taktischen Tornados als zu verehrendes Vorbild. Aber sie hinterlassen eine Schneise der Verwüstung. Diejenigen, die in Zukunft mit ihrem Code arbeiten müssen, verehren sie eher selten. Meist müssen andere später das Chaos aufräumen, das die Tornados mit ihrem Code hinterlassen haben – was dann so aussieht, als wäre der »Reinigungstrupp« (die wahren Helden) langsamer als der Tornado.