Wie würden Sie wissen, ob Sie lesbaren und leicht zu wartenden Code geschrieben haben?

336

Wie würde man wissen, ob der erstellte Code leicht lesbar, verständlich und wartbar ist? Aus der Sicht des Autors ist der Code natürlich lesbar und wartbar, da der Autor ihn zuerst geschrieben und bearbeitet hat. Es muss jedoch einen objektiven und quantifizierbaren Standard geben, an dem unser Beruf den Code messen kann.

Diese Ziele werden erreicht, wenn man mit dem Code ohne den fachmännischen Rat des ursprünglichen Autors Folgendes tun kann :

  • Es ist möglich, den Code zu lesen und den Logikfluss auf einer grundlegenden Ebene zu verstehen.

  • Auf einer tieferen Ebene ist es möglich zu verstehen, was der Code tut, um Eingaben, Ausgaben und Algorithmen einzuschließen.

  • Andere Entwickler können sinnvolle Änderungen am Originalcode vornehmen, z. B. Fehlerbehebungen oder Umgestaltungen.

  • Man kann neuen Code schreiben, beispielsweise eine Klasse oder ein Modul, das den ursprünglichen Code nutzt.

Wie quantifizieren oder messen wir die Codequalität, damit wir wissen, dass sie lesbar, verständlich und wartbar ist?

user22815
quelle
154
Obligatorischer Link (ausnahmsweise nicht an xkcd): osnews.com/images/comics/wtfm.jpg
Jerry Coffin
3
Ich würde nur leichtfertig sagen, dass Sie es wissen, wenn Sie es sehen, aber dieses Argument war grundlegend fehlerhaft und peinlich, auch in seiner ursprünglichen Form, egal, was für Quellcode angewendet wird.
Konrad Rudolph
6
"Natürlich ist Ihr Code aus Ihrer Sicht lesbar" - nicht so offensichtlich!
UncleZeiv
24
Ich würde sagen, Sie wissen es, wenn Sie es ein paar Monate nach dem Schreiben sehen.
JeffO
2
@asfallows: Ich habe meiner Frau einen Code gezeigt, und sie dachte, es sei wirklich ein schlechter Code, weil sie ihn lesen konnte! (Zu viele englisch aussehende Wörter darin und nicht genug @ [! ^ $ & *) Zeichen ...)
gnasher729

Antworten:

370

Ihr Peer sagt es Ihnen, nachdem Sie den Code überprüft haben.

Sie können dies nicht selbst bestimmen, da Sie als Autor mehr wissen, als der Code für sich sagt. Ein Computer kann Ihnen nicht sagen, aus den gleichen Gründen, aus denen er nicht sagen kann, ob ein Gemälde Kunst ist oder nicht. Daher benötigen Sie einen anderen Menschen, der in der Lage ist, die Software zu warten, um sich Ihre Texte anzusehen und seine Meinung zu äußern. Der offizielle Name dieses Prozesses ist Peer Review .

user1249
quelle
6
Nichts ist besser als empirische Tests.
Weltingenieur
25
+1 Ihr wichtigstes Publikum sind Ihre Kollegen, die mit Ihnen das Warum und Wie des Problems, an dem Sie arbeiten, und dessen Lösungen kennen. Guter Code spiegelt das aktuelle Verständnis Ihrer Vergleichsgruppe wider. Angenommen, das Team ist fähig, nachdenklich und offen für neue Ideen. "Ihr Kollege sagt Ihnen, dass es gut / wichtig ist", ist meiner Erfahrung nach eine weitaus bessere Definition als jede andere.
Doug T.
69
Nach meiner Erfahrung funktioniert dies nur, wenn Ihr Kollege weiß, was gut und was schlecht ist. Ansonsten klingt es so: "Sie sollten diesen Code in der gleichen Methode schreiben, das ist einfacher, Code zu finden"
Rangi Lin
12
@RangiLin, nun, dein Kollege könnte recht haben.
11
@Rangi Du musst mit deinen Kollegen zusammenarbeiten. Wenn sie Ihren Code schwierig finden, liegt ein Problem mit Ihrem Code vor. Auf längere Sicht, können Sie sie erziehen, oder versuchen , bessere Kollegen zu bekommen (Sie bewegen können , oder Sie können den Einstellungsprozess beeinflussen) ... Ach ja, und tun , erinnert sich immer , dass sie recht haben.
MarkJ
220

Manchmal ist der beste Weg, dies zu wissen, zu dem Code zurückzukehren, den Sie vor einem halben Jahr geschrieben haben, und zu verstehen, wozu er geschrieben wurde.

Wenn Sie es schnell verstehen, ist es lesbar.

