Ist hochwertige Software die Kosten ihrer Entwicklung wert?

Bei der Implementierung von Projekten stehen Teams häufig vor der Frage: Worauf sollte mehr geachtet werden - auf die Veröffentlichung neuer Funktionen oder auf die Verbesserung der Codequalität? In der Regel entscheiden sich Manager für Funktionen. Oft sind Entwickler mit diesem Zustand unzufrieden und glauben, dass sie nicht genug Zeit haben, um an der Architektur und Qualität des Codes zu arbeiten.

Das Gesetz von Betterridge besagt: "Jede Überschrift, die mit einem Fragezeichen endet, kann mit dem Wort" Nein "beantwortet werden." Diejenigen, die mich persönlich kennen, wissen, dass ich diesen Gedanken nicht teile. Aber in diesem Artikel möchte ich noch weiter gehen und beweisen, dass es einfach keinen Sinn macht, die Frage aus dem Titel dieses Artikels zu stellen. Eine solche Formulierung der Frage legt nahe, dass es einen Kompromiss zwischen Kosten und Qualität gibt. Und Sie müssen ständig das Gleichgewicht halten. In diesem Artikel werde ich beweisen, dass dieser Kompromiss nicht auf die Welt der Entwicklung von Computersystemen anwendbar ist und dass die Erstellung hochwertiger Software letztendlich billiger ist.

Trotz der Tatsache, dass die Hauptzielgruppe des Artikels Entwickler sind, sind keine besonderen Kenntnisse erforderlich, um ihn zu verstehen. Ich möchte, dass dieser Artikel allen zugute kommt, die in irgendeiner Weise mit dem Entwicklungsprozess verbunden sind, insbesondere den Managern, die den Produktentwicklungsvektor bilden.

Wir sind es gewohnt, zwischen Preis und Qualität zu wählen.

Wie ich bereits geschrieben habe, muss man bei der Entwicklung von Software ständig zwischen der Qualität des Produkts und den Kosten seiner Entwicklung wählen. Wenn Sie ein neues Smartphone kaufen, haben Sie die Wahl. Zahlen Sie mehr Geld und erhalten Sie einen schnelleren Prozessor, mehr Speicher und einen verbesserten Bildschirm oder zahlen Sie weniger, aber opfern Sie einige Funktionen. Es gibt Ausnahmen von dieser Regel: Manchmal ist ein Produkt mit höherer Qualität billiger. Und manchmal können Menschen zwei Produkte nicht einmal objektiv vergleichen und ein besseres auswählen. Zum Beispiel bemerken sie nicht den Unterschied zwischen Bildschirmen, die mit völlig unterschiedlichen Technologien hergestellt werden. Die Aussage „Hohe Qualität ist teurer“ trifft jedoch in der Regel zu.

Bei der Softwarequalität geht es um viel.

Wenn Sie über Softwarequalität sprechen, sollten Sie zunächst Qualitätskriterien definieren. Was ist Qualitätssoftware? Von diesem Moment an werden die Dinge etwas komplizierter, da jedes Computersystem viele Kriterien hat, anhand derer seine Qualität bewertet werden kann. Sie können UI und UX bewerten: Wie schnell und einfach kann ein Benutzer sein Problem lösen? Die Zuverlässigkeit kann beurteilt werden: Gibt es Fehler im Programm, die zu falschem und instabilem Verhalten führen? Ein weiteres Kriterium ist die Architektur: Wie strukturiert ist der Quellcode des Programms, wie einfach und schnell kann der Programmierer den Code finden, den er gerade benötigt?

Die obige Liste der Qualitätskriterien ist natürlich nicht vollständig. Diese Kriterien reichen jedoch aus, um eine wichtige Sache aufzuzeigen. Einige Kriterien, anhand derer die Qualität eines Programms normalerweise bewertet wird, sind für Endbenutzer nicht einmal sichtbar. Kunden können Feedback geben und feststellen, wie gut die Software ihre geschäftlichen Probleme löst. Benutzer können sich über die unbequeme Oberfläche beschweren. Oder sie beschweren sich über Fehler, insbesondere wenn sie zu Datenverlust oder längerer Nichtverfügbarkeit des Systems führen. Benutzer können die Architektur und Qualität des Codes jedoch nicht einschätzen.

