it-swarm-eu.dev

Woher weißt du, dass du guten Code schreibst?

Ich liebe es zu programmieren. Ich habe seit meiner Kindheit mit Code rumgespielt. Ich bin nie den professionellen Weg gegangen, aber ich habe mehrere interne Anträge für verschiedene Arbeitgeber codiert, einschließlich eines Projekts, in das ich ein internes Transaktionsmanagement-/Berichtssystem für eine Bank eingebaut habe. Ich lerne schnell, verstehe viele Konzepte und fühle mich mit dem gesamten Codierungsprozess wohl.

Trotzdem habe ich das Gefühl, nie zu wissen, ob meine Programme gut sind. Sicher, sie funktionieren - aber ist der Code sauber, eng und gut geschrieben, oder würde ein anderer Codierer ihn ansehen und mir in den Kopf schlagen? Ich sehe einige Dinge auf Stack Overflow, die mich einfach umhauen und meine Codierungsversuche völlig schwach erscheinen lassen. Meine Arbeitgeber waren mit dem, was ich getan habe, zufrieden, aber ohne Peer Review bin ich sonst im Dunkeln.

Ich habe mich mit Peer-Code-Überprüfung befasst, aber viele Dinge können aufgrund von NDAs oder Vertraulichkeitsproblemen nicht veröffentlicht werden. Viele von euch Profis haben vielleicht Teamkollegen, mit denen sie sich Dinge über die Schulter schauen oder Ideen austauschen können, aber was ist mit den unabhängigen und Solo-Jungs da draußen wie mir? Wie lernen Sie Best Practices und stellen sicher, dass Ihr Code dem Schnupftabak entspricht?

Oder spielt es keine Rolle, ob es "das Beste" ist, solange es wie erwartet ausgeführt wird und eine gute Benutzererfahrung bietet?

277
Jim

Der größte Hinweis für mich ist:

Ist es schwierig, wenn Sie zurückgehen und eine Funktion hinzufügen/ändern müssen? Unterbrechen Sie ständig vorhandene Funktionen, wenn Sie Änderungen vornehmen?

Wenn die Antwort auf das oben Gesagte "Ja" lautet, haben Sie wahrscheinlich ein schlechtes Gesamtdesign.

Es ist (zumindest für mich) ein bisschen schwierig, ein Design zu beurteilen, bis es auf Änderungen reagieren muss (natürlich aus gutem Grund; ein Teil des Codes ist einfach schlecht und man kann es sofort erkennen, aber selbst das kommt mit Erfahrung.)

333
Ed S.

Dies ist sicherlich eine ziemlich übliche Maßnahme, bei der ich arbeite.

Code Quality = WTFs/minute

Welche Tür repräsentiert Ihren Code? Welche Tür repräsentiert Ihr Team oder Ihr Unternehmen? Warum sind wir in diesem Raum? Ist dies nur eine normale Codeüberprüfung oder haben wir kurz nach dem Start eine Reihe schrecklicher Probleme festgestellt? Debuggen wir in Panik und stöbern in Code, von dem wir dachten, dass er funktioniert? Gehen Kunden in Scharen und Manager atmen uns den Hals runter ...

(Robert C Martin, Clean Code - Buch, das mit dem obigen Bild beginnt)

179
Phil.Wheeler

Sie wissen, dass Sie guten Code schreiben, wenn:

  • Die Dinge sind klug, aber nicht zu klug
  • Algorithmen sind sowohl hinsichtlich der Geschwindigkeit als auch der Lesbarkeit optimal
  • Klassen, Variablen und Funktionen sind gut benannt und sinnvoll, ohne zu viel nachdenken zu müssen
  • Sie kommen nach einem freien Wochenende darauf zurück und können direkt hineinspringen
  • Dinge, die wiederverwendet werden, sind wiederverwendbar
  • Unit-Tests sind einfach zu schreiben
104
Rich Bradshaw

