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

Welches Ausmaß an Investitionen in ein besseres Design ist nun angemessen? Es wäre nicht effektiv, zu Beginn riesig viel Aufwand zu treiben, um zum Beispiel direkt das gesamte System zu designen. Das entspräche der Wasserfallmethode, von der wir wissen, dass sie nicht funktioniert. Das ideale Design tendiert dazu, sich Schritt für Schritt zu entwickeln, während Sie Erfahrungen mit dem System sammeln. Daher ist es am besten, kontinuierlich viele kleine Investitionen zu tätigen. Ich schlage vor, etwa 10 bis 20 % Ihrer gesamten Entwicklungszeit für Investitionen aufzuwenden. Das ist so wenig, dass es Ihre Zeitpläne nicht signifikant beeinträchtigt, aber so viel, dass es mit der Zeit signifikante Vorteile bringt. Ihre ersten Projekte werden daher um 10 bis 20 % länger dauern als bei einem rein taktischen Vorgehen. Diese zusätzliche Zeit führt aber zu einem besseren Softwaredesign, und Sie werden innerhalb weniger Monate die Vorteile erkennen. Es wird nicht lange dauern, bis Sie mindestens 10 bis 20 % schneller entwickeln, als wenn Sie taktisch programmieren würden. Ab diesem Punkt werden sich Ihre Investitionen auszahlen: Die Vorteile Ihrer früheren Investitionen werden Ihnen so viel Zeit sparen, dass die Kosten zukünftiger Investitionen damit abgedeckt sind. Sie werden die Kosten der ersten Investitionen schnell wieder eingespielt haben. Abbildung 3-1 verdeutlicht das.

Programmieren Sie hingegen taktisch, werden Sie Ihre ersten Projekte um 10 bis 20 % schneller abschließen, aber mit der Zeit wird sich Ihre Entwicklung verlangsamen, wenn sich die Komplexität ansammelt. Es wird nicht lange dauern, bis Sie mindestens 10 bis 20 % langsamer programmieren. Schnell werden Sie die Zeit verbraucht haben, die Sie zu Beginn einsparen konnten, und für die restliche Lebensdauer des Systems werden Sie langsamer entwickeln, als wenn Sie den strategischen Ansatz verfolgt hätten. Haben Sie noch nie in einer wirklich schlimm heruntergekommenen Codebasis gearbeitet, sprechen Sie mal mit einer Person, die das schon getan hat – sie wird Ihnen bestätigen, dass schlechte Codequalität die Entwicklung um mindestens 20 % verlangsamt.

Der Begriff technische Schulden wird oft verwendet, um die Probleme zu beschreiben, die durch taktische Programmierung verursacht werden. Mithilfe taktischen Programmierens borgen Sie sich Zeit aus der Zukunft: Die Entwicklung wird jetzt schneller sein, aber später mehr Zeit benötigen. Wie bei finanziellen Schulden werden Sie mehr zurückzahlen müssen, als Sie sich geborgt haben. Aber anders als bei finanziellen Schulden werden technische Schulden nie vollständig zurückgezahlt: Sie werden immer und immer wieder zahlen müssen.

Abbildung 3-1 wirft eine wichtige Frage auf: Wo schneiden sich die strategische und die taktische Kurve? Mit anderen Worten: Wie lange dauert es, bis sich der strategische Ansatz auszahlt? Ich kenne leider keine Daten zu diesem Thema, und es wäre auch schwierig, ein kontrolliertes Experiment so durchzuführen, dass die Antwort überzeugen könnte. Meiner persönlichen Meinung nach liegt der Zeitpunkt im Bereich zwischen 6 und 18 Monaten. Er hängt stark vom Erinnerungsvermögen der Entwicklerinnen und Entwickler ab: Ist ein Codeabschnitt ein paar Monate alt, hat man das meiste von dem vergessen, was man sich beim Schreiben dabei gedacht hat. Die Entwicklung wird dadurch signifikant verlangsamt, wenn der Code komplex ist. Diese zusätzlichen Kosten gleichen schnell einen initialen Vorsprung gegenüber der strategischen Programmierung aus. Aber wie gesagt: Das ist nur meine Meinung, und ich habe keine Daten, die das bestätigen können.