Daher teile ich die Qualitätskriterien in zwei Kategorien ein: extern (z. B. UI / UX oder Vorhandensein von Fehlern) und intern (Architektur). Ihr wichtigster Unterschied besteht darin, dass Benutzer die externe Qualität bewerten können, aber nicht verstehen können, wie gut (oder schlecht) die interne Architektur des Systems ist.

Auf den ersten Blick spielt die interne Qualität für die Benutzer keine Rolle (sondern nur auf den ersten Blick).

Wenn Benutzer die interne Qualität der Software nicht bewerten können, ist dieses Kriterium wichtig? Stellen wir uns eine hypothetische Situation vor, in der zwei Entwicklungsteams unabhängig voneinander beschlossen, eine Anwendung zur Verfolgung und Vorhersage von Flugverspätungen zu erstellen. Ich leite ein Team und Rebecca führt das zweite. Die Grundfunktionen für die Anwendungen sind ungefähr gleich. Die Benutzeroberfläche für beide Anwendungen hat sich ebenfalls als sehr praktisch und durchdacht herausgestellt. Es gibt keine kritischen Fehler in den Anwendungen. Der einzige Unterschied besteht darin, dass der Quellcode der Anwendung von Rebecca klar strukturiert und organisiert ist und der von meinem Team erstellte Code eine unordentliche Reihe von Klassen und Methoden mit undurchsichtigen Namen und einer noch undurchsichtigeren Logik für die Verbindung dieses Codes ist. Es gibt noch einen weiteren Unterschied: Ich verkaufe meine Bewerbung für 6 US-Dollar und Rebecca verkauft fast dieselbe Bewerbung für 10 US-Dollar.

Da der Quellcode von Anwendungen für Benutzer nicht zugänglich ist und die Qualität des Codes keinen Einfluss auf die Benutzererfahrung hat, warum sollten Benutzer zusätzliche 4 US-Dollar zahlen? Mit anderen Worten - warum für interne Qualität zu viel bezahlen, was für Benutzer nicht wichtig ist?

Wenn Sie diese Idee weiterentwickeln, können Sie zu dem Schluss kommen, dass Investitionen in externe Qualität rentabler sind als in interne. Wenn der Benutzer zwischen zwei Anwendungen wählt, kann er diejenige auswählen, die teurer ist, wenn er eine bessere und bequemere Benutzeroberfläche hat. Benutzer sehen jedoch nicht die interne Struktur der Anwendungen, ganz zu schweigen von der Tatsache, dass der Benutzer die Architektur der beiden Anwendungen vergleichen kann. Warum also mehr für etwas bezahlen, das keine praktischen Vorteile bringt? Und warum sollten Entwickler Zeit und Ressourcen investieren, um die interne Qualität ihrer Programme zu verbessern?

Programme mit hoher interner Qualität lassen sich leichter erweitern

Warum ist es für Programmierer so wichtig, Qualitätscode zu haben? Programmierer verbringen die meiste Zeit damit, es zu lesen und zu bearbeiten. Selbst bei der Entwicklung eines neuen Systems wird fast immer im Kontext von bereits geschriebenem Code gearbeitet. Wenn ein Programmierer eine neue Funktion hinzufügt, muss er zunächst herausfinden, wie diese Funktion in die vorhandene Anwendungsarchitektur passt. Dann müssen Sie häufig Änderungen an der Architektur vornehmen, damit eine neue Funktion implementiert werden kann. Oft müssen Sie Datenstrukturen verwenden, die sich bereits im System befinden. Daher müssen Sie verstehen, dass diese Datenstrukturen bedeuten, welche Art von Beziehungen zwischen ihnen bestehen und welche neuen Datenstrukturen hinzugefügt werden müssen, um Funktionen zu implementieren.