Obwohl Sie sagten, dass Sie keine anderen Programmierer haben, um dies zu tun, werde ich dies für andere einschließen.

Der Code-Qualitätstest: Lassen Sie einen anderen Programmierer, der den Code noch nie gesehen hat, ihn lesen und erklären, was jedes Modul mit Ihnen macht, während Sie über die Schulter schauen. Je stärker Ihr Drang ist, einzuspringen und etwas zu erklären, desto schlechter ist der Code wahrscheinlich. Wenn Sie ruhig mit geschlossenem Mund da sitzen können und sie nicht viele Fragen stellen müssen, sind Sie wahrscheinlich gut.

Zu Ihrem Vorteil finden Sie hier einige allgemeine Richtlinien, wenn Sie keinen Peer zur Hand haben. Sie sind nicht absolut, nur "riecht".

Gute Zeichen

  • Die Methoden sind in der Regel sehr kurz und führen idealerweise eine einzelne Aufgabe aus.
  • Sie haben genügend Informationen, um Methoden aufzurufen, ohne deren Körper zu betrachten.
  • Unit-Tests sind einfach zu schreiben.

Schlechte Zeichen

  • Lange Methoden, die aus 2-3 Unteraufgaben bestehen, die nicht in andere Methoden unterteilt sind.
  • Methoden teilen Daten auf andere Weise als über ihre Schnittstelle.
  • Wenn Sie die Implementierung einer Methode (aber nicht der Schnittstelle) ändern, müssen Sie die Implementierung anderer Methoden ändern.
  • Viele Kommentare, besonders langatmige Kommentare.
  • Sie haben Code, der niemals in Ihrer Anwendung ausgeführt wird, um "zukünftige Flexibilität" zu gewährleisten.
  • Große Try/Catch-Blöcke
  • Es fällt Ihnen schwer, gute Methodennamen zu finden, oder sie enthalten die Wörter "OR" und "AND" (z. B. GetInvoiceOrCustomer).
  • Identische oder nahezu identische Codeblöcke.

Hier ist eine längere Liste von Code riecht , die auch hilfreich sein sollte.

59
JohnFx

Für mich persönlich denke ich, wenn ich den Code vergesse. Mit anderen Worten:

  • Fehler treten selten auf
  • Wenn sie auftreten, lösen andere Leute sie, ohne mich etwas zu fragen
  • Noch wichtiger ist, dass mich niemand je nach meinem Code fragt
  • Menschen haben keine hohe WTF/min-Rate beim Lesen
  • Viele neue Klassen im System verwenden meine Klasse ( High Fan-In , wie Steve McConnell es nennen würde).
  • Der Code kann bei Bedarf leicht geändert und/oder umgestaltet werden, ohne mich zu verfluchen (auch wenn ich es bin - ich selbst verfluche!)
  • Ich liebe es auch, wenn ich genau die richtige Menge an Abstraktion schätze, die jedem im Team zu passen scheint

Es ist ein schönes Gefühl, wenn Sie eine Datei öffnen, die Sie vor einem Jahr geschrieben haben, und alle netten Ergänzungen zu einer Klasse sehen, aber nur sehr wenige Modifikationen , und - sehr hoher Fan-In! :) :)

Natürlich sind dies die Dinge, die mir das Gefühl geben, guten Code zu schreiben, aber in Wirklichkeit ist es wirklich schwer zu wissen. Ich vermute, wenn sich die Leute mehr über Ihren Code lustig machen als über Sie, ist es Zeit, sich Sorgen zu machen.

27

Ich habe drei goldene Regeln:

  1. Wenn ich gezwungen bin, Codeblöcke zu kopieren/einzufügen, mache ich etwas falsch
  2. Wenn ich nicht den ganzen Code in meinem Kopf haben kann, mache ich etwas falsch
  3. Wenn jemand einspringt und sich in meinem Code verliert, mache ich etwas falsch