Alex In Paris
quelle
28
Ja, das klingt gut (und ist wahr), aber es ist kein sehr guter Ansatz, um zu entscheiden, was / wie heute zu tun ist ...
Michael Durrant
10
Sezierung schlägt vor, es dauert eine Weile und Sie müssen es sorgfältig tun ...
Deworde
3
Ich könnte den Zeitrahmen für einen erneuten Besuch auf einen Monat oder sogar weniger für einen ersten erneuten Besuch verkürzen. Ich denke, es hängt von der Komplexität des Projekts und der Domäne sowie von Ihrem mentalen Ansatz ab. Ich stelle fest, dass ich in sechs Monaten abgelenkt bin, wenn ich Refactoring- oder Optimierungsmöglichkeiten mit Tools oder Techniken sehe, die ich seit dem ersten Schreiben des Codes gelernt habe, anstatt dass sie wirklich lesbar sind.
Chris Bye
1
@MichaelDurrant Jedes Mal, wenn Sie alten Code überprüfen, werden Sie Teile finden, die anders geschrieben sein sollten, und das werden Sie dann für den Code berücksichtigen, den Sie "heute" schreiben. Ja, es braucht Zeit, um zu lernen, wie man guten Code schreibt.
18.
1
@MichaelDurrant ist es immer noch irgendwie, da du lernen kannst, welche unklaren Dinge du vor sechs Monaten getan hast, und diese Dinge heute nicht mehr tun kannst.
Djechlin
94

Es ist:

  1. wartbar, wenn Sie es pflegen können .
  2. leicht zu warten, wenn jemand anderes es warten kann, ohne Sie um Hilfe zu bitten
  3. lesbar, wenn eine andere Person beim Lesen das Design, das Layout und die Absicht richtig versteht

Der eigentliche Test für 1. ist (wie Alex in Paris und quant_dev sagen), dass Sie ihn nach ein paar Monaten wieder aufnehmen können, wenn Sie etwas anderes tun.

Der Test für 2. und 3. ist, dass jemand anderes es aufheben und herausfinden kann, wie Sie Ihren Code erweitern oder reparieren können, während Sie der Struktur Ihres Entwurfs folgen. Wenn sie das Design kann nicht verstehen, wie es zu dem Problembereich betrifft, oder wie Ihr Code soll verwendet werden, sie werden eine Lösung über das Korn Hack statt.

Es gibt Faustregeln, Prinzipien (dh Faustregeln, die jemand schön geschrieben und benannt hat) und alle möglichen Vorschläge, die Sie in die richtige Richtung führen oder von den üblichen Fallstricken abweichen können. Keiner von ihnen garantiert jedoch die Eigenschaften, nach denen Sie fragen.

Nutzlos
quelle
2
Wie wäre es mit der Überlegung, wie viel Zeit für die Behebung eines Fehlers oder die Änderung des vorhandenen Verhaltens aufgewendet werden muss, um die Wartbarkeit zu gewährleisten? Ein Teil des Codes, der weniger Zeit benötigt, um die gleiche Änderung vorzunehmen, sollte besser zu warten sein, oder?
VCD
1
Hängt davon ab; Manchmal ist für eine erfolgreiche Änderung ein Refactoring erforderlich (was klar ist, dass lesbarer Code nicht für eine solche Verwendung vorgesehen ist). Dies dauert länger als das Hacken in einem speziellen Fall (was unleserlichen Code fördert, da die Absicht unklar ist) ).
Nutzlos
30

Wenn Ihr Code den Prinzipien von SOLID und DRY folgt und eine Reihe von Komponententests enthält , ist er wahrscheinlich wartbar.

Ist es lesbar Lies es. Sind Methoden- und Variablennamen sinnvoll? Können Sie der Programmlogik problemlos folgen? Wenn die Antwort Ja lautet, ist der Code lesbar.

Oded
quelle
8
... und nachdem Sie es gelesen haben, geben Sie es jemand anderem, um zu versuchen, es zu lesen.
Jcmeloni
19
Dies ist kein besonders guter Test. Viele Anwendungen dieser Regeln sind subjektiv, und Sie können Ihren eigenen Code fast immer direkt nach dem Schreiben lesen.
DeadMG
1
"Wenn die Antwort ja ist, ist der Code lesbar" ... von Ihnen . Um zu sehen, ob es für andere lesbar ist, müssen andere versuchen, es zu lesen.
2
IMO, SOLID wird überbewertet. Vor allem die "S." Das oder jeder versteht es falsch.
Erik Reppen
Ich habe unzählige Male Code ausgeführt, der TROCKEN und FEST und doch schrecklich war. Das Befolgen von Grundsätzen kann den falschen Eindruck erwecken, dass das, was Sie schreiben, kein Mist ist.
Jakub Arnold
24

Lesen, wie man nicht wartbaren Code schreibt - Sichern Sie Roedy Green einen lebenslangen Job, indem Sie lachen und lernen.

... wie man Code schreibt, der so schwer zu pflegen ist, dass die Leute, die nach Ihnen kommen, Jahre brauchen werden, um selbst die einfachsten Änderungen vorzunehmen. Wenn Sie all diese Regeln religiös befolgen, können Sie sich sogar eine lebenslange Beschäftigung sichern, da niemand außer Ihnen die Hoffnung hat, den Code aufrechtzuerhalten ...

Der Aufsatz enthält zahlreiche Beispiele, wie man schlechten Code schreibt, und enthält viele lustige Beispiele. Es wird weiterhin erklärt, wie man kreative Rechtschreibfehler , die Wiederverwendung von Namen , die hoch geschätzte Technik der Wiederverwendung globaler Namen als privat, einsetzt .

Der Aufsatz zeigt Ihnen auf humorvolle Weise, wie Sie alle Beispiele für unlesbaren und nicht verwaltbaren Code vermeiden können.

