it-swarm.dev

Wie kann die Anzahl der Fehler beim Codieren reduziert werden?

Niemand ist perfekt, und egal was wir tun, wir werden von Zeit zu Zeit Code produzieren, der Fehler enthält. Welche Methoden/Techniken können Sie verwenden, um die Anzahl der von Ihnen verursachten Fehler zu verringern, sowohl beim Schreiben neuer Software als auch beim Ändern/Verwalten von vorhandenem Code?

30
GSto

Vermeiden Sie ausgefallene Codierung. Je komplizierter der Code ist, desto wahrscheinlicher sind Fehler. In modernen Systemen ist klar geschriebener Code normalerweise schnell und klein genug.

Verwenden Sie verfügbare Bibliotheken. Der einfachste Weg, Fehler beim Schreiben einer Dienstprogrammroutine zu vermeiden, besteht darin, sie nicht zu schreiben.

Lernen Sie ein paar formale Techniken für die komplizierteren Dinge. Wenn es komplizierte Bedingungen gibt, nageln Sie sie mit Stift und Papier fest. Im Idealfall sollten Sie einige Proof-Techniken kennen. Wenn ich beweisen kann, dass der Code korrekt ist, ist er fast immer gut, mit Ausnahme großer, dummer, offensichtlicher Fehler, die leicht zu beheben sind. Natürlich geht dies nur so weit, aber manchmal kann man formell über kleine, aber komplizierte Dinge nachdenken.

Erfahren Sie, wie Sie für vorhandenen Code eine Umgestaltung vornehmen: wie Sie kleine Änderungen am Code vornehmen, häufig mithilfe eines automatisierten Tools, um den Code besser lesbar zu machen, ohne das Verhalten zu ändern.

Mach nichts zu schnell. Nehmen Sie sich ein wenig Zeit, um die Dinge richtig zu machen, um zu überprüfen, was Sie getan haben, und um darüber nachzudenken, was Sie tun, kann sich das später auszahlen.

Wenn Sie den Code geschrieben haben, verwenden Sie das, was Sie brauchen, um ihn gut zu machen. Unit-Tests sind großartig. Sie können Tests häufig im Voraus schreiben, was ein gutes Feedback sein kann (wenn dies konsequent durchgeführt wird, handelt es sich um eine testgetriebene Entwicklung). Kompilieren Sie mit Warnoptionen und beachten Sie die Warnungen.

Lassen Sie sich von jemand anderem den Code ansehen. Formale Codeüberprüfungen sind gut, aber möglicherweise nicht zu einem geeigneten Zeitpunkt. Pull-Anfragen oder ähnliches, wenn Ihr SCM sie nicht unterstützt, ermöglichen asynchrone Überprüfungen. Buddy Checking kann eine weniger formelle Überprüfung sein. Die Paarprogrammierung stellt sicher, dass zwei Augenpaare alles betrachten.

58
David Thornley

nit Tests Mit dieser Option können Sie die Anzahl der Fehler reduzieren, die ein zweites Mal auftreten. Wenn Sie einen Fehler in Ihrem Code finden, stellen Sie durch Schreiben eines Komponententests sicher, dass dieser später nicht mehr angezeigt wird. (Außerdem ist es manchmal schwierig, an alle Fälle zu denken und Tausende von Komponententests im Voraus zu schreiben.)

30
Ryan Hayes

Ich habe einen ziemlich funktionalen Programmierstil entwickelt, obwohl meine Hauptsprachen C++ und Python sind. Ich habe festgestellt, dass mein Code viel robuster geworden ist, wenn ich den gesamten Kontext an eine Funktion (oder Methode) übergebe, die diese Funktion für ihre Arbeit benötigt, und die gesuchten aussagekräftigen Daten zurückgebe, nach denen ich suche.

Der implizite Zustand ist der Feind und meiner Erfahrung nach die Hauptursache für Fehler. Dieser Status kann eine globale Variable oder eine Mitgliedsvariable sein. Wenn die Ergebnisse jedoch von etwas abhängen, das nicht an die Funktion übergeben wird, fragen Sie nach Problemen. Es ist natürlich nicht möglich, den Status zu beseitigen, aber seine Minimierung hat enorme positive Auswirkungen auf die Programmzuverlässigkeit.

Ich möchte meinen Mitarbeitern auch gerne sagen, dass jeder Zweig (wenn, für, während ,? :) ein wahrscheinlicher Fehler ist. Ich kann nicht sagen, wie sich der Fehler manifestieren wird, aber je weniger bedingtes Verhalten Ihr Code aufweist, desto wahrscheinlicher ist es, dass er fehlerfrei ist, einfach weil die Codeabdeckung während der Ausführung konsistenter ist.

All diese Dinge wirken sich auch positiv auf die Leistung aus. Sieg!

9
dash-tom-bang

+1 auf beide Unit-Test-Kommentare.

