Wie kann man gegen die Senkung der Qualitätsstandards für ältere Codebasen argumentieren? [geschlossen]

28

Wir haben hier eine große alte Codebasis mit schlechtem Code, den Sie sich nicht vorstellen können.

Wir haben jetzt einige Qualitätsstandards definiert und möchten diese entweder in einer komplett neuen Codebasis erfüllen, aber auch, wenn Sie den alten Code berühren.

Und wir erzwingen diese mit Sonar (Code-Analyse-Tool), das bereits einige Tausend Verstöße aufweist.

Jetzt kam die Diskussion auf, um diese Verstöße für das Erbe zu verringern. Weil es Vermächtnis ist.

In der Diskussion geht es um Lesbarkeitsregeln. Wie viele verschachtelte ifs / for .. kann es haben.

Wie kann ich nun dagegen argumentieren, dass unsere Codierungsqualität bei Legacy-Code abnimmt?

keiki
quelle
2
ist die Diskussion über die Senkung der Schwellenwerte des Werkzeugs? ... oder habe ich es falsch verstanden. Es ist verwirrend geschrieben.
dagnelies
4
Die Frage hat einige sehr unklare Teile. "Diese Verstöße verringern" - Wollen Sie die tatsächliche Anzahl der Verstöße (durch Umschreiben des alten Codes), die Anzahl der von Sonar getesteten Regeln in der Legacy-Codebasis oder die Anzahl der Regeln Ihres Codierungsstandards, denen Sie folgen möchten, verringern beim Ändern von etwas im Legacy-Code?
Doc Brown
4
Wir haben auch ein Legacy-Produkt von schrecklicher Code-Qualität. Da es durch das neue Produkt ersetzt wird, ist es fast wertlos, diesen alten Code zu bereinigen. Das heißt: Wir akzeptieren einen niedrigeren Standard in der Legacy-Codebasis.
Bernhard Hiller
4
@keiki: immer noch unklar: Ist die neue Codebasis so weit getrennt, dass für den alten und den neuen Code unterschiedliche Validierungsregeln gelten? Was ist mit den Teilen, die Sie in der alten Codebasis ändern? Ist Ihr Problem, dass das Anheben der geänderten Teile auf den höheren Standard zu viel Aufwand verursacht, oder können Sie diese Teile nicht in der Sonar-Validierung trennen, damit nur diese geänderten Teile vollständig validiert werden können?
Doc Brown

Antworten:

73

Code ist nur ein Mittel zum Zweck. Was das Ziel sein mag, ist unterschiedlich, aber in der Regel ist es Gewinn.

Wenn es Profit ist; um dann erfolgreich zu argumentieren, dass alles, was Sie zeigen möchten, den Gewinn verbessert - z. B. durch Steigerung des Umsatzes, Reduzierung der Wartungskosten, Reduzierung der Entwicklungskosten, Senkung der Löhne, Reduzierung der Umschulungskosten usw. den Gewinn verbessern; dann sagst du meistens nur, es wäre eine lustige Art, Geld in die Toilette zu spülen.