Diese Regeln haben mich zu einigen echten architektonischen Verbesserungen geführt, die zu kleinen, sauberen und wartbaren Klassen/Methoden geführt haben.

20
dukeofgaming

Dies ist eine ausgezeichnete Frage, und ich begrüße Sie dafür, dass Sie sie überhaupt gestellt haben.

Erstens ist es gut, hin und wieder den Verstand zu verlieren. Hält dich demütig, lässt dich erkennen, dass du nicht alles weißt, dass es Leute gibt, die besser in dir sind als das, und gibt dir etwas Besseres anstreben.

Woher wissen Sie, wann Sie guten Code schreiben?

  • Wenn Ihre Klassen jeweils einem einzelnen, sehr klar definierten Zweck dienen, getrennt von anderen Klassen mit anderen klar definierten Zwecken.
  • Wenn Ihre Methoden kurz sind - idealerweise unter 50 Zeilen und sicherlich unter 100 - und ihre Namen klar definieren, was sie genau tun . Eine Methode sollte nichts anderes tun, als der Name impliziert. Wenn Sie mehr als 100 Zeilen verwenden oder sehr weit in Registerkarten eingefügt sind, können Sie wahrscheinlich etwas in die eigene Funktion ziehen.
  • Wenn Ihr Code eine Möglichkeit bietet, etwas zu tun - wenn er nicht die Option Zick oder Zack bietet, sondern stattdessen einen einzelnen linearen Pfad für jede mögliche Vorgehensweise bereitstellt, die der Benutzer möglicherweise nach unten sendet.
  • Wenn Sie alles getan haben, können Sie die Kopplung zwischen Klassen vernünftigerweise verringern. Wenn also Klasse A von Klasse B abhängt und Klasse B entfernt und Klasse C an ihre Stelle gesetzt wird, müssen an Klasse A kaum oder gar keine Änderungen vorgenommen werden. Klasse A sollte so blind wie möglich für das sein, was in der Klasse B vor sich geht Außenwelt.
  • Wenn Ihre Klassen-, Methoden- und Variablennamen von jedem gelesen und sofort verstanden werden können, der auf den Code stößt, ist 'pktSize' nicht erforderlich, wenn 'packetSize' viel einfacher zu lesen ist.

Wie andere bereits gesagt haben, folgt der Code im Wesentlichen nicht den guten objektorientierten Prinzipien, wenn Sie objektorientierte Programmierung durchführen und wenn es an der Zeit ist, etwas zu ändern, wie wenn Sie versuchen, einen Wollknäuel zu entwirren und zurückzuspulen .

Ich kann das Buch "Clean Code", nur empfehlen, wenn Sie daran interessiert sind, etwas näher darauf einzugehen. Es ist eine gute Lektüre für Anfänger und Experten gleichermaßen.

11
trycatch

Ich würde sagen, meine Hauptpunkte wären:

  • Lesbarkeit (für Sie und alle anderen, die sich Ihren Code angesehen haben)
  • Wartbarkeit (leicht zu ändern)
  • Einfachheit (Dinge nicht komplizieren, wenn das nicht nötig ist)
  • Effizienz (natürlich sollte Ihr Code schnell ausgeführt werden)
  • Klarheit (Wenn Ihr Code selbsterklärend ist, sind die meiste Zeit keine Kommentare erforderlich, benennen Sie Ihre Methoden/Eigenschaften usw. sinnvoll, brechen Sie die lange Code nach unten kopieren und niemals einen Codeblock einfügen)

Ich füge Design nicht in diese Liste ein, da ich glaube, dass ein guter Code geschrieben werden kann, ohne sich an ein Designmuster zu halten, solange es in Ihrem Projekt konsistent ist .

Guter MSDN-Artikel zu diesem Thema: Was macht guten Code gut?

7
Грозный

Schauen Sie sich nach einem guten Open Source-Projekt in Ihrer Lieblingssprache um und sehen Sie, was sie tun.