Eigentlich fiel es mir schwer zu glauben, dass irgendjemand Code mit Ähnlichkeiten zu den Beispielen im Text schreiben würde. Damals war ich frisch von der Schule. Aber nach ein paar Jahren Arbeit sehe ich jeden Tag Code aus dem Text ...

iikkoo
quelle
Siehe auch waterfall2006.com/gorman.html Bei der Umstrukturierung wird ein gut gestalteter Code übernommen und durch eine Reihe kleiner, reversibler Änderungen für niemanden außer Ihnen unerreichbar.
Sjoerd
22

Ungeachtet dessen, wie es scheint, gibt es einige ziemlich objektive Maßnahmen, die Sie in Betracht ziehen können. In Büchern wie C ++ - Codierungsstandards , Refactoring und Clean Code finden Sie eine lange Liste von Kriterien, anhand derer Sie Ihren Code beurteilen können. Dabei werden wichtige Namen, Funktionsgrößen, Prinzipien wie Kopplung und Kohäsion, Objektdesign, Komponententests, sukzessive Verfeinerung usw. betrachtet.

Die Liste ist zu groß, um für eine Checkliste zugänglich zu sein, aber Sie lesen das Buch und wählen ein paar wichtige Dinge aus, an denen Sie arbeiten müssen. Lesen Sie es dann nach einigen Monaten erneut, um es weiter zu verbessern.

Karl Bielefeldt
quelle
4
+1 für inkrementelles Lernen und nicht versuchen, über Nacht perfekt zu werden
dj18
19

Der Beweis liegt im Pudding. Beobachten Sie, was passiert, wenn Sie es einer einigermaßen kompetenten Person übergeben haben. Wenn sie nicht viele Fragen in Bezug auf die Schwierigkeit des Codes stellen müssen, haben Sie gute Arbeit geleistet.

Dies war eine frühe Lektion in meiner Karriere. Ein Mentor sagte: "Dokumentieren Sie alles, damit Sie später dem Programm entkommen können. Wenn Sie Fragen nicht antizipieren, wenn die Antworten in Ihrem Kopf frisch sind, müssen Sie sie herausfinden, wenn sie nicht sind."

MathAttack
quelle
10
Beachten Sie, dass die Menschen möglicherweise keine Fragen stellen, weil sie befürchten, ihre Unwissenheit preiszugeben. Möglicherweise empfinden Sie diese Personen aufgrund ihrer Tendenz, sie nicht preiszugeben, sogar als „einigermaßen kompetent“. Ein Mangel an Fragen ist möglicherweise keine gute Sache, es sei denn, Sie wissen, dass Sie beide aufrichtig sind.
Hermann Ingjaldsson
1
@HermannIngjaldsson - Fair genug. Natürlich, wenn sie nicht kompetent sind und etwas kaputt geht, werden Sie früh genug davon erfahren. "Hilfe!!!!"
MathAttack
dies scheint nur zu wiederholen , was in Gesagten Top-Antwort
gnat
17

Ich las alle Antworten durch und bemerkte, dass niemand die Komplexität des Codes erwähnte.

Es gibt eine enge Korrelation zwischen Codekomplexität und Lesbarkeit / Wartbarkeit. Es gibt zahlreiche Algorithmen zur Bewertung der Codekomplexität, aber ich werde nur darauf eingehen, wie die Bewertung der McCabe-Komplexität funktioniert.

Grundsätzlich liest die McCabe-Wertung Ihren Code durch und berechnet die Anzahl der eindeutigen "Pfade", die er durchläuft. Wenn Sie McCabe als Zähler und Codezeilen als Nenner verwenden, erhalten Sie auch eine ziemlich gute Annäherung an die "Lesbarkeit".

Wenn Sie 10 Codezeilen haben und 300 Pfade durch diesen Code führen, handelt es sich um einen ziemlich nicht zu wartenden Code (der sich nur schwer sicher und einfach ändern lässt) und wahrscheinlich nicht sehr gut lesbar ist. Wenn Sie dagegen über 300 Codezeilen verfügen, aber nur einen Pfad durchlaufen (es gibt keine Bedingungen), ist dieser lesbar und leicht zu warten.

Wo McCabe jedoch hinfällt, ist das letztere Beispiel. Wenn ich 300 Codezeilen ohne Bedingungen habe, besteht eine gute Chance, dass ich die Funktion "Wiederverwendung kopieren / einfügen" ausgeführt habe, und das ist natürlich auch keine gute Sache. Es gibt also systemweite Metriken, die Sie zusätzlich zu McCabe anwenden - beispielsweise die Erkennung von doppeltem oder nahezu doppeltem Code.

Joe Rounceville
quelle
2
Das sollte die Antwort sein. Messen. Andere Antworten sind mehr Meinung als Tatsache, wenn ich es verstehen kann, muss es gut sein? Zuerst mit Hilfe der Komplexitätsanalyse messen, dann mit dem menschlichen Refactor nach Duplikaten suchen usw.
Jon Raynor,
1
Ihr letzter Absatz, in dem die Nachteile der durch LOC geteilten McCabe-Punktzahl erwähnt werden, macht eher die gesamte Idee ungültig. Wenn Sie 300 Pfade durch Ihren Code benötigen , warum um alles in der Welt, denken Sie, wird es den Code wartungsfreundlicher machen, mehr Zeilen zu verwenden? Das ist so, als würde man sagen, wenn ein Buch komplizierte Ideen enthält, sollte es ein wirklich großes Buch sein, anstatt zu versuchen, präzise zu kommunizieren. -1.
Wildcard
8