Legen Sie darüber hinaus die höchste Warnstufe fest, die Ihr Compiler bietet, und stellen Sie sicher, dass Warnungen als Fehler behandelt werden. Fehler verstecken sich oft in diesen "fehlerhaften" Fehlern.

Investieren Sie in ähnlicher Weise in statische Analysetools, die zur Kompilierungszeit ausgeführt werden (ich betrachte diese als zusätzliche Ebene von Compiler-Warnungen).

9
Alan

Zusätzlich zu dem, was erwähnt wurde:

  • Ignorieren Sie keine Fehlercodes - z. Gehen Sie nicht davon aus, dass Sie ein gültiges Ergebnis erhalten haben, dass eine Datei erfolgreich erstellt wurde usw. Denn eines Tages wird etwas passieren.
  • Gehen Sie nicht davon aus, dass Ihr Code niemals eine Bedingung eingibt und dass daher "es sicher ist, diese Bedingung zu ignorieren".
  • Testen Sie Ihren Code und lassen Sie ihn von einer anderen Person testen. Ich finde, ich bin die schlechteste Person, um meinen eigenen Code zu testen.
  • Machen Sie eine Pause, lesen Sie Ihren Code erneut und prüfen Sie, ob Sie "das Offensichtliche verpasst haben". Passiert mir oft.

Viele andere Dinge vergesse ich im Moment, aber die anderen werden sicherlich an sie denken. :) :)

9
MetalMikester
  • Schreiben Sie weniger Code, der mehr kann.
  • Denken Sie an die Auswirkungen auf niedriger Ebene und die Auswirkungen auf hoher Ebene
  • Betrachten Sie die Abstraktion, die Sie in Ihrem Code erstellen.
  • Schreiben Sie nach Möglichkeit nur die wesentliche Komplexität.
8
Paul Nathan

Eine etwas weniger technische Antwort: Programmieren Sie nicht, wenn Sie müde (9 Stunden pro Tag sind genug), betrunken oder "gebacken" sind. Wenn ich müde bin, habe ich nicht die nötige Geduld, um sauberen Code zu schreiben.

8
Alexandru

Schreiben Sie nit-Tests und Integrationstests.

7
ysolik

Hier einige gute Antworten zu Unit-Tests und Tools. Das einzige, was ich ihnen hinzufügen kann, ist Folgendes:

Beziehen Sie Ihre Tester so früh wie möglich ein

Wenn Sie ein Testteam haben, geraten Sie nicht in die Falle, sie als Gatekeeper für Ihre Codequalität zu behandeln und Ihre Fehler für Sie zu erkennen. Arbeiten Sie stattdessen mit ihnen und beziehen Sie sie so früh wie möglich ein (bei agilen Projekten ist dies von Anfang an der Fall, aber wir können immer Wege finden, sie früher einzubeziehen, wenn wir es wirklich versuchen).

  • Finden Sie heraus, was ihr Testplan ist. Überprüfen Sie ihre Testfälle mit ihnen - decken Sie sie alle mit Ihrem Code ab?
  • Bitten Sie sie um Verständnis für die Anforderungen. Ist es dasselbe wie deins?
  • Geben Sie ihnen frühzeitig funktionierende Builds, an denen sie Erkundungstests durchführen können - Sie werden erstaunt sein, welche Verbesserungen sie vorschlagen werden.

Eine gute Zusammenarbeit mit Ihren Testern bedeutet, dass Sie sehr früh schlechte Annahmen und Fehler erkennen können, bevor sie Schaden anrichten können. Dies bedeutet auch, dass sich die Tester befähigt fühlen, beim Produktdesign zu helfen und Usability-Probleme zu erkennen, wenn Zeit ist, diese zu beheben.

5
Paddyslacker

Statische Analysewerkzeuge

Plugins und Apps wie FindBugs crawlen Ihren Code und finden Orte, an denen Potenzial Fehler vorhanden sind. Orte, an denen Variablen nicht initialisiert und verwendet werden oder nur verrückte Dinge, die 9 mal von 10 sind, erleichtern das Auftreten von Fehlern. Tools wie dieses helfen mir zu verhindern, dass sich mein Bonehead die Straße hinunter bewegt, auch wenn es noch kein Fehler ist.

P.: Denken Sie daran, immer zu recherchieren warum Ein Tool sagt Ihnen, dass etwas schlecht ist. Es tut nie weh zu lernen (und nicht alles ist in allen Situationen richtig).

4
Ryan Hayes

Code-Inspektion oder andere Formen der Peer-Review wie Paarprogrammierung.

Strukturierte Codeüberprüfungen wie die Fagan-Inspektion können mindestens so effektiv und effizient sein wie Unit-Tests und haben sich in einigen Fällen sogar als besser als Unit-Tests erwiesen. Inspektionen können auch früher im Software-Lebenszyklus und mit anderen Artefakten als Code verwendet werden.

Peer Reviews in Software von Karl Wiegers ist ein großartiges Buch zu diesem Thema.

3
Michael