Zum Beispiel ist sendmail ein Ort, an dem Sie nachsehen können, ob Sie Spaghetti-Code schreiben. Es ist nicht wirklich die Schuld von sendmail. Es ist erst 20 Jahre alt und hat viel Cruft. Wenn Ihr Code also wie sendmail-Code aussieht, sind Sie wahrscheinlich auf dem falschen Weg.

Ich habe mir Postfix in letzter Zeit allerdings nicht angesehen, und es ist wahrscheinlich sehr gut gestaltet. Wenn Ihre Inhalte also eher wie Postfix aussehen, sind Sie auf dem richtigen Weg.

Als ich als Kind anfing zu programmieren, gab es kein Internet und man hatte nichts zu vergleichen. Aber jetzt, da eine Unmenge von Codezeilen zum Vergleich zur Verfügung stehen, sollten Sie sich ein Bild davon machen, ob Sie es richtig machen oder nicht.

Und nur weil der Linux-Kernel der Linux-Kernel ist, heißt das nicht, dass er gut geschrieben ist. Merk dir das.

6
stu

Dies war meine Erfahrung seit dem Wechsel von der College-Programmierwelt zur Industrie in den letzten fünf Monaten:

  • Benutzerfreundlichkeit ist so wichtig, dass wir die Leute nur dafür bezahlen, Benutzeroberflächen zu entwerfen. Codierer saugen oft am UI-Design.
  • Sie finden, dass es nicht ausreicht, es zum Laufen zu bringen
  • Optimierungen werden in realen Szenarien kritischer.
  • Es gibt tausend Möglichkeiten, sich einem Problem zu nähern. Oft berücksichtigt der Ansatz jedoch nicht etwas weniger bekannte Faktoren, die die Leistung Ihres Ansatzes beeinträchtigen könnten, wie z. B. Datenbankauthentifizierung, Transaktionen, Datei E/A , Reflexion, um nur a zu nennen zufällige wenige.
  • Die Wartbarkeit ist ein sehr wichtiger Aspekt der Codierung. Nur weil dein Code super optimiert und super dicht ist ... heißt das nicht, dass er sexy ist. Manchmal wird es einfach als "Heldencodierung" bezeichnet.
  • Designfähigkeiten werden erlernt, nicht inhärent. Ich bin mir sicher, dass es ein paar Gehirnkinder gibt, aber im Allgemeinen wird solides Design in Bezug auf reale Probleme durch Zeit, Untersuchung und vor allem durch die Vermittlung von Wissen von Ihren Vorgesetzten = P hervorgebracht
  • Dokumentation ist keine Annehmlichkeit, sondern eine Notwendigkeit.
  • Das Gleiche gilt für nit Testing (dies variiert zugegebenermaßen von Unternehmen zu Unternehmen)

Ich würde vorschlagen, dass Sie eine Gelegenheit mit einem Open-Source-Projekt nutzen. Sie können sehen, wie viel Sie wirklich wissen, wenn Sie mit anderen Programmierern zusammenarbeiten. Ein Open Source-Projekt ist wahrscheinlich der beste Weg, um anhand Ihres Hintergrunds herauszufinden.

6
Feisty Mango

Lesen Sie guten Code und finden Sie heraus, warum er gut ist. Lesen Sie schlechten Code und finden Sie heraus, warum er schlecht ist. Lesen Sie mittelmäßigen Code und finden Sie heraus, welche Teile gut, welche schlecht und welche in Ordnung sind. Lesen Sie Ihren eigenen Code und machen Sie dasselbe. Holen Sie sich ein paar (angesehene) Lehrbücher, um sich die Beispiele anzusehen und zu verstehen, warum sie so geschrieben wurden, wie sie es getan haben. Lesen Sie meistens den Code, bis Sie den Unterschied zwischen schlecht und gut erkennen und Ihr eigenes "Wtf?" Tests.

Sie können nicht wissen, ob Sie guten Code schreiben, bis Sie guten Code im Allgemeinen erkennen können. Nur weil etwas über deinem Kopf ist, heißt das nicht, dass es gut geschrieben ist ...