Brendan
quelle
15
Ich glaube, es gibt eine andere Dimension in dieser Diskussion, die Professionalität ist. Wenn Ihr Chef Sie in vielen Berufen bittet, Abstriche zu machen, können Sie dies aus moralischen Gründen ablehnen (manchmal unterstützt Sie sogar das Gesetz) verstehen, warum Softwareentwickler sich anders verhalten sollten.
Alessandro Teruzzi
21
@AlessandroTeruzzi Sie können es aus (persönlichen) moralischen Gründen ablehnen, irgendwo etwas zu tun, unabhängig von der Professionalität. Garantiert jedoch nicht, dass Sie an diesem Ort weiterarbeiten.
Kromster sagt Unterstützung Monica
Da Codebasen oftmals extrem kompliziert sind, ist es schwierig, die genannten Dinge zu beweisen, auch wenn ein erfahrener Entwickler aus Erfahrung weiß, dass das Schneiden von Ecken auf lange Sicht kostspielig sein wird.
Mkataja
17
An dieser Antwort ist nichts auszusetzen, dennoch ist sie meiner Meinung nach für die meisten Situationen in der realen Welt nicht nützlich. Durch die Verbesserung der Qualität einer Codebasis werden häufig die Wartungskosten gesenkt, insbesondere auf lange Sicht. Diese Auswirkungen sind jedoch nur selten quantifizierbar. Daher ist es oft eine strategische Entscheidung.
Doc Brown
2
@DocBrown Ich stimme versuchsweise zu, aber ich denke, dass die von der Anzahl der verschachtelten Wenns getriebene Entwicklung a la OP kein wirksamer Ansatz zur Verbesserung einer alten Codebasis ist.
brian_o
44

Ich selbst und ich waren sowohl Produzent als auch Erhalter von Legacy-Code. Wenn Ihr Tool "Tausende von Verstößen" (oder sogar Hunderte von Verstößen) verursacht, vergessen Sie das Tool, es ist auf die Situation nicht anwendbar ...

Ich gehe davon aus, dass die ursprünglichen Entwickler schon lange nicht mehr zur Diskussion stehen. Es ist also niemand da, der das Warum und Warum des Design- und Codierungsstils versteht. Das Korrigieren von Hunderten oder Tausenden von Verstößen bedeutet nicht, hier und da ein paar Codezeilen neu zu schreiben. Stattdessen ist zweifellos eine Umgestaltung / funktionale Zersetzung erforderlich. Sie versuchen, dies mit einer großen vorhandenen Codebasis zu tun, ohne deren aktuelles Design genau zu verstehen, und Sie sind verpflichtet, eine ganze Reihe neuer Bugs / Probleme / etc. Einzuführen. Nur eine neue Dose Würmer, die noch schlimmer ist als die, die Sie jetzt haben (oder schlimmer als Ihr Werkzeug, das Sie jetzt >> denken <<).

Der einzig vernünftige Ansatz, um "Tausenden von Verstößen" entgegenzutreten, wäre das Neuschreiben von Grund auf. Ein langer und teurer Aufwand, der kaum an das Management zu verkaufen ist. Und in diesem Fall haben sie wahrscheinlich recht ...

Legacy-Code erfordert in der Regel nur Optimierungen. Zum Beispiel für das Jahr 2000 oder wenn die Aktien von 256 auf Dezimal gestiegen sind. Ich habe jede Menge Cr * P gemacht. Und viele andere ähnliche Sachen. Es ist in der Regel ziemlich "genau", dass Sie den manchmal schlechten Stil, die schlechte funktionale Zerlegung, das schlechte usw. "durchlesen" und die Sammlung von Stellen finden können, die geändert werden müssen. Und dann kann es Ihnen ein Rätsel bleiben, was "zwischen diesen Orten" passiert, dh was ist der Fluss auf höherer Ebene? Stellen Sie einfach sicher, dass Sie die lokalisierte Funktionalität verstehen, die Sie ändern, und testen Sie, testen Sie, testen Sie auf Nebenwirkungen usw., die von Ihrem lokalisierten Wissen nicht vorhergesehen werden können.

Wenn Sie sich so nicht durch Code zurechtfinden, sind Sie möglicherweise nicht die beste Person, um älteren Code zu verwalten. Einige Leute können mit einem leeren Bildschirm beginnen und schöne Programme schreiben, aber nicht mit einer großen Codebasis des Codes anderer Leute beginnen und ihn pflegen. Andere Leute können Code pflegen, aber nicht von vorne anfangen. Manche können beides. Stellen Sie sicher, dass die richtigen Personen Ihren Legacy-Code verwalten.