Dank des hochwertigen Codes können Programmierer schnell darin navigieren. Es ist eigentlich sehr einfach, eine Situation zu erreichen, in der der Code schwer zu verstehen ist. Logische Bedingungen können miteinander verflochten sein, Beziehungen zwischen Datenstrukturen können komplex und implizit sein. Die Namen, die Tony vor 6 Monaten Variablen und Funktionen gegeben hat, waren ihm vielleicht klar, aber auch für den neuen Entwickler unverständlich, sowie die Motive, die Tony dazu veranlassten, das Unternehmen zu verlassen. Entwickler nennen dies normalerweise „technische Schulden“ ( technische Schulden ) oder mit anderen Worten den Unterschied zwischen dem aktuellen Status des Codes und dem idealen Status, in dem er sich befinden kann.

Einer der Hauptvorteile der hohen Codequalität besteht darin, dass der Programmierer schnell verstehen kann, wie das System funktioniert, und die erforderlichen Änderungen vornehmen kann. Wenn die Anwendung in Module unterteilt ist, muss der Programmierer nicht alle 500.000 Zeilen Quellcode studieren und kann schnell die Hunderte von Zeilen finden, die er gerade benötigt. Wenn Programmierer Variablen, Funktionen und Klassen aussagekräftige Namen geben, können Sie leicht verstehen, was jeder einzelne Code tut, ohne sich eingehend mit dem Kontext befassen zu müssen. Wenn die Datenstrukturen im Programm mit der Terminologie aus der Domänendomäne des Unternehmens übereinstimmen, kann der Programmierer die Anforderung neuer Funktionen leicht mit der Funktionsweise des Systems korrelieren. Die technische Verschuldung erhöht auch die Zeit, die für die Arbeit mit dem Code benötigt wird. Die Wahrscheinlichkeit, einen Fehler zu machen, steigt ebenfalls. Im Falle von Fehlern aufgrund der schlechten Qualität des Codes wird zusätzliche Zeit benötigt, um das Problem zu lokalisieren und zu beheben. Und wenn der Fehler nicht sofort bemerkt wird, führt dies zu Problemen im Produktionscode und der Tatsache, dass Sie in Zukunft noch mehr Zeit damit verbringen müssen, diese Probleme zu beheben.

Jede Änderung des Codes wirkt sich auf die Zukunft des Produkts aus. Oft gibt es eine Situation, in der es eine einfache und schnelle Möglichkeit gibt, eine neue Funktion zu implementieren, jedoch auf Kosten des Bruchs der aktuellen Architektur (d. H. Aufgrund einer Zunahme der technischen Verschuldung). Wenn ein Programmierer diesen Pfad wählt, gibt er seine Funktion schneller frei, verlangsamt jedoch die Arbeit anderer Entwickler, die diesen Code später unterstützen müssen. Wenn jeder im Team dies tut, wird selbst eine gut gestaltete Anwendung mit gutem Code schnell zu technischen Schulden, und selbst einige Änderungen werden mehrere Wochen dauern.

Benutzer möchten so schnell wie möglich neue Funktionen erhalten.

Wir nähern uns einem wichtigen Punkt, nämlich: Um die Frage zu beantworten, warum ist die interne Qualität von Software für Benutzer immer noch wichtig? Hohe interne Qualität fördert die schnellere Veröffentlichung neuer Funktionen, da diese einfacher, schneller und billiger durchzuführen sind. Meine Bewerbungen bei Rebecca sehen jetzt fast gleich aus, aber nach ein paar Monaten wird der hochwertige Code von Rebecca es ihr ermöglichen, jede Woche eine neue Funktion zu veröffentlichen, und ich werde an Ort und Stelle bleiben, versuchen, mit den technischen Schulden fertig zu werden und mindestens eine neue Funktion zu starten. Ich werde nicht in der Lage sein, mit Rebecca in Bezug auf die Entwicklungsgeschwindigkeit zu konkurrieren, und ihre Anwendung wird meine in Bezug auf Funktionalität schnell überholen. Letztendlich werden Benutzer meine Anwendung löschen und die Rebecca-Anwendung verwenden, obwohl sie mehr kostet.

Visualisierung des Einflusses der internen Qualität

