Wie eine verfrühte Optimierung Ihre Entwicklungsanstrengungen ruinieren kann

Optimierung, sei es Code oder Architektur, ist ein heikles Thema für alle, die mit Softwareentwicklung zu tun haben. Es ist leicht, vorschnell ein Modul oder eine Methode zu ändern, wenn man glaubt, dass sich dadurch die Verarbeitungszeit verkürzt oder der Prozess besser abläuft. Man muss sich darüber im Klaren sein, dass jede Optimierung nur ein Zusatz ist und nicht die Hauptstütze der Entwicklung sein kann.

Seit Donald Knuth in den 1970er Jahren feststellte, dass "vorzeitige Optimierung die Wurzel allen Übels" ist, tobt eine regelrechte Debatte. Es gibt viele Stimmen, die dafür sind und solche, die sie nicht völlig außer Acht lassen. Es gibt viele, die glauben, dass ein gut durchdachter Entwicklungsprozess eher wenige Optimierungen erfordert als ein schlecht durchdachter Prozess. Und es gibt andere, die glauben, dass nicht alle verfrühten Optimierungen schlecht sind. Beide Denkansätze haben durchaus ihre Berechtigung. Denken Sie darüber nach Einige der Faktoren, die den Entwicklungsaufwand bei der Durchführung verfrühter Optimierungen beeinflussen, sind die folgenden.

• Welche Entwicklungsmethodik verfolgen Sie? Sind Sie agil? Oder sind Sie eher ein Unternehmen, das nach dem Wasserfallprinzip arbeitet? Sie werden vielleicht nicht zustimmen, aber auch diese Information ist wichtig, wenn Sie Entscheidungen über Optimierungen treffen, ob sie verfrüht sind oder nicht.
• Sind Sie ein Anwendungsentwicklungsteam oder entwickeln Sie Produkte? Die Kosten-Nutzen-Analyse ist ein Muss, bevor Sie entscheiden, ob Sie sich Optimierungen leisten können, und zwar in mehr als einer Hinsicht.
• Braucht diese Methode wirklich so viele Parameter? Sicherlich kann sie umgeschrieben werden. Sie müssen darüber nachdenken, welche Vorteile Ihnen die Optimierung dieses Teils des Codes bringt, wenn überhaupt. Vorteile wie eine kürzere Verarbeitungszeit oder eine Verringerung der Abhängigkeiten sind wichtig, aber diese Änderungen müssen genehmigt und geplant werden.
• Welche anderen Methoden sind von dieser Berechnung abhängig? Für jedes Stück Code, das Sie ändern, müssen Sie möglicherweise viele Module erneut testen. Das bedeutet wiederum Zeit und Aufwand.
• Der wichtigste Punkt von allen ist, wer für die geleistete Arbeit bezahlen wird.

Dies sind nicht die einzigen Faktoren, wie sich Optimierungen auf die Entwicklung auswirken. Es gibt bestimmte Situationen, in denen die Optimierung der Abfrage oder der Schnittstelle durchaus sinnvoll ist. Die Frage, die Sie sich stellen sollten, ist, ob die Optimierung wirklich dem Endprodukt zugute kommt oder ob Sie sie nur einbauen wollen, um Ihren Code schicker aussehen zu lassen. Hüten Sie sich vor den Fallstricken Im Wasserfallverfahren werden alle Anforderungen definiert und Entwicklungspläne weit im Voraus erstellt. Der Spielraum für die Einführung von Optimierungen in einem späteren Entwicklungsstadium ist nicht festgelegt. Das Hauptaugenmerk liegt vielmehr darauf, die Entwicklung abzuschließen, ohne dabei die Qualität so weit wie möglich zu beeinträchtigen. In solchen Fällen drängen viele Kunden nicht auf Optimierungen, da sie nur daran denken, die Software in die Hände zu bekommen, die ihr Unternehmen voranbringen würde.

Bei Agile hingegen wird die Planung auf der Basis von Sprints vorgenommen. Der Umfang der Einführung von Optimierungen für ein bestimmtes Modul kann also in den kommenden Sprints geplant werden. Das gibt Ihnen einen gewissen Spielraum, um die Abhängigkeiten und Auswirkungen der Optimierungen zu verstehen und zu planen. Mögliche Lösungen Ganz gleich, welche Methodik Sie anwenden oder welche Art von Software Sie entwickeln, Ihr Team von Architekten, Beratern und Entwicklern ist Ihre beste Chance, optimale Ergebnisse zu erzielen. Die Erfahrung, die sie einzeln und gemeinsam besitzen, trägt dazu bei, die Software zu erstellen, die Ihre Kunden nutzen werden. Diese Erfahrung kommt Ihnen bei der Umsetzung der Qualitätsstandards Ihres Unternehmens zugute.

• Setzen Sie gute Entwicklungspraktiken durch: Es gibt bestimmte dokumentierte Entwicklungspraktiken, die verwendet werden können, um ein kompetentes Stück Software zu schreiben. Die Bedingungen, die definieren, was ein gutes Stück Software ist, liegen also letztlich in den Standards Ihres Unternehmens. Die Standards müssen eindeutige Bestimmungen darüber enthalten, welche Art von Optimierungen in welchem Stadium des Entwicklungszyklus akzeptabel sind.
• Lassen Sie Raum für Überraschungen: Durch die Verwendung oder Kombination verschiedener Managementmethoden können Sie Entwicklungs- und Überprüfungsprozesse schaffen, die Ihnen Raum für Änderungen an Ihrem Code geben. Wie spät oder früh diese Optimierungen vorgenommen werden können, muss eingeplant werden.
• Sprechen Sie mit Ihren Kunden: Vergessen Sie nicht, dass auch Ihre Kunden ein Mitspracherecht bei der Umsetzung solcher Optimierungen haben. Da sie es sind, die letztendlich für die Entwicklung bezahlen, würden sie in bestimmten Situationen oder Entwicklungsstadien keine Optimierungen bevorzugen, wenn sie nur ein funktionell einwandfreies Produkt wollen. Auch hier müssen Sie sich mit Ihren Kunden gut verständigen, ob sie überhaupt bereit sind, Optimierungen vorzunehmen und wenn ja, in welchem Stadium der Entwicklung. Dies gilt insbesondere für Anwendungsentwicklungsteams, unabhängig vom Entwicklungsprozess oder der angewandten Methodik.

Wenn Sie das vollständige Zitat von Donald Knuth lesen, stellt er fest, dass "Wir sollten kleine Effizienzgewinne vergessen, sagen wir in etwa 97% der Fälle: verfrühte Optimierung ist die Wurzel allen Übels. Dennoch sollten wir unsere Chancen in diesen kritischen 3% nicht verpassen. " Damit ist gemeint, dass Sie nicht optimieren sollten, weil Sie glauben, dass es einen Leistungsschub gibt, sondern dass Sie optimieren sollten, wenn Sie den Leistungsgewinn tatsächlich messen können. [contact-form-7 id="21011" title="Der 3-Schritte-Prozess zur drastischen Verbesserung des ROI Ihrer Softwareentwicklung"]