Es kann vorkommen, dass Sie Ihre alte Codebasis von Grund auf neu entwerfen und umschreiben möchten, wenn sich die geschäftlichen (oder sonstigen) Anforderungen so stark ändern, dass "Tweaks" am Hosenplatz den geänderten Anforderungen einfach nicht mehr gerecht werden . Zu diesem Zeitpunkt können Sie auch gleich ein neues Dokument mit den funktionalen Anforderungen verfassen und sicherstellen, dass alle Beteiligten an Bord sind. Es ist im Grunde ein ganz neues Ballspiel.

Die einzige >> falsche << Sache, die Sie tun müssen, ist, die Pflege von Legacy-Code so zu behandeln, wie Sie es bei der Neuentwicklung tun würden. Und dieses eine falsche Ding scheint genau der Weg zu sein, den Sie einschlagen möchten :) Nehmen Sie mein Wort dafür, das ist nicht das, was Sie tun wollen.

John Forkosh
quelle
2
Dies beantwortet eine Frage "Sollte das Erbe neu geschrieben werden". OP fragt jedoch nicht, wie die Warnungen behoben werden sollen oder ob ein erneutes Schreiben erfolgen soll. Die Frage betraf den Qualitätsstandard - im Grunde genommen eine Voraussetzung für jede Änderung, um die Anzahl der Validierungswarnungen nicht zu erhöhen.
Basilevs
9
Hiermit wird direkt die Frage angesprochen, bei der es nicht um das Umschreiben geht. Das OP möchte argumentieren, dass "die Pflege von Legacy-Code genauso behandelt wird, wie Sie es bei der Neuentwicklung tun würden". Diese Antwort sagt "WOAH! Das solltest du nicht tun!" Möglicherweise nicht die Antwort, die das OP oder Sie hören wollten, sondern die vollständige Beantwortung der Frage.
Jonathan Eunice
1
@Basilevs (und @ JonathanEunice). Was Jonathan gesagt hat. Und beachten Sie, dass ich zu Beginn direkt gesagt habe: "Vergiss das Werkzeug, es ist nicht anwendbar auf die Situation", was die Frage direkt anspricht, wenn auch negativ. Aber wie das Sprichwort sagt, wenn Sie kritisieren wollen, bieten Sie konstruktive Kritik. Also konnte ich nicht einfach sagen "Tu das nicht". Ich musste auch vorschlagen, was ich stattdessen tun sollte (und das wurde etwas langatmiger, als ich erwartet hatte, als ich anfing, es zu schreiben).
John Forkosh
1
Bei der Arbeit mit älteren Code-Projekten möchte ich manchmal eine Schnittstellenebene entwerfen, die zwischen altem und neuem Code liegt. Dies ermöglicht eine saubere Trennung zwischen alten und neuen Teilen und erleichtert die Fehlerbehebung bei neuen Teilen, als wenn sie mit einer Menge Code versehen wären, die ich nicht verstehe.
Superkatze
@supercat Wenn das geht, ist es sicher ein netter Ansatz. Aber wenn man sich an verschiedene meiner y2k-Korrekturprojekte erinnert, musste man einfach in die Mitte des vorhandenen Codes "eintauchen" und damit herumspielen. Kein (Re-) Factoring in Alt / Neu möglich (ohne >> massives << Umschreiben). Anstatt beispielsweise zwei Bytes zu Datumsfeldern für ein ccyy-formatiertes Vier-Byte-Jahr hinzuzufügen, das umfassende Aktualisierungen für umfangreiche Datenbanken erfordert, interpretieren Sie yy> 50 als 19yy und yy <= 50 als 20yy. Die einzig sinnvolle Implementierung beinhaltet jedoch viele kleine Änderungen an jedem Ort, an dem yy verwendet wird.
John Forkosh
13

Die Frage ist nicht, wie gut oder schlecht dieser Code ist. Die Frage ist, wie viel Nutzen Sie aus wie viel Investition ziehen.