Der Hauptvorteil der hohen internen Qualität des Programms ist die Reduzierung der Kosten für zukünftige Änderungen. Das Schreiben von qualitativ hochwertigem Code erfordert jedoch mehr Aufwand, und dies erhöht kurzfristig die erforderlichen Ressourcen.

Die folgende Grafik zeigt schematisch, wie Sie sich das Verhältnis der Funktionalität und die Zeit vorstellen können, die für die Entwicklung erforderlich ist. Normalerweise sieht eine Kurve ungefähr so ​​aus:


So sieht der Entwicklungsprozess aus, wenn der Code keine sehr hohe Qualität aufweist. Die Entwicklung ist zunächst schnell genug, aber dann wird immer mehr Zeit benötigt, um die Funktionalität weiter zu erweitern. Zu einem bestimmten Zeitpunkt muss der Programmierer zunächst viel komplexen und verwirrenden Code lernen, um auch nur eine kleine Änderung vorzunehmen. Nachdem die Änderung vorgenommen wurde, wird festgestellt, dass ein Fehler aufgetreten ist. Dies führt zu zusätzlichem Zeitaufwand für das Testen und Beheben von Fehlern.

Eine hohe interne Qualität trägt in späteren Phasen zur Entwicklungseffizienz bei. Einige Teams erzielen sogar den gegenteiligen Effekt, wenn jede neue Funktion schneller als die vorherige veröffentlicht wird, da bereits geschriebener Code wiederverwendet werden kann. Dies kommt jedoch nur selten vor, da ein hochprofessionelles Team mit einer guten Arbeitsorganisation erforderlich ist. Aber manchmal passiert das immer noch.


Es gibt jedoch einen Trick. In der Anfangsphase der Entwicklung ist das Ignorieren der Codequalität effektiver als das Befolgen hoher Standards. Aber wann endet diese Periode?

Um diese Frage zu beantworten, müssen Sie zunächst klarstellen, dass die Bilder Pseudografien darstellen . Es gibt keinen wirklichen Weg, um die Teamleistung zu bewerten. Es ist nicht leicht zu verstehen, wie sich schlechter Code auf die endgültige Qualität des Produkts auswirkt (und wenn diese Korrelation besteht, wie ausgeprägt sie ist). Dieses Problem ist übrigens nicht nur für die IT-Branche relevant. Wie kann man zum Beispiel die Qualität der Arbeit eines Anwalts oder Arztes bewerten?

Zurück zur Frage: Ab wann lohnt es sich, über die Qualität des Codes nachzudenken? Erfahrene Entwickler glauben, dass sich die schlechte Codequalität innerhalb weniger Wochen nach Projektstart verlangsamt. In einem frühen Stadium des Projekts kann die Schönheit von Architektur und Code ignoriert werden.

Aus eigener Erfahrung kann ich auch sagen, dass selbst kleine Projekte einen ernsthaften Wettbewerbsvorteil erzielen, wenn sie moderne und effektive Entwicklungspraktiken in ihrer Arbeit anwenden und über die Qualität des Codes nachdenken.

Selbst die besten Teams schreiben manchmal schlechten Code

Diejenigen, die neu im Entwicklungsprozess sind, glauben, dass schlechter Code darauf hinweist, dass das Team nicht gut arbeitet. Aber wie die Praxis zeigt, machen selbst die erfahrensten Teams manchmal Fehler und schreiben schlechten Code.

Um dies klar zu demonstrieren, möchte ich Ihnen von einem Gespräch mit einem unserer besten Teamleiter erzählen. In diesem Moment hatte er gerade die Arbeit an einem Projekt beendet, das alle für sehr erfolgreich hielten. Der Kunde war von dem neuen System sowohl von den neuen Funktionen als auch von den Ressourcen, die für seine Entwicklung aufgewendet wurden, begeistert. Das Team war auch mit dem abgeschlossenen Projekt zufrieden. Der technische Leiter des Teams war ebenfalls sehr zufrieden mit dem Ergebnis, gab jedoch zu, dass die Systemarchitektur tatsächlich nicht so erfolgreich war. Ich fragte ihn: "Aber wie kommt es, dass Sie einer unserer besten Architekten sind?" Er antwortete, wie jeder erfahrene Architekt geantwortet hätte: „Wir haben gute Entscheidungen getroffen, aber erst jetzt verstehen wir, wie man es richtig macht.“

