Gibt es eine Fallstudie, die überzeugend belegt, dass sauberer Code die Entwicklung verbessert hat? [geschlossen]

Ich bin in meinem ersten richtigen Job als Programmierer und sehe nur den "Big Ball of Mud" -Code (auch ohne nützliche Kommentare), aber ich mache gerne sauberen Code, und es fällt mir wirklich schwer, schlechter zu programmieren Weg.

Ich suche nach einem Studienfall, in dem die Verwendung von sauberem Code (ich sehe hier verschiedene Definitionen dessen, was sauberer Code ist) die Entwicklung und Wartbarkeit verbessert hat.

Bei einer schnellen (aber keineswegs vollständigen) Suche in Google Scholar werden zahlreiche Artikel gefunden, die sich auf Bob Martins Clean Code beziehen , aber ich persönlich habe keine gesehen, die eine Korrelation zwischen "Clean Code" und verbesserter Entwicklung behandeln.

Denken Sie jedoch einen Moment über Ihre Frage nach. Sie fragen nach einer verbesserten Entwicklung, und das ist an sich ein sehr breites Themengebiet, das nicht nur durch das Schreiben von besserem Code abgedeckt wird, sondern auch durch viele andere Faktoren wie Kommunikation, das Verwalten von Erwartungen, Methodik und Straffung von Prozessen, Testen, kontinuierliche Integration und vieles mehr die ganze Schachtel und Würfel, wenn Sie überlegen, wie viele Dinge zum Erfolg eines Softwareentwicklungsprojekts beitragen, geschweige denn, es zu verbessern.

Ihre Frage sollte also wahrscheinlich lauten: Trägt das Schreiben von sauberem Code zur Verbesserung der Softwareentwicklung bei? Um das zu beantworten, wäre der einzige "Beweis", den ich vorlegen könnte, völlig anekdotisch, und dafür wäre das Clean Code- Buch meiner Meinung nach eine ausgezeichnete Referenz, da es nicht nur von Bob Martin selbst geschrieben wurde, sondern auch viele Kapitel enthält von einigen der intelligentesten Softwareentwickler da draußen. Wenn das nicht hilft, könnte vielleicht ein wenig kalte harte Logik zutreffen.

Wenn Sie ein Chaos in Ihrem Haus anrichten und es nie sauber machen, wird das Leben in Ihrem Haus zur lästigen Pflicht. Es wird schwieriger, Dinge zu finden, sich zu bewegen, und niemand, der bei Verstand ist, wird Sie besuchen wollen, wenn Sie in einer schmutzigen Umgebung leben. Das selbe auch mit Code. Wenn Ihr Code ein Chaos ist, finden Sie es schwieriger, Probleme zu lokalisieren, geschweige denn, sie zu beheben. Es wird einfacher, einen Workaround zu rechtfertigen, der möglicherweise nicht die Arbeit leistet, aber hey, es ist sicher besser, als sich durch den ganzen alten Legacy-Mist wühlen zu müssen, oder? Am Ende kostet es Sie Zeit und Mühe, Ihren Code unordentlich zu machen, so wie Sie es nie getan haben, und auf lange Sicht hat es Ihnen Schwierigkeiten bereitet. Wenn Sie jedoch Ihren Code sauber halten, erhalten Sie eine bessere Plattform, auf der Sie arbeiten und Refactoring und Debugging einfacher gestalten können.

Nein, ich habe keine direkten Beweise, und das sind nur die Gedanken von jemandem, der dieses Zeug schon sehr lange gemacht hat und hoffentlich ein wenig Erfahrung in der Softwareentwicklung gesammelt hat . :-)

Was Sie verstehen müssen, ist, dass sich kein Unternehmen daran macht, mittelmäßigen Code zu schreiben. Das Problem ist, dass 50% des Codes (Geben oder Nehmen) von den unterdurchschnittlichen Programmierern Ihres Unternehmens geschrieben werden. Sie predigen vor dem Chor, wenn Sie die Vorteile von sauberem Code erläutern. Der Trick ist, wie es geht. Recherchieren Sie zu Themen wie Peer-Review-Tools, statischen Analysen, automatisierten Tests, kontinuierlicher Integration, TDD, Scrum, extremer Programmierung usw. und stellen Sie mögliche Lösungen vor, anstatt nur zu erklären, warum das Problem so schlimm ist.

Ich weiß, dass dies hier gegen den Strich geht, aber die Zeit bis zur Markteinführung, die richtigen Anforderungen, die richtige Finanzierung, ein gutes Marketing, der richtige Preis und ganz einfach viel mehr Einfluss auf den Erfolg eines Softwareprodukts als auf die Codequalität.

Dies bedeutet NICHT , dass die Codequalität ignoriert werden sollte, aber Sie sollten anerkennen, dass dies nur einer von vielen Faktoren ist.

Es gibt viele Beispiele für schrecklichen Code in äußerst erfolgreichen Produkten (z. B. das ursprüngliche Apple-Betriebssystem, das das Thread-Management den Anwendungen überließ).

Ich kann mir keine Beispiele für schönen Code vorstellen, der ein schlecht konzipiertes oder überteuertes Produkt überwindet.

Wenn es also Zeit für die Vermarktung im Vergleich zu hübschem Code gibt, sollte die Zeit für die Vermarktung Vorrang haben!

Sie müssen sauberen Code von den eigentlichen Zielen trennen: Reduzierung der Kosten für die Behebung von Fehlern nach der Bereitstellung und Reduzierung unnötiger Nacharbeiten. Wenn Sie davon sprechen, "sauberen Code zu schreiben, um weniger Fehler zu verursachen", dann sprechen Sie von Religion. Wenn Sie über die Reduzierung der Fehlerrate um 10% sprechen, um 2 Mannmonate Projektaufwand zu sparen, dann sprechen Sie über Management. Sauberer Code ist ein Werkzeug, um die ursprüngliche Qualität der Codebasis zu verbessern und dadurch die Gesamtkosten zu senken, aber es ist eines von vielen.

In folgendem Artikel wird erläutert, warum es aus Kostengründen wichtig ist, das Problem beim ersten Mal zu beheben: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Mir ist keine spezifische Studie bekannt, aber ich schaue mir die Arbeit von Steve McConnell an .

Wenn jemand es hat, wird er es tun. Zum Beispiel zwei Minuten Scan gefunden dieses (16 Jahre alt , aber immer noch relevant heute).

Um die Antwort von mattnz zu ergänzen, wenn Sie es noch nicht getan haben, sollten Sie sich Code Complete: A Practical Handbook of Software Construction von Steve McConnell genauer ansehen . Neben der Tatsache, dass es wahrscheinlich Ihre Codierung verbessern wird, zitiert er im gesamten Buch zahlreiche Studien darüber, wie sich verschiedene Codierungsmethoden auf die Qualität von Programmen auswirken.

Als Beispiel (aus dem Buch):

Eine weitere Studie mit 450 verschiedenen Routinen (was nur ein ungewöhnlicher Zufall ist) ergab, dass Routinen mit den höchsten Kopplungs-Kohäsions-Verhältnissen 7-mal so viele Fehler aufwiesen wie solche mit den niedrigsten Kopplungs-Kohäsions-Verhältnissen und 20-mal so teuer waren zu beheben (Selby und Basili 1991).

Es war auch die Antwort Nummer eins auf die Frage: Was ist das einflussreichste Buch, das jeder Programmierer lesen sollte? (obwohl ich sehe, dass die Antworten auf diese Frage vor kurzem lahm reorganisiert wurden)