Sie haben also ein Tool, das Tausende von Dingen findet, die es nicht mag. Sie haben die Wahl, die Ergebnisse des Tools zu ignorieren oder Arbeit zu investieren, um Tausende von Dingen zu ändern. Das ist eine Menge Zeug. Die Leute werden nicht fokussiert, nicht während sie die Änderungen vornehmen, nicht während sie sie überprüfen, und dies wird nicht richtig getestet, da es Ewigkeiten dauert, um herauszufinden, wie man jede Änderung testet (oder nur ausprobiert), so dass es Fehler gibt. Also, bis Sie diese Fehler gefunden und behoben haben, haben Sie viel Zeit und Geld mit einem insgesamt negativen Ergebnis investiert.

Andererseits können Tools Dinge finden, die sie nicht nur "nicht mögen", sondern die Fehler oder potenzielle Fehler sind. Wenn der Legacy-Code noch weit verbreitet ist, kann das richtige Tool tatsächlich Fehler finden. Daher kann es sich lohnen, die Compiler-Warnungen einzeln zu aktivieren, zu überprüfen, ob sie nützlich sind (nicht alle sind nützlich), und diese Warnungen zu beheben.

gnasher729
quelle
2
Ich bin einmal zu einem Projekt gekommen, das schnell erledigt war (ignorierte Compiler-Warnungen etc.). Das Projekt war ein Chaos, es gab einen Fehler. Eine Anzahl lief über. Das Team hat 2 Wochen gesucht. Ich habe die Compiler-Umgebung mit allen aktivierten Warnflags eingerichtet (die Anzahl stieg von 500 auf mehrere tausend Warnungen). Ich ging alle Warnungen durch. Nach nur 3 Stunden hatte ich 0 Warnungen. Aus irgendeinem Grund funktionierte der Code. Aber wir wussten nicht warum. Ich habe den Code bei jeder Änderung in meiner Filiale festgeschrieben. Nach einigem Suchen habe ich es gefunden. Eine implizit deklarierte Funktion, die C veranlasst hat, den Rückgabewert zu entstellen.
CodeMonkey
7

Wenn es nicht kaputt ist, beheben Sie es nicht

Dies sollte praktisch auf jeden Softwareentwickler und -manager tätowiert werden, damit er es nie vergisst.

Ja, es verstößt gegen alle modernen Kodierungskonventionen. Ja, es ist in FORTRAN-77 mit einem Wrapper in C geschrieben, damit es von Python aus aufgerufen werden kann. Ja, das sind unstrukturierte GOTOs. Ja, es gibt ein Unterprogramm mit dreitausend Zeilen. Ja, die Variablennamen sind nur für einen Kroaten sinnvoll. usw. usw.

Aber wenn es über ein Jahrzehnt oder länger im Zorn getestet wurde und vergangen ist, lass es in Ruhe! Wenn die erforderliche Änderung gering ist, halten Sie sie so klein und lokal wie möglich. Alles andere birgt das größere Risiko, etwas zu beschädigen, das nicht repariert werden musste.

Natürlich stellt man manchmal fest, dass es sich wirklich um eine nicht zu wartende Kluge handelt und dass die einzige Möglichkeit, die "kleine" Modifikation zu berücksichtigen, darin besteht, sie von Grund auf neu zu schreiben. In diesem Fall müssen Sie zu demjenigen zurückkehren, der nach der Änderung fragt, und ihm mitteilen, was sie kosten wird (sowohl in Dollar oder Mannstunden für das Umschreiben als auch in Blutschweiß und Tränen für die unvermeidlichen neuen Fehler).