Viele Menschen vergleichen die Schaffung komplexer Systeme mit dem Design von Wolkenkratzern. Anscheinend werden erfahrene Entwickler deshalb als "Architekten" bezeichnet. Bei der Erstellung von Software gibt es jedoch immer einige Unsicherheiten, die für andere Tätigkeitsbereiche untypisch sind, in denen die Unsicherheiten viel geringer sind. Typische Kunden haben ein schlechtes Verständnis dafür, was sie von dem Programm erwarten, und beginnen dies erst zu verstehen, wenn sie daran arbeiten. Meistens in dem Moment, in dem die ersten Versionen des Programms angezeigt werden. Die Elemente, aus denen Programme erstellt werden (Programmiersprachen, Bibliotheken, Plattformen), ändern sich alle paar Jahre. Können Sie sich eine Analogie zum Bau eines Wolkenkratzers vorstellen, in der ein Kunde einen Architekten auffordert, ein Dutzend weitere Stockwerke hinzuzufügen und das Layout der unteren zu ändern, obwohl die Hälfte des Gebäudes bereits gebaut ist? Die Situation wird noch komplizierter, wenn sich herausstellt, dass die zur Herstellung von Beton verwendeten Technologien, ihre physikalischen Eigenschaften und Eigenschaften alle zwei Jahre aktualisiert werden.

Angesichts ständig neuer Herausforderungen, der Zunahme ihrer Anzahl und Komplexität müssen sich die Teams ständig etwas Neues einfallen lassen. Zunehmend ist es notwendig, Probleme zu lösen, die noch niemand zuvor gelöst hat, und dementsprechend gibt es keine bekannte und bewährte Lösung für sie. Normalerweise kommt ein klares Verständnis des Problems erst zum Zeitpunkt seiner Lösung, daher höre ich oft die Meinung, dass das Verständnis, wie die Architektur eines komplexen Systems aussehen sollte, mindestens ein Jahr nach Arbeitsbeginn erfolgt. Und selbst das professionellste Entwicklungsteam der Welt wird das System nicht perfekt machen können.

Ein professionelles und organisiertes Team unterscheidet sich von einem weniger organisierten darin, dass es bei der Arbeit am System weniger technische Schulden verursacht und auch das vorhandene beseitigt. Dies hilft dem Projekt, sich schnell zu entwickeln und neue Funktionen so schnell wie möglich freizugeben. Ein solches Team investiert in die Erstellung automatisierter Tests, mit denen Probleme schneller erkannt und weniger Zeit für das Auffinden und Beheben von Fehlern aufgewendet werden können. Die Mitglieder eines solchen Teams arbeiten ständig daran, qualitativ hochwertigen Code beizubehalten und schlechten Code schnell zu beseitigen, bis er die weitere Entwicklung beeinträchtigt. Dazu tragen auch CI-Systeme bei, insbesondere in einer Situation, in der viele Menschen gleichzeitig an unterschiedlichen Aufgaben arbeiten. Als Metapher können Sie nach dem Kochen in die Küche bringen. Es ist unmöglich, etwas zu kochen, ohne den Tisch, das Geschirr und andere Küchenutensilien zu verschmutzen. Wenn Sie sie nicht sofort reinigen, trocknet der Schmutz aus und es ist viel schwieriger, ihn zu waschen. Und wenn Sie das nächste Mal etwas kochen möchten, wird es für Sie viel schwieriger, dies zu tun, da Sie zuerst den Berg des Geschirrs waschen müssen.

DevOps Forschung und Bewertung (DORA)