("Code anderer Leute lesen" ist in einigen Kommentaren zu diesem Thread aufgetaucht, aber ich dachte, er hätte einen eigenen Beitrag verdient.)

2
Beekguk

Aus Code- und Designperspektive gefällt mir, was andere bereits über die Wartbarkeit gesagt haben.

Darüber hinaus schaue ich auch auf Stabilität. Sehen Sie sich die Statistiken zur Produktionsunterstützung an. Wenn Sie eine hohe Anzahl an Support-Korrespondenz für Dinge erhalten, die wie grundlegende Funktionen erscheinen, aber feststellen, dass viele Menschen nicht in der Lage sind, die Verwendung der Software zu verstehen, oder feststellen, dass sie nicht ihren Anforderungen entspricht, stimmt etwas nicht.

Natürlich gibt es einige Benutzer, die wirklich ahnungslos sind, aber wenn Sie im Laufe der Zeit immer noch Berichte über Bruch, Verwirrung oder signifikante Änderungsanforderungen erhalten, ist dies ein Hinweis darauf, dass eine oder alle der folgenden Bedingungen zutreffen:

  • Die Anforderungen wurden gebrochen
  • Der Code ist kaputt
  • Die Anwendung ist nicht intuitiv
  • Der Entwickler hat die Benutzeranforderungen nicht verstanden
  • Jemand drängte auf Liefertermin über Qualität
  • Jemand hat nicht gut getestet oder wusste, worauf er testen sollte
2
Bernard Dy

Bitten Sie jemanden, Ihren Job für einen Tag zu übernehmen und zu überprüfen, wie gestresst er oder sie am Ende des Tages ist ;-)

Ich bin schlecht darin, Dinge zu dokumentieren und aufzuräumen - so überprüfe ich es.

2
Stefan Ernst

Wenn Sie es wie Prosa lesen können.

2
Klaim

Für einen bestimmten Code:

Wenn es funktioniert und wartbar ist (wählen Sie Ihre bewährten Methoden aus), handelt es sich um guten Code.

Für Sie als Entwickler im Laufe der Zeit:

Gut ist ein relativer und dynamischer Begriff für die Sprachdomäne, die Problemdomäne, die aktuellen Trends und vor allem Ihre Erfahrung. Der "GUTE" Säuretest für dieses Kontinuum könnte einfach auf Ihre vorherige Arbeit zurückblicken und wenn Sie sagen "seufz habe ich es wirklich so gelöst?" Dann wachsen Sie wahrscheinlich immer noch und schreiben wahrscheinlich weiterhin guten Code.

Wenn Sie zurückblicken und dann perfekten Code sehen, sind Sie auch perfekt - und es besteht die Gefahr, dass Sie stagnieren und möglicherweise bald aufhören, guten Code zu schreiben.

1
Stephen Bailey

Guter Code ist subjektiv für die Person. Ein professioneller Codierer, der viele Bücher gelesen und Seminare besucht und verschiedene Codierungstechniken verwendet hat, würde Ihren Code wahrscheinlich in Stücke reißen ... Ich habe jedoch festgestellt, dass Code wirklich anzeigt, wo sich die Erfahrung der Codierer befindet. Für mich liest es sich wie ein Geschichtsbuch oder eine Autobiografie. Es ist das, was der Codierer zu der Zeit wusste oder auf welche Tools er/sie beschränkt war.

Fragen Sie sich Folgendes: Warum benötigt Microsoft drei Softwareversionen, um etwas richtig zu machen? Weil sie ständig die Fehler beheben, die sie in den vorherigen Versionen gemacht haben. Ich weiß, dass mein Code nach einer Überarbeitung immer besser wird. Sicher wird es Leute hier geben, die sagen, ich schreibe beim ersten Mal perfekten Code. Wenn du das glaubst, dann habe ich ein Sumpfland, das ich dir verkaufen kann ...