Vor langer Zeit gab es eine Reihe von Ausfällen bei einem der Festplattenlaufwerke von Digital. Am Ende haben sie sich alle bei gord zurückgerufen und ersetzt, was es gekostet hat. Anscheinend befand sich in der HDA ein Klebestreifen mit einem Filter. Das Konstruktionsmanifest sagte über den Klebstoff "Nicht parametrisch spezifiziert, KEINE ERSATZSTOFFE AKZEPTIERBAR". Ein Bohnenzähler "sparte" weniger als einen Cent pro Laufwerk, indem er einen anderen Klebstoff beschaffte. Es gab einen Dampf im HDA ab, der die Festplatte nach ein paar Betriebsjahren tötete. Es war nicht kaputt, bis er es reparierte. Zweifellos "es war nur eine winzige Veränderung ..."

nigel222
quelle
2
Meinen Sie damit Western Digital ? War es dieser Rückruf ? Können Sie Quellen angeben, die Ihre Geschichte stützen?
Leichtigkeit Rennen mit Monica
3
Ziemlich sicher, dass er Digital Equipment Corp meint, von dem ein schwacher Schimmer noch tief im schwarzen Herzen von Hewlett Packard leben könnte.
John Hascall
1
Ja - Digital auch als DEC bekannt.
Nigel222
5

Es ist definitiv nicht sinnvoll, die Qualitätsstufe für Legacy-Code zu verringern. Es ist auch nicht erforderlich, Warnungen sofort zu beheben. Stellen Sie einfach sicher, dass alle Ihre "neuen" Änderungen in jeder Komponente Ihres Projekts einem hohen Qualitätsstandard entsprechen. Dh kein Commit sollte die Anzahl der Warnungen jemals erhöhen.

Es ist ein einheitlicher und absolut einfacher Ansatz.

Es lässt zu, dass alter Legacy-Code unverändert funktioniert (da keine unnötigen Änderungen daran vorgenommen werden). Es stellt sicher, dass neuer Code von hoher Qualität ist. Es fallen keine zusätzlichen Kosten an.

Basilevs
quelle
Ich könnte Ausnahme mit dem Wort nehme immer am Ende des ersten Absatzes. Wenn beispielsweise ein paar Dutzend Änderungszeilen in der Mitte einer Funktion mit mehreren Hundert Zeilen erforderlich sind, deren Stil Warnungen auslöst, werde ich weiterhin versuchen, dem vorhandenen Stil zu folgen, sofern er nicht fehlerhaft ist Ausmaß der Unlesbarkeit. Ich möchte dem nächsten armen Kerl das Leben so einfach wie möglich machen. Stile nur aus dem Grund zu mischen, um die Standards einiger Werkzeuge zu erfüllen, ist an sich schon ein schlechter Stil. Befolgen Sie stattdessen die ursprünglichen Standards / Stile, soweit dies möglich ist.
John Forkosh
Ich habe Commit gesagt, keine Leitung oder Funktion. Angeblich räumst du genug Unordnung in deiner Bearbeitung auf, um ein Budget für einen Problemplatz zu haben.
Basilevs
3

Risikokontrolle….

  • Der Code in der großen Legacy-Codebasis wurde zumindest unter Verwendung der Software im realen Leben getestet.
  • Es ist sehr unwahrscheinlich, dass der Code in der großen alten Codebasis durch automatisierte Komponententests abgedeckt wird.
  • Daher ist jede Änderung der Erkältung in der großen alten Codebasis ein hohes Risiko.

Kosten….

  • Es ist billig, den Code während des Schreibens einer Codeüberprüfung zu unterziehen
  • Dies zu einem späteren Zeitpunkt zu tun, ist sehr viel kostspieliger

Vorteil

  • Sie hoffen, dass die Einhaltung von Codierungsstandards zu einem besseren Code-Design führt.

  • Es ist jedoch sehr unwahrscheinlich, dass eine Person, die viele Wochen lang den Code ändert, um Warnungen aus einem Tool zur Überprüfung des Codestandards zu entfernen, das Design des Codes verbessert.

  • Einfacher Code ist klarer und in der Regel einfacher zu verstehen, es sei denn, der komplexe Code wird von jemandem, der ihn nicht versteht, in kurze Methoden aufgeteilt.

