Wie kann die Anzahl der Fehler beim Codieren verringert werden?

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

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

Verwenden Sie verfügbare Bibliotheken. Die einfachste Möglichkeit, 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. Idealerweise sollten Sie einige Beweistechniken kennen. Wenn ich nachweisen kann, dass der Code korrekt ist, ist er fast immer gut, außer für große, dumme, offensichtliche Fehler, die leicht zu beheben sind. Natürlich geht das nur so weit, aber manchmal kann man formell über kleine, aber komplizierte Dinge nachdenken.

Erfahren Sie, wie Sie bei vorhandenem Code eine Umgestaltung durchführen: wie Sie kleine Änderungen am Code vornehmen, häufig mithilfe eines automatisierten Tools, mit dem der Code besser lesbar wird, ohne das Verhalten zu ändern.

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

Sobald Sie den Code geschrieben haben, verwenden Sie, was Sie haben, um es gut zu machen. Unit-Tests sind großartig. Sie können häufig Tests vorab schreiben, was ein großartiges Feedback sein kann (wenn dies konsequent durchgeführt wird, ist dies eine testgetriebene Entwicklung). Kompilieren Sie mit Warnoptionen und beachten Sie die Warnungen.

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

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

+1 für beide Kommentare zum Komponententest.

Stellen Sie darüber hinaus die höchste Warnstufe ein, die Ihr Compiler anbietet, und stellen Sie sicher, dass Warnungen als Fehler behandelt werden. Fehler verbergen sich oft in diesen "fehlerhaften" Fehlern.

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

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

• Ignorieren Sie keine Fehlercodes - nehmen Sie beispielsweise nicht an, dass Sie ein gültiges Ergebnis erhalten haben, dass eine Datei erfolgreich erstellt wurde usw. ... Eines Tages wird etwas passieren.
• Gehen Sie nicht davon aus, dass Ihr Code niemals eine Bedingung eingibt und dass es daher sicher ist, diese Bedingung zu ignorieren.
• Testen Sie Ihren Code und lassen Sie ihn dann 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. :)

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

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

Ich sage meinen Mitarbeitern auch gerne, dass jede Filiale (wenn, für, während,? :) ein wahrscheinlicher Fehler ist. Ich kann nicht sagen, wie sich der Fehler manifestieren wird, aber je weniger bedingt Ihr Code sich verhält, desto wahrscheinlicher ist es, dass er fehlerfrei ist, allein aufgrund der Tatsache, dass die Codeabdeckung während der Ausführung konsistenter ist.

Das alles hat natürlich auch positive Auswirkungen auf die Leistung. Sieg!

• Schreiben Sie weniger Code, der mehr bewirkt.
• Denken Sie über die Auswirkungen auf niedriger Ebene und die Auswirkungen auf hoher Ebene nach
• Betrachten Sie die Abstraktion, die Sie in Ihrem Code erstellen.
• Schreiben Sie nach Möglichkeit nur die wesentliche Komplexität.

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

Schreiben Sie Komponententests und Integrationstests .

Einige gute Antworten hier in Bezug auf Unit-Tests und Tools. Das einzige, was ich ihnen hinzufügen kann, ist Folgendes:

