Kunstfertigkeit, Praxis oder Fortpflanzung?

In den letzten Jahren wurde viel über die Qualität von Software geredet. Programmierer haben sich emanzipiert und sich zu Software-Handwerkern entwickelt. Es wurden Metriken definiert und verfeinert, um die Qualität des Codes und der zu liefernden Artefakte zu messen. Immer mehr unserer Kunden bitten um Unterstützung bei der Erreichung immer höherer Qualitätsziele. Die Diskussion über Software-Handwerk ist nicht nur positiv. Viele Entwickler, mit denen ich zusammengearbeitet habe, haben das Gefühl, dass bestimmte Qualitätsniveaus nur von der persönlichen Befriedigung der Handwerker angetrieben werden und nicht mit den wirtschaftlichen Realitäten unserer Branche übereinstimmen. In diesem Artikel bemühe ich mich, Richtlinien für den Kompromiss zwischen Qualität und Geschwindigkeit aufzustellen. Ich halte es für gerechtfertigt, nuancierter vorzugehen als mit der simplen Aussage: "Schnell gehen durch gut gehen". Das liegt daran, dass "gut" in verschiedenen Kontexten unterschiedliche Dinge bedeuten kann. Ich suche nach einer Grenze zwischen der Verbesserung der Qualität zur Verbesserung der Fortpflanzung und der Verbesserung der Qualität aus reinem Eigennutz.

Die Bedeutung von Qualität

Jeder Entwickler mit etwas Erfahrung weiß intuitiv, wie wichtig Qualität ist. Code zu lesen und zu ändern ist schwieriger als ihn zu schreiben. Wenn Sie schon einmal Code von suboptimaler Qualität ändern mussten, kennen Sie das Gefühl: Hätte man sich bei der Entwicklung dieses Codes nur ein bisschen mehr Gedanken gemacht, hätte man sich so viel Kopfzerbrechen ersparen können. Die Qualität von Code wird im Wesentlichen durch drei Attribute definiert:

• Ist es einfach
• Ist es einfach zu ändern
• Ist es einfach zu testen

Ich habe viele verschiedene Entwickler gebeten, die Eigenschaften von qualitativ hochwertigem Code aufzulisten, und diese drei wichtigsten waren das Ergebnis. Wenn Sie darüber nachdenken, ist es eigentlich ganz offensichtlich. Immer, wenn Sie sich den Code ansehen, sind Sie entweder dabei, um ein Problem zu beheben oder um eine Änderung zu implementieren. Die Zeit, die Sie dafür aufwenden müssen, hängt stark von diesen drei Faktoren ab.

Wann ist Qualität hoch genug?

Bis jetzt haben wir nur qualitative Attribute gesehen. Das ist aus zwei Gründen unbefriedigend. Erstens mangelt es an wissenschaftlichem Wert. Wir haben nichts Messbares, also müssen alle Aussagen über Qualität subjektiv sein. Zweitens gibt es keine Möglichkeit, qualitative Ergebnisse wie die Betriebskosten im Verhältnis zur Qualität vorherzusagen. Es hat viele Versuche gegeben, dieses Problem zu lösen. Es gibt komplizierte Metriken wie zyklomatische Komplexität, Testabdeckung, Verflechtung und dergleichen mehr. Alle diese Metriken wurden manipuliert und missbraucht. Zurzeit gibt es keine Möglichkeit, diese Metriken mit den Kosten für die Änderung der Software in Verbindung zu bringen. Tut mir leid.Das einzige, was wir haben, sind Schätzungen von menschlichen Entwicklern. Wie unwissenschaftlich! Schätzungen eignen sich gut für Kostenvorhersagen in agilen Prozessen, also können wir sie vielleicht trotzdem verwenden. Auch wenn wir keine nützlichen quantitativen Maßstäbe für die Qualität haben, heißt das nicht, dass wir völlig im Dunkeln tappen. Wir haben qualitative Beziehungen, an denen wir uns orientieren können, um zu entscheiden, welches Maß an Qualität erforderlich ist. Wir können sie mit Hilfe von Schätzungen quantifizieren. Es gibt drei Variablen, die die optimale Qualität steuern: - der Anteil der Zeit, die für das Lesen der Software im Vergleich zum Schreiben aufgewendet wird. - die durchschnittlichen Kosten eines Fehlers - die Anzahl der erwarteten Änderungen In einem standardmäßigen (agilen) Prozess schätzen wir normalerweise nur die Kosten für die Implementierung einer Änderung. Wir schätzen das Risiko der Änderung oft nicht ab. Wir schätzen auch nicht die Änderung und ihr Risiko nach einem theoretischen Refactoring, das wir vornehmen könnten. Würden wir dies tun, hätten wir viel mehr Einblick in die Kosten, die entstehen, wenn wir keine Qualitätsverbesserungen vornehmen.