Empfehlung….

  • Wenn in einem Codeabschnitt viele Fehler auftreten oder viele Änderungen zum Hinzufügen zusätzlicher Funktionen erforderlich sind, müssen Sie die Funktionsweise zu 100% verstehen.
  • Verbringen Sie auch die Zeit damit, diesem Codeabschnitt einen guten Komponententest hinzuzufügen, da Sie nachweislich einen Bedarf dafür haben.
  • Sie könnten dann erwägen, den Code neu zu gestalten (wie Sie jetzt wissen), damit er auch die neue Codeprüfung besteht.

Persönlich erleben….

  • In den letzten 20 Jahren meiner Tätigkeit als Programmierer habe ich noch nie einen Fall erlebt, in dem die blinde Änderung der alten, um die gesamte Ausgabe eines neuen Codierungsstandardprüfers zu entfernen, neben der Erhöhung des Einkommens der beauftragten Auftragnehmer auch Vorteile hatte.
  • Ebenso, wenn alter Code erstellt werden muss, um Codeüberprüfungen zu bestehen (TickIt / ISO 9001 falsch durchgeführt), bei denen der alte Code wie der neue Codierungsstandard aussehen musste.
  • Ich habe viele Fälle erlebt, in denen die Verwendung von Standard-Überprüfungswerkzeugen für neuen Code durch die Reduzierung der laufenden Kosten große Vorteile gebracht hat.
  • Ich habe noch nie erlebt, dass ein Unternehmen die Kosten für die Wartung von altem Code, der in einem Produkt mit vielen Kunden verwendet wird, nicht bezahlt hat.
  • Ich habe gesehen, dass das Unternehmen scheitert, weil es das Einkommen der Kunden nicht dadurch erzielt, dass es zu langsam auf dem Markt ist.
Ian
quelle
0

Ist die Diskussion über die Senkung der Schwellenwerte des Werkzeugs? ... oder habe ich es falsch verstanden. Es ist verwirrend geschrieben. Wenn nicht, verwerfen Sie bitte meine Antwort.

IMHO wäre es eine gute Idee, die Empfindlichkeit des Werkzeugs zu reduzieren. Warum? Weil es die haarigsten Teile des Codes hervorheben würde. Die Alternative besteht darin, Berichte mit Tausenden von Verstößen zu erstellen, die aufgrund ihrer Größe unbrauchbar werden.

... ansonsten sprechen Sie einfach mit den Beteiligten darüber und erfahren Sie auch deren Gründe.

dagnelies
quelle
0

Ich würde versuchen, den alten Code vom neuen sauberen Code zu trennen. In zB Eclipse können Sie dies tun, indem Sie sie in verschiedene Projekte einfügen, die sich gegenseitig verwenden. 'Clean'-Projekt und ' Legacy'-Projekt .

Auf diese Weise können Sie beide Projekte in Sonar mit unterschiedlichen Qualitätsstandards analysieren. Die Standards sollten sich nur in der Wichtigkeit der Regeln unterscheiden. Die Regeln selbst sollten gleich sein. Auf diese Weise können Sie im "Legacy" -Projekt sehen, was "repariert " werden muss, um die Standards des "Clean" -Projekts zu erfüllen .

Wann immer Sie es geschafft haben, einen alten Code auf die höheren Standards zu heben, können Sie ihn in das 'Clean'-Projekt verschieben.

In der täglichen Arbeit kann man es aufgrund der zeitlichen Verzögerung nicht schaffen, jede Klasse, die man berührt, an die „sauberen“ Projektstandards heranzuführen. Sie sollten jedoch versuchen, in kleinen Schritten dorthin zu gelangen, indem Sie versuchen, den Legacy-Code bei jeder Berührung ein wenig zu verbessern.

MrSmith42
quelle