Ein Punkt, den ich teilen würde, ist, wenn der Code in "Module" aufgebaut ist, und wenn ich sage, dass ich damit meine, dass Sie eine Sache in einem Modul ändern und es leicht haben können, mit dem Ganzen zu arbeiten. Es beseitigt Effekte zwischen nicht verwandten Dingen. Ebenfalls:

  • Code ist einfach wiederzuverwenden
  • Ihr Code ist flexibel (dies hängt mit dem Einbau von Modulen zusammen)
  • TROCKEN - Wiederholen Sie sich nicht

Ich empfehle dringend zu lesen, The Pragmatic Programmer.

jket
quelle
8

Einige Tests / Indikatoren:

  • Schalten Sie die IDE aus. Können Sie noch Ihren eigenen Code lesen? Wenn es einen Fehler gibt, ist es ziemlich einfach, ihn von Hand durchzuarbeiten und herauszufinden, in welcher Klasse Sie einen Haltepunkt benötigen, um herauszufinden, wo das Problem liegt? Oder wenn Sie die IDE verwenden, stören Sie sich nicht einmal daran und gehen Sie einfach von Anfang an durch?

  • Wird das Debuggen oft zu einem Wack-a-Mole-Spiel, bei dem das Beheben eines Fehlers mehr als 2 schafft?

  • Wie viele Methodenaufrufe werden vom Trigger-Pull bis zu etwas Nützlichem benötigt? Wie viele Methoden geben genau die gleichen oder die meisten der gleichen genauen Parameter an einen anderen Methodenaufruf weiter?

  • Wie viele Dateien müssen Sie öffnen, um einer Klasse eine einfache neue Methode hinzuzufügen?

  • Denken Sie an Muster und Praktiken, die Sie übernommen haben. Hast du es getan, weil es vollkommen sinnvoll war, oder weil dich jemand davon überzeugt hat, dass "es der einzige Weg ist, es zu tun?" oder weil du es in deinem Lebenslauf haben wolltest oder weil es irgendein Rockstar-Entwickler gesagt hat.

Erik Reppen
quelle
3
Das Lesen von Code ohne IDE erscheint unsinnig, insbesondere als Maß für die Lesbarkeit. Diese Art von Metrik führt zu "Lösungen" im ungarischen Notationsstil, die die Lesbarkeit am Ende wirklich untergraben.
Rubenvb
8

Wie würde man wissen, ob der von ihm erstellte Code leicht zu pflegen und zu lesen ist?

Sie können leicht zu pflegenden und lesbaren Code erkennen, indem Sie nach den folgenden Eigenschaften suchen:

  1. Objekte, Methoden und / oder Funktionen machen immer eines.
  2. Methoden und / oder Funktionen sind prägnant (wie in "kurz aber umfassend").
  3. Objekte, Methoden und / oder Funktionen tun im Wesentlichen das, was Sie denken, dass sie aufgrund ihrer Namen tun sollen.
  4. Code, der zur Wiederverwendung bestimmt ist, kann tatsächlich wiederverwendet werden.
  5. Wenn Sie den Code sofort einem Komponententest unterziehen können, haben Sie wahrscheinlich mindestens einen modularen Code mit einer Verantwortung geschrieben.

Wie würden wir wissen, ob wir einen ziemlich chaotischen und nicht verwaltbaren Code geschrieben haben? Gibt es irgendwelche Konstrukte oder Richtlinien, die wir kennen sollten, wenn wir unordentliche Software entwickelt haben?

  1. Wenn Sie eine Methode durchlesen und es nicht klar ist, was die Absicht war, ist dies im besten Fall nicht relevant und wahrscheinlich im schlimmsten Fall nicht erreichbar.
  2. Wenn es nicht einfach zu sein scheint, ist es wahrscheinlich nicht einfach und das ist ein Zeichen von nicht wartbarem Code oder Code, der bald nicht mehr wartbar sein wird.
  3. Wenn die Codebasis nicht symmetrisch (konsistent) ist, handelt es sich wahrscheinlich um nicht verwaltbaren Code.
mehr
quelle
Ich stimme nicht zu, dass Ihr Refactoring-Beispiel klarer ist. Ich bin damit einverstanden, dass der ursprüngliche Code funktioniert, aber rein in Bezug auf Klarheit und Kommunikationsabsicht denke ich, dass das Original viel besser ist. Ich bin sehr verdächtig, dass Refactoring die Klarheit bei der Einführung von Regex verbessert.
Roy
1
@ Roy, ja, fair genug. Ich hätte dieses Codebeispiel wahrscheinlich nie hinzufügen sollen. Zugegeben, es war vor fast 3 Jahren, aber selbst dann hätte ich wahrscheinlich kein PHP verwenden sollen (ich schaue es mir gerade an), und ich hätte kein Regex verwenden sollen, da es eines dieser Dinge ist, die manche Leute haben kann es ansehen und sofort abrufen, aber für andere, egal wie prägnant, sind reguläre Ausdrücke eine sofortige Deaktivierung. Ich bearbeite die Antwort und lasse das Codebeispiel fallen. Danke für den Kommentar.
Wil Moore III
Wie kann ein Objekt eine Sache tun?
Koray Tugay,
@KorayTugay Betrachten Sie es so. Wenn ein Objekt mehr als ein zusammenhängendes Konzept beschreibt, haben Sie einen Geruch.
Wil Moore III
6