Wenn Sie die Konzepte verstehen, wird es einfacher. Für mich ist der Beginn des Lernens von etwas Neuem "Kann ich es zum Laufen bringen?", Dann ist der nächste Schritt "Ich frage mich, ob ich es so machen kann ...", dann frage ich normalerweise, wenn ich es genagelt habe "wie kann ich es schneller machen" ...

Wenn Sie ein Programmierer sein wollen, müssen Sie sich darauf einlassen und es einfach tun. Es erfordert viel Arbeit und um ehrlich zu sein, ist es wie ein Kunstwerk, das niemals fertiggestellt werden kann. Wenn Sie jedoch nur ein Gelegenheitshobbyist sein möchten, machen Sie sich keine Sorgen, wenn es funktioniert. Sie müssen sich an Ihre Umgebung anpassen. Wenn Sie keine Möglichkeit haben, Codeüberprüfungen durchzuführen, ist Unwissenheit Glückseligkeit =)

Aber egal was ... Jeder wird seine eigene Meinung haben. Sicher, es gibt richtige und falsche Wege, Dinge zu tun ... Aber meistens habe ich festgestellt, dass es meistens bessere Wege gibt, Dinge zu tun als nur falsche Wege ...

1
webdad3

Trotzdem habe ich das Gefühl, nie zu wissen, ob meine Programme gut sind. Sicher, sie funktionieren - aber ist der Code sauber, eng, gut geschrieben, oder würde ein anderer Codierer ihn ansehen und mir in den Kopf schlagen?

Haben Sie fragen einen anderen Codierer überlegt, was er von Ihrem Code hält?

Einige Orte verwenden "Peer Review", wobei Code muss für einen anderen Codierer akzeptabel sein muss, bevor er in das Code-Repository aufgenommen wird.

1
user1249

IMHO gibt es keinen "guten Code" an sich, aber es gibt "gute Software".

Wenn wir an etwas arbeiten, gibt es viele Einschränkungen in unserer Arbeit, die uns oft dazu bringen würden, den Code zu produzieren, der nicht dem "guten Code" -Standard anderer Programmierkollegen entspricht.

Einige könnten sagen, "guter Code" ist der Code, der einfach zu pflegen ist. Das Gegenargument für diese Aussage ist für mich, wie einfach? Müssen wir uns um 200% bemühen, um den Code so einfach zu warten, dass er aus Gründen des "guten Codes" gewartet werden kann, auch wenn wir wissen, dass wir ihn nicht so oft warten müssen? Es tut mir leid, aber ich denke nicht.

Tatsächlich bin ich derjenige, der wirklich für "guten Code" in meinem Team wirbt, für den sich niemand wirklich interessiert. Jedes Mal, wenn ich mir ihre Codes ansehe, habe ich nie festgestellt, dass sie einen perfekten Code schreiben. Ich muss jedoch akzeptieren, dass sie die Arbeit wirklich erledigt haben und sie auch angemessen für die Bedürfnisse unseres Unternehmens warten können. Natürlich ist die Anwendung manchmal fehlerhaft, aber wir haben es gerade noch rechtzeitig geschafft, um unsere Kunden und Benutzer glücklich zu machen und unser Unternehmen in der Position zu sichern, die weit vor unseren Mitbewerbern liegt.

Ich würde also sagen, dass "guter Code" der Code ist, der das produziert, was Sie brauchen. Sie müssen nur überlegen, was Sie wirklich brauchen, und dann Ihren Code bewerten.

1
tia

Noch nie.

"Guter Code" ist nur Code, für den noch keine Verbesserungsmöglichkeit gefunden wurde. Wie Jeff Atwood sagte :

Es gibt eine Handvoll Programmierer auf der Welt, die brillanten, perfekten Code produzieren können. Alles, was der Rest von uns tun kann, ist, unsere Software im Laufe der Zeit immer weniger beschissen zu machen - ein Prozess der kontinuierlichen Verbesserung