Investieren Sie nur, wenn Sie eine Rendite erwarten

Da sich die Industrie langsam auf die agile Methode umstellt, wird es zur gängigen Praxis, nur die Funktionen zu implementieren, die nach einer Schätzung einen größeren Mehrwert als ihre Kosten zu bringen scheinen. Dies lässt sich auch auf Qualitätsverbesserungen anwenden. Zunächst schätzen Sie den Aufwand für eine bestimmte Qualitätsverbesserung. Dann schätzen Sie die Reduzierung des Aufwands für die verbleibenden Funktionen, wenn die Verbesserung durchgeführt würde, und die Reduzierung des Fehlerrisikos. So erhalten Sie ein Ergebnis für einen Break-Even-Punkt in der Zukunft. So erhalten Sie ein konkretes Argument dafür, ob Sie die Verbesserung durchführen oder nicht. Sie können dies dann mit demjenigen, der die Rechnungen bezahlt, in einem Vokabular diskutieren, das er sehr gut versteht.

Ist es schlecht, den Code nur zum Üben zu polieren?

Es gibt eine Zeit und einen Ort zum Üben. Wenn Sie nicht üben, werden Sie nie gut werden. Es spricht nichts dagegen, den Code aufzupolieren und hier und da ein paar fragwürdige Zeilen zu entfernen. Einfach weil Sie es können. Es ist jedoch nicht unser gottgegebenes Recht, den Code zu polieren, bis wir zum Crescendo aufsteigen. Oft höre ich Beschwerden von Entwicklern wie: "Wir haben nie Zeit für das Refactoring, deshalb sieht unser Code so aus." Und oft höre ich als Antwort darauf: "Sie sollten sich diese Zeit einfach nehmen, denn es ist Ihre Aufgabe als Handwerker, qualitativ hochwertigen Code zu erstellen." Die Zeit, die wir für den Feinschliff aufwenden, ist nicht umsonst. Wir sollten nach einem intelligenten Kompromiss suchen, das ist unsere Aufgabe.

Ist da noch Platz für echte Handwerkskunst oder sollten wir alle nur hacken?

Bei Facebook werden die Entwickler zum HACKEN angehalten. Sie sind sehr erfolgreich. Daher glaube ich, dass es in einem bestimmten Kontext keinen Sinn macht, Stunden damit zu verbringen, bestehenden Code zu polieren. Es zum Laufen zu bringen und den Quellcode zu verdammen ist eine großartige Strategie, und zwar an viel mehr Stellen, als Sie vielleicht denken. Aber Facebook stellt keine Flugzeugleitsysteme her. Oder Handelssysteme. Oder Routenplaner. Wenn Sie etwas herstellen, von dem die Menschen beim Einkaufen, Reisen, Einkommen oder sogar in ihrem Leben abhängig sind, tragen Sie eine größere Verantwortung dafür, dass es nicht kaputt geht. Aber es gibt eine große Grauzone zwischen Hacking und handwerklichem Eifer. Finden Sie heraus, welche Kräfte die Betriebskosten in Ihrem Umfeld bestimmen, und nutzen Sie sie, um Qualitätsverbesserungen zu priorisieren, wenn sie tatsächlich sinnvoll sind. Und üben Sie natürlich, wenn Sie die Zeit dazu finden. Nur Übung macht den Meister! Ich bin sehr an Experimenten interessiert, die Sie durchgeführt haben, um die Kosten und den Nutzen von Qualitätsverbesserungen sichtbar zu machen. Schicken Sie mir einen Link oder einen Kommentar, wenn Sie etwas zu berichten haben.