Mit einem Wort: Erleben .

Zu Beginn müssen Sie die Grundlagenarbeit geleistet haben, daher kann ich Programmierern nicht empfehlen, sich die Zeit zum Lesen von Büchern wie Refactoring zu nehmen , die einige der grundlegenderen Werkzeuge in einem Programmierer-Arsenal bereitstellen, die sich verbessern werden Ihre Fähigkeit , Code und zu pflegen Clean Code , die von einigen der am stärksten erkennbaren Talente in unserem Bereich geschrieben worden war, und die beschreibt fast alles , was Sie , um zu verstehen , müssen Sie Ihren Code sauber und lesbar zu gewährleisten.

Keine Lektüre ist jedoch ein Ersatz für hart erarbeitete Erfahrungen. Sie müssen wirklich eine Weile mit Code gearbeitet haben, um den Unterschied zu erkennen, den die Beachtung der Codequalität ausmachen kann. Durch das Erleben der Freude an der Arbeit mit sauberem, gut faktorisiertem Code sowie der Mühe, mit Code-Spaghetti zu arbeiten, lernen Sie, besser zu verstehen, was die Autoren dieser Bücher Ihnen wirklich beibringen wollten, aber Sie tun dies im weiteren Kontext von echtem Live-Produktionscode, bei dem die Qualität Ihrer Arbeit von entscheidender Bedeutung ist und sich auf Ihre Fähigkeit auswirkt, täglich problemlos mit Ihrem Code zu arbeiten.

Es ist auch hilfreich, entweder einen guten Mentor oder einen Kollegen mit der Erfahrung zu haben, um zu bestätigen, dass Sie sich Mühe geben, Code auf hohem Niveau zu schreiben. Dies ist nur ein Grund, warum Codeüberprüfungen so nützlich sein können. Die Verwendung von Codeüberprüfungs- und Formatierungswerkzeugen kann ebenfalls eine sehr nützliche Hilfe sein, um sicherzustellen, dass Sie die Dinge sauber halten. Nichts ist jedoch mit der Erfahrung vergleichbar, die Sie durch jahrelanges Schreiben von Software gesammelt haben, sodass Sie automatisch Code schreiben, der einfach zu warten, sauber, lesbar und strukturiert ist lange.

S.Robins
quelle
3

Ohne puritanisch zu sein: lieber funktional. Die meisten Sprachen (.NET, Ruby, Python, Javascript usw.) unterstützen und fördern dies (z. B. LINQ, Unterstriche).

Es ist außerordentlich leicht zu lesen.

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

Es zwingt jeden Knoten, eine einzelne, fokussierte Absicht zu haben, die der Klarheit des Zwecks dient. Und da jede einzelne Aufgabe isoliert ist, ist das Einstecken und Umordnen von Knoten (Operationen) zu unterschiedlichen Zwecken trivial. Dies erleichtert die Wartung.

Mario T. Lanza
quelle
2

Lesbarer und wartbarer Code: Code, den ein Programmierer auf den ersten Blick so gut verstehen kann , dass er leicht:

  • es über seine Schnittstelle wieder verwenden, oder
  • debuggen oder
  • ändere sein Verhalten. (Hinzufügen / Entfernen eines Features) oder
  • optimieren Sie es
  • Probier es aus

Das läuft auf "Klarheit" hinaus. Das heißt, wie viele Fragen muss der Programmierer an ein bestimmtes Codesegment stellen, bevor er sicher ist, dass er "versteht, was es gut genug macht", um die aktuelle Aufgabe zu lösen, ohne unerwartete Nebenwirkungen zu verursachen.

Das Buch 'Code Complete, von Steve McConnell' geht sehr detailliert darauf ein.

Er durchläuft verschiedene Metriken, anhand derer Sie feststellen können, ob der Code von guter Qualität ist.

Ein Beispiel finden Sie hier: http://books.google.de/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false

JW01
quelle
Dies scheint nichts Wesentliches über die in früheren Antworten gemachten und erklärten Punkte hinzuzufügen
Mücke
Ich denke, eines der wesentlichsten Dinge, die hinzugefügt werden, ist ein Verweis auf Code Complete, der in keiner früheren Antwort erwähnt wird. Dieses Buch ist eines der bedeutendsten und einflussreichsten Bücher, das sich auf das Schreiben von lesbarem und wartbarem Code konzentriert. Jeder, der dieses Buch gelesen hat, muss nicht fragen: "Woher wissen Sie, ob Sie lesbaren und leicht zu wartenden Code geschrieben haben?".
JW01
... daher glaube ich, dass das Beste, was jemand bekommen kann, wenn er wirklich daran interessiert ist, wartbaren Code zu schreiben, darin besteht, dieses Buch zu lesen. Nach vielen Minuten sorgfältiger Überlegungen (die oft viele Minuten länger dauern als die der SO-Moderatoren) ist dies meines Erachtens nicht nur eine angemessene Antwort auf die Frage des OP, sondern auch die beste .
JW01
2

Nebenwirkungen minimieren (im Idealfall keine)