Übrigens muss man nicht die Perfektion erreichen, denn manchmal " Ausreichendes Design bedeutet schlechtes Design ".

0
David

Es gibt nichts Schöneres, als wenn jemand Erfahrung mit Ihrem Code hat, aber es gibt einige Ressourcen, mit denen Sie Ihren Code selbst bewerten und verbessern können. Schauen Sie sich Martin Fowlers Refactoring (oder Website ) an. Sutter und Alexandrescus C++ Coding Standards ist gut, wenn Sie in C++ schreiben. Viele der darin enthaltenen Empfehlungen sind sprachunabhängig, andere können jedoch möglicherweise ähnliche Bücher für andere Sprachen empfehlen. Testgetriebene Entwicklung kann für Solo-Entwickler sehr nützlich sein, da sie eine Art Qualitätsprüfung bietet und Sie wissen, wenn Tests schwer zu schreiben sind, bedeutet dies, dass Ihr Code möglicherweise eine Umstrukturierung benötigt.

Einige andere Anzeichen sind prozessorientierter. Sie führen normalerweise zu besserem Code, aber nicht direkt. Dazu gehören Dinge wie die Verwendung der Quellcodeverwaltung, ein automatisierter Erstellungsprozess, die nicht direkt auf dem Live-Server entwickelt wird, die Verwendung von Fehlerverfolgungssoftware usw.

0
Karl Bielefeldt

Um gut zu programmieren, möchte ich sicherstellen, dass das Programm hochfunktional und schnell ist. Stellen Sie sicher, dass sich alles an einem Ort befindet, an dem es sein sollte, damit die Datei, Daten, Funktionen und Abstraktionen ziemlich offensichtlich sind.

Nach diesem Punkt habe ich es auf die Probe gestellt: Finden Sie eine Person, die im Allgemeinen nicht mit Computern vertraut ist, und versuchen Sie, einige der wichtigsten Codemuster zu erklären. Wenn sie es irgendwie lesen können, wow. Gut gemacht.

Meistens nur KUSS und versuche innovativ zu sein, ohne irgendetwas zum Absturz zu bringen. Ich würde auch mehr Notizen darüber machen, wie man zum Code zurückkehrt und eine schöne Zeit damit hat, ihn zu verbessern und zu pflegen, aber das wurde ziemlich gut behandelt.

0
Garet Claborn

Sie können ein Code-Analyse-Tool wie FindBugs , PMD verwenden. Dadurch erhalten Sie einige Informationen zur Qualität Ihres Codes.

0
nimcap

Geben Sie Ihren Code frei und lassen Sie einige Leute damit herumspielen, um sicherzustellen, dass er das tut, was er immer tun soll. Oder wenn Sie möchten, entwerfen Sie eine Spezifikation und stellen Sie sicher, dass sie alle diese Spezifikationen erfüllt. Wenn Sie einen oder beide dieser Tests bestehen, ist Ihr Code "jetzt gut". Für die meisten Leute wird Ihr Code niemals großartig sein, weil Sie in einem Jahr zurückkommen und sagen: "Warum habe ich das getan, wenn es so viel besser funktioniert hätte das Weg? "

Mit mehr Erfahrung erhalten Sie besseren Code. Aber wenn Sie ständig dieselben Gewohnheiten praktizieren, werden Sie immer wieder in dieselben Fallstricke geraten. Es ist nur eine einfache Interpretation eines alten Sprichworts von "Übung macht permanent". Wenn Sie die Dinge kontinuierlich richtig machen (z. B. Ihren Code testen, um sicherzustellen, dass er immer so funktioniert, wie er soll), werden Sie besser. Wenn Sie die Dinge ständig falsch machen (z. B. niemals Ihren Code auf bestimmte Situationen testen oder nicht erkennen, wo Fehler auftreten können), werden Sie nur hartnäckig mit Ihrem Code.

0
Andrew Hays