Binden 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 binden Sie sie so früh wie möglich ein (bei agilen Projekten wird dies von Anfang an der Fall sein, 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ühe Builds, mit 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 schlechte Annahmen und Mängel frühzeitig 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 zur Behebung ist.

Statische Analyse-Tools

Plugins und Apps wie FindBugs crawlen Ihren Code und finden Orte, an denen potenzielle Fehler auftreten können. Orte, an denen Variablen nicht initialisiert und verwendet werden, oder einfach nur verrückte Dinge, die neun Mal von zehn sind, machen das Auftreten von Fehlern einfacher. Mit Tools wie diesen kann ich verhindern, dass mein Knochenkopf die Straße hinunterfährt, auch wenn es noch kein Fehler ist.

PS: Denken Sie daran, immer zu untersuchen, warum ein Tool Ihnen sagt, dass etwas schlecht ist. Es tut nie weh zu lernen (und nicht in allen Situationen stimmt alles).

Code-Inspektion oder andere Formen von Peer-Review, z. B. Paarprogrammierung.

Strukturierte Code-Reviews 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 durchgeführt werden.

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

Aktivieren Sie zusätzlich zu allen anderen Vorschlägen hier alle möglichen Warnungen mit höchster Empfindlichkeit und behandeln Sie sie als Fehler. Verwenden Sie auch alle Flusenwerkzeuge, die in der Sprache verfügbar sind.

Sie werden erstaunt sein, wie viele einfache Fehler durch Warnungen abgefangen werden können und wie viele dieser einfachen Dinge sich in echten Fehlern in Ihrem Code niederschlagen.

Viele gute Antworten hier, aber ein paar Dinge, die ich hinzufügen wollte. Stellen Sie sicher, dass Sie die Anforderung wirklich 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 Vorfeld für das Verständnis aufgewendet wird, desto weniger Nacharbeit und Fehlerbehebung wird es geben.

Lernen Sie das Unternehmen kennen, das Sie unterstützen. Oft sehen Sie Dinge in Anforderungen, die fehlen oder dann einer weiteren Erläuterung bedürfen. Wenn Sie Aufgabe Y wie angegeben ausführen, wird das vorhandene Feature Z beschädigt.

Verstehen Sie Ihre Datenbankstruktur. Viele, viele Fehler sind das Ergebnis einer syntaktisch korrekten Abfrage, die jedoch die falschen Ergebnisse zurückgibt. Erfahren Sie, wie Sie erkennen, wann Ihre Ergebnisse lustig aussehen. Wenn ich eine komplexe Berichtsabfrage schreibe, lasse ich meine Ergebnisse immer von einem technischen Spezialisten überprüfen, bevor ich sie als betriebsbereit markiere. Die Daten, die ich verpasst habe, enthalten zwangsläufig etwas. Machen Sie sich dann Notizen darüber, was Sie nicht bemerkt haben, und denken Sie daran, dass Sie beim nächsten Mal etwas Ähnliches tun.

Ich denke, die wichtigste Technik ist , sich Zeit zu nehmen . Wenn Sie der Meinung sind, dass Sie zwei Tage brauchen, um ein neues Modul zu codieren, aber Ihr Chef Sie zwingt, nur an einem Tag zu codieren, ist Ihr Code wahrscheinlich fehlerhafter.

Eines der Bücher , die ich vor einiger Zeit gelesen , sagte, dass Sie mit nicht leben sollten zerbrochene Fensterscheiben , weil die Menschen sich nicht darum kümmern , wenn anotherone kaputt geht ... Codierung die gleiche ist, jeder der ersten über das Sein in etwas zu tun , kümmern wird schlecht aber schnell , aber keiner kümmert sich um einen Höllencode mit vielen Fehlern und sehr schlechtem Design und Stil.

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

Verwenden Sie Tools zur Codeinspektion wie ReSharper oder IDEs wie IntelliJ IDEA , die vor vielen Fehlern beim Kopieren und Einfügen und anderen warnen, indem Sie z. B. auf Variablen hinweisen, die "geschrieben, aber nie gelesen" werden. Hat mir viel Zeit gespart.

Ü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. (Benutze final / readonly liberal.) Je weniger veränderlicher Zustand du hast, desto weniger Dinge können schief gehen.

• Optimieren Sie nicht vorzeitig. Viele Programmierer werden mit Leistungsproblemen konfrontiert, was dazu führt, dass sie ihren Code unnötig verschachteln und ihre Entwürfe verfälschen, ohne vorher zu wissen, ob Leistung ein Problem sein wird. Erstellen Sie Ihr Softwareprodukt zunächst auf akademische Weise, ohne Rücksicht auf die Leistung. Prüfen Sie dann, ob die Leistung schlecht ist. (Dies wird wahrscheinlich nicht der Fall sein.) Wenn es Leistungsprobleme gibt, suchen Sie eine oder zwei Stellen, an denen Sie nette und formale algorithmische Optimierungen vornehmen können, damit Ihr Produkt die Leistungsanforderungen erfüllt, anstatt Ihre gesamte Codebasis zu optimieren und zu hacken Quetsch-Taktzyklen hier und da.