Eine Funktion, die 3 Änderungen an Zuständen außerhalb ihres eigenen Bereichs verursacht, ist viel schwieriger zu überlegen und beizubehalten als eine Funktion, die nur etwas eingibt und etwas anderes ausgibt. Sie können nicht nur wissen, was die Funktion bewirkt, Sie müssen sich auch daran erinnern, was sie bewirkt hat und wie sich dies auf alle anderen relevanten Funktionen auswirkt.

Für OOP bedeutet das Minimieren von Nebenwirkungen auch Klassen mit weniger Mitgliedern und insbesondere weniger Mitgliedern, die den Status der Klasse ändern können, da Mitgliedsfunktionen Zustände ändern können, die über ihre eigenen hinausgehen und Nebenwirkungen haben (sie können beispielsweise die Interna der Klasse manipulieren). Dies bedeutet auch, dass Klassen weniger eigene Datenelemente haben, sodass diese Methoden weniger manipulieren können und weniger Nebenwirkungen auftreten können.

Stellen Sie sich als einfaches Beispiel vor, Sie möchten eine ausgefallene Datenstruktur entwerfen, die einen sortedZustand beibehält, in dem ermittelt wird, ob binäre oder lineare Suchen ausgeführt werden sollen. In einem solchen Fall kann es nützlich sein, den Entwurf in zwei Klassen zu unterteilen. Wenn Sie sorteddie unsortierte Klasse aufrufen, wird möglicherweise eine Datenstruktur einer anderen Klasse zurückgegeben, deren Inhalt immer sortiert bleibt. Jetzt haben Sie weniger Nebenwirkungen (daher weniger fehleranfällig und einfacher zu verstehen) sowie allgemeineren Code (das frühere Design wäre sowohl für die Verarbeitung als auch für die menschliche intellektuelle Effizienz für kleine Arrays, die nie sortiert werden müssen, eine Verschwendung).

Vermeiden Sie überflüssige externe Abhängigkeiten

Möglicherweise können Sie den knappsten Code implementieren, den Sie sich bei maximaler Wiederverwendung von Code vorstellen können, indem Sie 13 verschiedene Bibliotheken verwenden, um eine relativ einfache Aufgabe auszuführen. Dies überträgt jedoch den intellektuellen Aufwand auf Ihre Leser, da diese mindestens Teile von 13 verschiedenen Bibliotheken verstehen müssen. Diese inhärente Komplexität sollte sofort von jedem gewürdigt werden, der versucht hat, eine Bibliothek von Drittanbietern zu erstellen und zu verstehen, für deren Funktion ein Dutzend anderer Bibliotheken abgerufen und erstellt werden musste.

Dies ist wahrscheinlich eine sehr kontroverse Ansicht, aber ich würde eine bescheidene Codeduplizierung dem entgegengesetzten Extrem vorziehen, vorausgesetzt, das Endergebnis ist gut getestet (nichts Schlimmeres als ungetesteter fehlerhafter Code, der vielfach dupliziert wurde). Wenn Sie die Wahl zwischen drei Zeilen duplizierten Codes zur Berechnung eines Vektorkreuzprodukts oder dem Einlesen einer epischen Mathematikbibliothek haben, um nur drei Codezeilen zu sparen, würde ich die erstere vorschlagen, es sei denn, Ihr gesamtes Team ist an Bord dieser Mathematikbibliothek An diesem Punkt könnten Sie noch überlegen, nur 3 Zeilen Code anstelle von 1 zu schreiben, wenn dies im Austausch für die Entkopplungsvorteile trivial genug ist.

Die Wiederverwendung von Code ist ein Spagat. Wenn Sie zu viel wiederverwenden und die intellektuelle Komplexität auf eine Eins-zu-Viele-Art übertragen, müssen die Leser und Betreuer in den oben gespeicherten drei Zeilen einfachen Codes weitaus mehr Informationen als drei Zeilen Code verstehen . Außerdem wird Ihr Code dadurch instabiler, da sich bei Änderungen an der Mathematikbibliothek möglicherweise auch Ihr Code ändert. Wenn Sie zu wenig wiederverwenden und den intellektuellen Aufwand vervielfachen, profitiert Ihr Code nicht mehr von zentralen Verbesserungen. Es ist also ein Balanceakt, aber die Idee, dass es sich um einen Balanceakt handelt, ist erwähnenswert, da der Versuch, jede kleine Form von bescheidener Vervielfältigung zu beseitigen, dazu führen kann zu einem Ergebnis, das genauso schwer zu halten ist, wenn nicht sogar mehr als das entgegengesetzte Extrem.

Teste den Mist draus

Dies ist eine Selbstverständlichkeit, aber wenn Ihr Code nicht alle Eingabefälle verarbeitet und einige Randfälle übersehen, wie können Sie dann erwarten, dass andere den von Ihnen geschriebenen Code beibehalten, den Sie nicht einmal richtig verstanden haben, bevor er auf ihre Augen und Hände übertragen wurde? Es ist schwierig genug, Code zu ändern, der perfekt funktioniert, geschweige denn Code, der nie ganz richtig war.

Darüber hinaus wird Code, der gründliche Tests besteht, im Allgemeinen weniger Gründe für Änderungen finden. Dies bezieht sich auf die Stabilität, die noch wichtiger ist als die Wartbarkeit, da stabiler Code, der niemals geändert werden muss, keine Wartungskosten verursacht.