Zusätzlich zu allen anderen Vorschlägen hier alle möglichen Warnungen mit höchster Empfindlichkeit aktivieren und als Fehler behandeln. Verwenden Sie auch alle Flusenwerkzeuge, über die die Sprache verfügt.

Sie wären erstaunt darüber, wie viele einfache Fehler durch Warnungen aufgefangen werden können und wie viele dieser einfachen Dinge zu echten Fehlern in Ihrem Code führen.

2
greyfade

Viele gute Antworten hier, aber ein paar Dinge, die ich hinzufügen wollte. Stellen Sie sicher, dass Sie die Anforderung tatsächlich verstehen. Ich habe viele Fehler gesehen, als der Benutzer dachte, die Anforderung bedeute X und der Programmierer dachte, sie bedeute Y. Drücken Sie zur Klärung schlechter oder mehrdeutiger Anforderungen zurück. Ich weiß, dass wir alle gerne einspringen und programmieren, aber je mehr Zeit im Voraus aufgewendet wird, um das Verständnis sicherzustellen, desto weniger Nacharbeit und Fehlerbehebung wird es geben.

Wenn Sie das Unternehmen kennenlernen, das Sie unterstützen, werden Sie häufig Dinge in Anforderungen sehen, die fehlen oder dann einer weiteren Erläuterung bedürfen. Wenn Sie Aufgabe Y wie angegeben ausführen, wird die vorhandene Funktion Z beschädigt.

Verstehen Sie Ihre Datenbankstruktur. Viele, viele Fehler sind das Ergebnis einer Abfrage, die syntaktisch korrekt ist, aber die falschen Ergebnisse zurückgibt. Erfahren Sie, wie Sie erkennen, wann Ihre Ergebnisse lustig aussehen. Wenn ich eine komplexe Berichtsabfrage schreibe, lässt ich meine Ergebnisse immer von einem technischen Spezialisten überprüfen, bevor ich sie als betriebsbereit markiere. In den Daten, die ich verpasst habe, wird unweigerlich etwas angezeigt. Machen Sie sich dann Notizen darüber, was sie gefangen haben, was Sie nicht getan haben, und denken Sie daran, dass Sie das nächste Mal etwas Ähnliches tun.

2
HLGEM

Ich folge der Praxis von Test-Code-Test anstelle von Code-Test-Code-Test. Dies hilft mir, über Anwendungsfälle nachzudenken und die Logik angemessen zu gestalten

1
viv

Überraschenderweise wurden die folgenden drei sehr wichtigen Punkte noch nicht erwähnt:

  • Verwenden Sie Behauptungen großzügig. Die Frage, die Sie sich immer stellen sollten, lautet nicht "soll ich das behaupten?" aber "gibt es etwas, das ich vergessen habe zu behaupten?"

  • Entscheiden Sie sich für Unveränderlichkeit. (Verwenden Sie final/readonly großzügig.) Je weniger veränderlicher Zustand Sie haben, desto weniger Dinge können schief gehen.

  • Nicht vorzeitig optimieren. Viele Programmierer werden mit Leistungsproblemen konfrontiert, was dazu führt, dass sie ihren Code unnötig verwickeln und ihre Designs bastardisieren, ohne vorher zu wissen, ob die Leistung ein Problem sein wird. Erstellen Sie Ihr Softwareprodukt zunächst auf akademische Weise, ohne Rücksicht auf die Leistung. Überprüfen Sie dann, ob die Leistung schlecht ist. (Dies wird wahrscheinlich nicht der Fall sein.) Wenn Leistungsprobleme auftreten, suchen Sie nach ein oder zwei Stellen, an denen Sie nette und formale algorithmische Optimierungen bereitstellen können, mit denen Ihr Produkt die Leistungsanforderungen erfüllt, anstatt Ihre gesamte Codebasis zu optimieren und zu hacken hier und da Taktzyklen drücken.

1
Mike Nakis

Verwenden Sie Code-Inspektionstools wie ReSharper oder IDEs wie IntelliJ IDEA , die vor vielen Kopier- und Warnmeldungen warnen -Paste Bugs und andere von z Auf Variablen hinweisen, die "geschrieben, aber nie gelesen" werden. Hat mir viel Zeit gespart.

1
DonJoe

Ich denke, die wichtigste Technik ist nimm dir Zeit. Wenn Sie der Meinung sind, dass Sie zwei Tage benötigen, um ein neues Modul zu codieren, Ihr Chef Sie jedoch zwingt, nur an einem Tag zu codieren, ist Ihr Code wahrscheinlich fehlerhafter.

In einem der Bücher, die ich vor einiger Zeit gelesen habe, heißt es, dass man nicht mit zerbrochenen Fenstern leben sollte, weil es den Leuten egal ist, ob ein anderer kaputt geht ... Die Codierung ist die gleiche, jeder wird sich darum kümmern der Erste zu sein, der etwas tut schlecht, aber schnell, aber keiner wird sich um einen kümmern Höllencode, mit vielen Fehlern und sehr schlechtem Design und Stil.

1
greuze