Der Kompromiss zwischen Kosten und Qualität ist nicht der einzige in der Welt der Softwareentwicklung, der auf den ersten Blick einfach erscheint, aber in der Praxis stellt sich heraus, dass alles etwas komplizierter ist. Es gibt auch eine breite Diskussion darüber, was am besten zu wählen ist - schnelle Entwicklungs- und Veröffentlichungsraten oder langsamere Raten und strenge Tests. Es wird angenommen, dass die Verwendung des zweiten Ansatzes eine höhere Stabilität von Produktionssystemen ermöglicht. Die DORA- Studie hat jedoch bewiesen, dass dies nicht der Fall ist.

Nachdem die Forscher über mehrere Jahre hinweg Statistiken gesammelt hatten, identifizierten sie, welche Praktiken zu einer höheren Teamleistung beitragen. Es stellte sich heraus, dass die effektivsten Teams den Produktionsserver mehrmals täglich aktualisieren und die Freigabe von Code ab dem Zeitpunkt der Veröffentlichung bis zur Veröffentlichung nicht länger als eine Stunde dauert. Wenn Sie diesen Ansatz befolgen, können Sie Änderungen an kleinen Teilen freigeben, und die Wahrscheinlichkeit schwerwiegender Schäden wird verringert. Teams, die laut Statistik seltener Veröffentlichungen veröffentlichen, haben mit vielen ernsthaften Problemen zu kämpfen. Außerdem können sich Teams, die an ein hohes Tempo gewöhnt sind, nach einem Absturz schneller erholen. Studien haben auch gezeigt, dass in solchen Teams Prozesse normalerweise besser aufeinander abgestimmt sind und organisierter funktionieren.

Die Unterstützung von Systemen mit einer guten Architektur ist billiger

Die wichtigsten Punkte aus dem, worüber wir oben gesprochen haben:

• Die mangelnde Beachtung der Codequalität führt zu einer Anhäufung technischer Schulden
• Technische Schulden verlangsamen die Systementwicklung
• Selbst professionelle Teams treffen manchmal schlechte Entscheidungen. Die Anwendung moderner Praktiken und die regelmäßige "Rückzahlung" technischer Schulden ermöglichen es Ihnen jedoch, diese unter Kontrolle zu halten
• Durch die Aufrechterhaltung einer hohen Codequalität wird die technische Verschuldung minimiert. Dies ermöglicht es, sich auf neue Funktionen zu konzentrieren und diese mit weniger Aufwand, schneller und billiger freizugeben.

Leider ist es für Entwickler normalerweise schwierig, dies dem Management zu erklären. Ich höre oft Beschwerden, dass das Handbuch es nicht ermöglicht, qualitativ hochwertigen Code beizubehalten, indem die für die Bearbeitung von Aufgaben vorgesehene Zeit begrenzt wird. Bei der Beantwortung von Managementfragen, warum zusätzliche Ressourcen für die Schönheit des Codes aufgewendet werden, antworten Entwickler normalerweise, dass dies ein Indikator für hohe Professionalität ist. Die Verwendung nur dieses Arguments bedeutet jedoch, dass zusätzliche Ressourcen für die Aufrechterhaltung einer hohen Qualität aufgewendet werden, die für andere Aufgaben verwendet werden könnten. Und das untergräbt das Argument für Professionalität. Die Wahrheit ist, dass aufgrund der schlechten Architekturqualität und des schlechten Codes das Leben für alle schwieriger wird: Es ist für Entwickler schwieriger, damit zu arbeiten, und für Kunden kostet es mehr. Bei der Erörterung der Qualität des Kodex mit dem Management fordere ich, dass er ausschließlich als wirtschaftlicher Indikator betrachtet wird. Wenn das Programm in hoher Qualität ausgeführt wird, ist es einfacher und billiger, neue Funktionen hinzuzufügen. Dies bedeutet, dass die Investition in das Schreiben von Qualitätscode letztendlich die Gesamtentwicklungskosten senkt.

Dies ist der wahre Grund, warum die Frage aus dem Titel des Artikels einfach keinen Sinn ergibt. Aus wirtschaftlicher Sicht ist es letztendlich rentabler, zusätzliche Ressourcen für Architektur und guten Code auszugeben. , , , . , . ( ). , .

---

. :

, , . – . . , . .