Schnittstellendokumentation

Priorisieren Sie "was die Dinge tun" vor "wie die Dinge tun", wenn Sie nicht die gleiche Zeit für die Dokumentation beider Dinge aufwenden können. Eine klare Schnittstelle, die in ihren Absichten, was sie in allen möglichen Eingabefällen tun wird (oder zumindest was sie tun soll), offensichtlich ist, wird eine Klarheit des Kontexts für ihre eigene Implementierung ergeben, die nicht nur das Verständnis dessen leiten wird, wie um den Code zu benutzen, aber auch wie es funktioniert.

Während Code, dem diese Eigenschaften fehlen und der nicht einmal weiß, was er tun soll, SOL ist, egal wie gut die Implementierungsdetails dokumentiert sind. Ein 20-seitiges Handbuch zur Implementierung von Quellcode ist für Leute wertlos, die nicht einmal genau herausfinden können, wie er in erster Linie verwendet werden soll und was er in allen möglichen Szenarien tun soll.

Priorisieren Sie für die Implementierungsseite die Dokumentation Ihrer Aktivitäten, die sich von denen aller anderen unterscheiden. Beispielsweise verfügt Intel über eine begrenzte Volume-Hierarchie für seine Raytracing-Kernel. Da ich in diesem Bereich arbeite, kann ich den Großteil der Code-Aktivitäten auf einen Blick erkennen, ohne die Dokumentation zu durchsuchen. Sie machen jedoch etwas Einzigartiges, nämlich das Überqueren des BVH und das parallele Durchführen von Kreuzungen mit Strahlenpaketen . Hier möchte ich, dass sie ihrer Dokumentation Priorität einräumen, da diese Teile des Codes für die meisten historischen BVH-Implementierungen exotisch und ungewöhnlich sind.

Lesbarkeit

Dieser Teil ist sehr subjektiv. Die Lesbarkeit, die menschlichen Denkprozessen nahe kommt, ist mir eigentlich egal. Der am besten dokumentierte Code, der Dinge auf höchstem Niveau beschreibt, ist für mich immer noch schwer zu befolgen, wenn der Autor bizarre und verschlungene Denkprozesse verwendet, um ein Problem zu lösen. In der Zwischenzeit ist es für mich oft einfacher, einen Kurzcode mit 2 oder 3 Zeichen zu verstehen, wenn die Logik sehr einfach ist. Ich schätze, Sie könnten in einem Peer Review nachsehen, was andere bevorzugen.

Ich interessiere mich hauptsächlich für Wartbarkeit und vor allem Stabilität. Code, der keine Gründe für eine Änderung findet, hat keine Wartungskosten.

user204677
quelle
1

Ich würde sagen, eine Möglichkeit wäre zu wissen, ob neue Teammitglieder den Code aufnehmen, verstehen und modifizieren können, um Fehler zu beheben oder neue Anforderungen relativ einfach zu erfüllen.

FrustratedWithFormsDesigner
quelle
1

Hier ist eine Technik, die ich gerne benutze:

Zeigen Sie den Code einem Ihrer Peer-Programmierer und lassen Sie sich erklären, was er tut. Achte auf diese Dinge.

1) Wenn sie den Zweck eines Codeblocks nicht einfach erklären können, überarbeiten Sie ihn.
2) Wenn sie zu einem anderen Codeabschnitt springen müssen, um den aktuellen Abschnitt zu verstehen, müssen Sie ihn umgestalten.
4) Wenn Sie während des Vorgangs das Bedürfnis haben zu sprechen, muss dieser Codeabschnitt überarbeitet werden. (Der Code spricht nicht für sich selbst).

JohnFx
quelle
Angenommen, der Peer-Programmierer ist mindestens gleich erfahren und wird in die Programmiersprache und ihre Redewendungen eingelesen. Allzu oft können Techniken wie diese dazu führen, dass Leute Code in einer Teilmenge der Ausdruckskraft der Sprache schreiben, um Int selbst für das jüngste Teammitglied verständlich zu machen. Das Ergebnis ist ein größerer Code in einer verworrenen Teilmenge der Sprache. Unabhängig davon, wie stark Sie die Sprachuntermenge reduzieren, ist die Verwaltung von 500KLOC Code für kleine Sprachuntermengen immer aufwändiger als von 200KLOC Code, der eine aussagekräftigere Untermenge verwendet.
user1703394
dies scheint nur zu wiederholen , was in Gesagten Top-Antwort
gnat
-1

Der am besten wartbare Code ist Code, der nicht vorhanden ist. Anstatt die LOC-Anzahl zu erhöhen, könnte ein neuer Code, der die LOC-Anzahl "verringert" (auch wenn er isoliert betrachtet etwas weniger wartbar ist), die gesamte Codebasis einfach durch Verringern ihrer Größe wartbarer machen. Daher die Hauptregel für wartbaren Code:

  • maximiere TROCKEN.

Zweitens gibt es für die Wartbarkeit nichts Schlimmeres als versteckte Abhängigkeiten. Also für Regel Nummer 2:

  • Machen Sie alle Ihre Abhängigkeiten explizit.

Drittens sind nicht alle Programmierer gleichermaßen in der Lage, bestimmte Sprachmerkmale oder Redewendungen für fortgeschrittenere Techniken zu pflegen oder zu schreiben. Wenn Sie die gesamte Codebasis verfälschen, erhalten Sie eine große Codebasis, die aufgrund ihrer Größe schwer zu warten ist. Das Zulassen von Funktionen und Redewendungen für fortgeschrittene Techniken im gesamten Code macht den gesamten Code nur für erfahrene Entwickler wartbar, was auch schlecht ist. Der Schlüssel zur Wartbarkeit liegt in der geschicklichkeitsbasierten Schichtung. Beispiel:

Projektübergreifende Bibliotheken: Ältere Entwickler, volles Rückgrat von Tricks Code / Idiom / Techniken Projektspezifische Bibliotheken und System-Backend: Fortgeschrittene Entwickler meiden die fortgeschrittensten und schwer zu erklärenden Dinge. Senioren werden diesen Code durchgehen und nach Möglichkeiten zur Verbesserung von DRY suchen.

Front-End: Junior-Entwickler verwenden einen strengen Style-Guide und eine Reihe von Techniken, um Sprachkonstruktionen und Redewendungen zu vermeiden. Medior-Entwickler werden diesen Code nach DRY-Möglichkeiten und versteckter Geschäftslogik durchsuchen.

Also für Regel Nummer 3:

  • Überlagern Sie Ihren Code nach Entwicklerkompetenz und schreiben Sie den wartbaren Code entsprechend.

ich

user1703394
quelle
1
Dies scheint nichts Wesentliches zu bieten über Punkte, die in früheren 25 Antworten gemacht und erklärt wurden
Mücke
@gnat, ich hatte gehofft, vielen (potenziell schädlichen) Vereinfachungen in anderen Antworten eine "Nuance" hinzuzufügen. Vor allem mit Punkt 3.
user1703394
1
@ user1703394 Diese Frage und ihre Antworten sind Community-Wiki. Wenn Sie der Meinung sind, dass eine vorhandene Antwort verbessert werden könnte, können Sie sie auch ohne die Berechtigung "Beiträge anderer Benutzer bearbeiten" bearbeiten.
-2

Es ist nie zu einfach, lesbaren und leicht zu wartenden Code zu schreiben, aber es ist nicht zu schwer, einen leicht zu wartenden Code zu schreiben.

OOAD ist ein Wort aus vier Buchstaben, aber es ist schwer auf einen Schlag zu verstehen - folge objektorientierter Analyse und Design

  1. Beginnen Sie immer mit einer guten Anforderungserfassung und der genauen Problemstellung

    • Beginnen Sie mit wenigen Anwendungsfällen, z. System-Benutzer-Dialoginteraktion
  2. Sie müssen Ihre Objekte lose gekoppelt halten und sicherstellen, dass sich Ihr Code nicht wiederholt - folgen Sie DRY [Wiederholen Sie sich nicht]

    • Wenn Sie ein Duplikat sehen, suchen Sie nach einem Ort, an dem Sie es einkapseln können
  3. Ihr Code ist offen für Erweiterungen und geschlossen für Änderungen - OCP [Open-Closed-Prinzip]
  4. Wenn Sie Ihren Code ändern, denken Sie immer daran: Erstellen Sie keine Probleme, um Probleme zu lösen. Die IT gibt lediglich an, dass Ihre vorhandenen Funktionen nicht geändert werden
  5. Testen Sie Ihren Code
    • Testen Sie Ihren Code immer, wenn etwas schief geht
  6. Denken Sie bei der Arbeit an der Funktionalität immer daran, die grundlegenden OOP (objektorientierte Prinzipien) und Techniken zu befolgen, um sicherzustellen, dass Ihre Anwendung von Anfang an gut gestaltet ist
    • Objekte sollten tun, was ihr Name angibt
    • Jedes Objekt sollte ein einzelnes Konzept darstellen
  7. Denken Sie immer an die Problembeschreibung des Systems und an die Funktionsweise der Kontext- / Domänensoftware
  8. Mach auch ein bisschen Papierkram - ja, das funktioniert bei mir
    • Einige Ausdrucke von UI-bezogenen Inhalten und UML-Diagrammen funktionieren immer
    • Sie können sogar die Screenshots der Brainstorming-Sitzung vom Whiteboard erhalten
  9. Architekturlayouts
  10. Wenden Sie nach Möglichkeit Gestaltungsprinzipien an
  11. Dokumentation
    • Dokumentieren Sie immer Ihren Code
    • Setzen Sie Einrückungen in der IDE und dokumentieren Sie diese ebenfalls
Narender Parmar
quelle
1
Dies ist eine Theorie, die die Frage nicht beantwortet: Wie quantifizieren oder messen wir die Codequalität, damit wir wissen, dass sie lesbar, verständlich und wartbar ist? Anfrage
Jan Doggen
Einverstanden !! Wenn wir jedoch die oben genannten Prinzipien befolgen, ist es einfach, die Codequalität zu messen, lesbar, verständlich und offensichtlich wartbar. Korrigiere mich, wenn ich falsch liege.
Narender Parmar
Ich weiß nicht, warum meine Antwort herabgestuft wurde, obwohl ich bereits die wichtigsten Punkte behandelt habe
Narender Parmar,