Wie kann man ein Null-Fehler-Programmierer sein? [geschlossen]

Mein Chef hat mir immer gesagt, dass ein guter Programmierer sicherstellen sollte, dass der Code, den er oder sie ändert, zuverlässig, korrekt und gründlich selbst verifiziert ist. dass Sie alle Ergebnisse und Auswirkungen, die Ihre Änderungen verursachen, vollständig verstehen sollten. Ich habe mein Bestes gegeben, um diese Art von Programmierer zu sein - indem ich immer wieder Tests durchführte -, aber es gibt immer noch Fehler.

Wie kann ich ein Null-Fehler-Programmierer sein und wissen, was jedes Zeichen meines Codes verursacht und beeinflusst?

Code überhaupt nicht.

Nur so können Sie ein Null-Fehler-Programmierer sein.

Fehler sind unvermeidlich, weil Programmierer menschlich sind. Wir können nur unser Bestes tun, um sie zu verhindern, schnell auf Fehler zu reagieren, aus unseren Fehlern zu lernen und auf dem Laufenden zu bleiben.

Null Fehler ist für ein nicht triviales Programm unmöglich.

Es ist möglich, sehr nahe zu kommen, aber die Produktivität leidet. Und es lohnt sich nur für bestimmte risikoreiche Software. Mir fällt die Space-Shuttle-Software ein . Ihre Produktivität liegt jedoch in der Größenordnung von einigen Zeilen pro Tag. Ich bezweifle, dass Ihr Chef das will.

Diese Software ist fehlerfrei. Es ist perfekt, so perfekt wie die Menschen es erreicht haben. Betrachten Sie diese Statistiken: Die letzten drei Versionen des Programms - jeweils 420.000 Zeilen lang - hatten jeweils nur einen Fehler. Die letzten 11 Versionen dieser Software hatten insgesamt 17 Fehler.

Nehmen Sie das Upgrade der Software vor, damit das Shuttle mit Global Positioning Satellites navigieren kann. Diese Änderung betrifft nur 1,5% des Programms oder 6.366 Codezeilen. Die Spezifikationen für diese eine Änderung umfassen 2.500 Seiten, ein Volumen, das dicker ist als ein Telefonbuch. Die Spezifikationen für das aktuelle Programm füllen 30 Bände und umfassen 40.000 Seiten.

"Zero-Bug-Programmierer" ist ein Oxymoron wie ein stiller Sänger, aber in den letzten 60 Jahren hat das Programmieren einiges an Weisheit hervorgebracht, was Sie zu einem besseren Programmierer macht, wie zum Beispiel:

• Sei demütig - du bist und wirst Fehler machen. Wiederholt.
• Seien Sie sich der begrenzten Größe Ihres Schädels voll bewusst. Nähere dich der Aufgabe mit voller Demut und vermeide clevere Tricks wie die Pest. [Edsger Dijkstra]
• Kampf kombinatorische Explosion
• Werden Sie den veränderlichen Zustand los (wo immer möglich). Ja, funktionale Programmierung lernen.
• Reduzieren Sie die Anzahl der möglichen Codepfade
• Verstehen Sie die Größe der Eingabe- und Ausgabebereiche (Ihrer Funktionen) und versuchen Sie, sie zu reduzieren, um eine Testabdeckung von 100% zu erreichen
• Gehen Sie immer davon aus, dass Ihr Code nicht funktioniert - beweisen Sie es anders!

TDD

Der Punkt von TDD ist, dass Sie keine einzige Codezeile schreiben, wenn es keinen Test gibt, der diese Codezeile erfordert. Um es auf das Äußerste zu bringen, beginnen Sie immer mit der Entwicklung einer neuen Funktion, indem Sie einen Abnahmetest schreiben. Hier habe ich festgestellt, dass das Schreiben von Gurkenstiltests ideal ist.

Der TDD-Ansatz bietet mindestens zwei Vorteile.

• Der gesamte Code wurde geschrieben, um eine bestimmte Funktion zu lösen, sodass keine unnötige Überproduktion auftritt.
• Wenn Sie eine vorhandene Codezeile ändern und eine Funktion stören, werden Sie benachrichtigt

Es beweist nicht, dass es keine Bugs gibt, da dies unmöglich wäre (worauf bereits unzählige andere Antworten hingewiesen haben). Aber nachdem ich TDD gelernt habe und gut darin bin (ja, es ist auch eine Fähigkeit, die Übung erfordert), habe ich ein viel höheres Vertrauen in meinen eigenen Code, da er gründlich getestet wurde. Und was noch wichtiger ist, ich kann vorhandenen Code, den ich nicht vollständig verstehe, ändern, ohne mir Gedanken über die Funktionsstörung zu machen.

Aber TDD hilft Ihnen nicht weiter. Sie können keinen fehlerfreien Code schreiben, wenn Sie die Architektur des Systems und die Fallstricke dieser Architektur nicht genau kennen. Wenn Sie beispielsweise eine Webanwendung schreiben, die mehrere Anforderungen gleichzeitig verarbeitet, müssen Sie wissen, dass Sie keine veränderlichen Daten für mehrere Anforderungen freigeben können.

Ich glaube, dass die Entwicklungsteams, die bei TDD gut sind, den Code mit den wenigsten Fehlern liefern.

Die Sache ist, Bugs sind die Dinge, die Sie nicht erkennen. Wenn Sie keine enzyklopädischen Kenntnisse der Programmiersprache / des Compilers sowie sämtlicher Umgebungen haben, in denen Ihre Anwendung ausgeführt wird, können Sie wirklich nicht damit rechnen, 100% fehlerfreien Code zu produzieren.

Sie können Ihre Fehleranzahl durch viele Tests reduzieren, aber am Ende wird es wahrscheinlich einen Randfall geben, der nicht berücksichtigt wird. Joel Spolsky hat einen besonders schönen Artikel über die Fehlerbehebung geschrieben .

Ja, es ist unmöglich, niemals einen Fehler in Ihrem Code zu haben, aber es ist nicht unmöglich, weniger Fehler zu haben. Die Einstellung "Das ist dumm, Sie werden immer Fehler haben" ist nur ein Hinweis, um die Anzahl der Fehler in Ihrem Code nicht zu verringern. Niemand ist perfekt, aber wir können und sollten uns bemühen, besser zu werden. In meinen eigenen Bemühungen, mich zu verbessern, fand ich die folgenden Punkte hilfreich.

• Das ist nicht einfach. Sie werden sich über Nacht nicht verbessern. Lassen Sie sich also nicht entmutigen und geben Sie nicht auf.
• Schreiben Sie weniger und schreiben Sie schlauer. Weniger Code ist normalerweise besserer Code. Es ist natürlich, vorausplanen zu wollen und fantastische Designmuster zu erstellen, aber auf lange Sicht spart es Zeit und beugt Fehlern vor, nur das zu schreiben, was Sie brauchen.
• Komplexität ist der Feind. Weniger zählt nicht, wenn es sich um ein undurchsichtiges, kompliziertes Durcheinander handelt. Codegolf macht Spaß, aber es ist eine Hölle zu verstehen und eine schlimmere Hölle zu debuggen. Wann immer Sie komplizierten Code schreiben, öffnen Sie sich selbst für eine Welt voller Probleme. Halte die Dinge einfach und kurz.
• Komplexität ist subjektiv. Code, der einmal kompliziert war, wird einfach, sobald Sie ein besserer Programmierer werden.
• Erfahrung ist wichtig. Eine der beiden Möglichkeiten, ein besserer Programmierer zu werden, ist das Üben. Übung ist NICHT, Programme zu schreiben, die man leicht schreiben kann, sondern Programme, die ein wenig weh tun und zum Nachdenken anregen.
• Der andere Weg, um besser zu werden, ist zu lesen. Es gibt viele schwierige Themen im Programmieren zu lernen, aber Sie werden sie niemals durch einfaches Programmieren lernen können, Sie müssen sie studieren. Sie müssen die harten Sachen lesen. Es ist unmöglich, Dinge wie Sicherheit und Parallelität richtig zu lernen, wenn Sie nur Code schreiben, es sei denn, Sie möchten durch Bereinigen von Katastrophen lernen. Wenn Sie mir nicht glauben, schauen Sie sich die epischen Sicherheitsprobleme an, die Gawker hatte. Wenn sie sich die Zeit genommen hätten, um zu lernen, wie man Sicherheit richtig macht und nicht nur etwas, das funktioniert, wäre dieses Chaos niemals passiert.
• Blogs lesen. Es gibt eine Menge interessanter Blogs, die Ihnen neue und interessante Möglichkeiten bieten, sich Programme anzuschauen und darüber nachzudenken. Dies wird Ihnen dabei helfen, ...
• Lerne die schmutzigen Details. Die kleinen Details darüber, wie undurchsichtig Teile Ihrer Sprache und Ihrer Anwendung sind, sind sehr wichtig. Sie können Geheimnisse enthalten, die Ihnen helfen, komplizierten Code nicht zu schreiben, oder Teile, die eigene Fehler enthalten, die Sie vermeiden müssen.
• Erfahren Sie, wie die Benutzer denken. Manchmal sind Ihre Benutzer völlig verrückt und arbeiten mit Ihrer App auf eine Weise, die Sie nicht verstehen und nicht vorhersagen können. Sie müssen sich genug in den Kopf setzen, um die fremden Dinge zu kennen, die sie versuchen könnten, und um sicherzustellen, dass Ihre App damit umgehen kann.

Persönlich denke ich, dass das Streben nach fehlerfreier Programmierung teurer zu sein scheint (sowohl in Bezug auf Zeit als auch in Bezug auf Geld). Um einen Fehler von Null oder nahezu Null zu erreichen, müssen die Entwickler gründliche Tests durchführen. Dies bedeutet, dass Sie alles einer Regression unterziehen müssen, bevor Sie den Code zur Überprüfung des Patches einreichen. Dieses Modell scheint mir nicht kosteneffektiv zu sein. Es ist besser, wenn die Entwickler sorgfältige Tests durchführen und die eingehenden Tests dem QA-Team überlassen. Hier ist warum:

• Entwickler saugen am Testen. Es ist wahr und du weißt es. (Ich bin ein Entwickler!) Ein gutes QA-Team findet immer die Randfälle, an die Entwickler niemals denken.
• Entwickler können gut programmieren. Lassen Sie sie zu dem zurückkehren, was sie am besten können (und normalerweise auch, was sie am liebsten tun).
• Das QA-Team kann in einem Durchgang Fehler im Zusammenhang mit mehreren Entwickleraufgaben finden.

Akzeptieren Sie, dass beim Schreiben von Code Fehler protokolliert werden. Aus diesem Grund gibt es einen QS-Prozess, und das gehört dazu, Entwickler zu sein. Das heißt natürlich nicht, dass Sie etwas einreichen, sobald Sie Ihr letztes Semikolon geschrieben haben. Sie müssen immer noch die Qualität Ihrer Arbeit sicherstellen, aber Sie können es übertreiben.

Wie viele Berufe können Sie nennen, die ihre Aufgabe immer gleich beim ersten Mal ohne Begutachtung und / oder Prüfung richtig erledigen?

Null Fehler? Es hört sich so an, als ob Sie Lisp brauchen (folgen Sie dem skeptischen Pfad und meiden Sie das Musikvideo).

In den gängigen Codierungsumgebungen (Java, C #, PHP usw.) ist es außerordentlich schwierig, fehlerfreien Code zu erzielen. Ich würde mich darauf konzentrieren , gut getesteten und von Experten geprüften Code in kurzen kontrollierten Iterationen zu erstellen .

Wenn Sie den Code so einfach wie möglich halten, können Sie Fehler vermeiden.

Stellen Sie sicher, dass Sie Codeanalyse-Tools (wie FindBugs , PMD usw.) verwenden, die in Kombination mit strengen Compiler-Warnungen alle möglichen Probleme mit Ihrem Code aufdecken. Notieren Sie sich, was sie Ihnen sagen, und bemühen Sie sich wirklich, die Art des Fehlers zu verstehen. Führen Sie dann Schritte aus, um Ihre Programmiersprache so zu ändern, dass es sich unnatürlich anfühlt, auf eine Weise zu codieren, die diesen Fehler erneut verursacht.

Alle "Überhaupt nicht codieren." Bei den Antworten fehlt der Punkt völlig. Außerdem scheint Ihr Chef definitiv kein Idiot zu sein!

Ich kann mich nicht erinnern, wie oft ich Programmierer gesehen habe, die einfach nicht wussten, was ihr Code tut. Ihre einzige Entwicklungsphilosophie schien Versuch und Irrtum zu sein (und nicht selten auch Kopieren / Einfügen / Ändern). Obwohl Versuch und Irrtum ein guter Weg ist, um einige Probleme zu lösen, können Sie häufig die Problemdomäne analysieren und dann eine sehr spezifische Lösung anwenden, die auf Ihrem Verständnis der von Ihnen verwendeten Tools und ein wenig Disziplin und Sorgfalt basiert, über die Sie nicht verfügen Nur das Problem wurde behoben, aber auch die meisten Eckfälle (potenzielle Fehler), bevor Sie es zum ersten Mal bereitstellen. Können Sie garantieren, dass der Code fehlerfrei ist? Natürlich nicht. Aber mit jedem Fehler, auf den Sie stoßen oder über den Sie lesen, können Sie ihn zu den Dingen hinzufügen, über die Sie beim nächsten Schreiben / Ändern nachdenken möchten. Wenn Sie dies tun, werden Sie folglich viel Erfahrung mit dem Schreiben von Code sammeln, der fast fehlerfrei ist. - Es gibt jede Menge Ressourcen, um ein besserer Programmierer zu werden, der Ihnen auf dem Weg helfen kann ...

Persönlich würde ich niemals Code schreiben, bei dem ich nicht jede einzelne Zeile erklären kann. Jede Zeile hat einen Grund, dort zu sein, ansonsten sollte sie entfernt werden. Natürlich werden Sie manchmal Annahmen über das Innenleben der von Ihnen aufgerufenen Methoden treffen, andernfalls müssen Sie die innere Logik des gesamten Frameworks kennen.

Ihr Chef sagt zu Recht, dass Sie die Ergebnisse und Auswirkungen des Codes verstehen sollten, den Sie auf ein vorhandenes System schreiben. Werden Fehler auftreten? Ja natürlich. Diese Fehler sind jedoch darauf zurückzuführen, dass Sie die Systeme / Tools, mit denen Sie arbeiten, nicht vollständig verstanden haben und mit jeder Fehlerbehebung eine bessere Abdeckung erhalten.

Wie die anderen Kommentare bereits richtig gezeigt haben, gibt es keine nicht-triviale Software ohne Bugs.

Wenn Sie die Software testen möchten, denken Sie immer daran, dass Tests nur das Vorhandensein von Fehlern und nicht deren Abwesenheit beweisen können.

Abhängig von Ihrer Arbeitsdomäne können Sie versuchen, Ihre Software formal zu verifizieren. Mit formalen Methoden können Sie sich ziemlich sicher sein, dass Ihre Software genau den Spezifikationen entspricht.

Das bedeutet natürlich nicht, dass die Software genau das tut, was Sie wollen. Das Schreiben einer vollständigen Spezifikation ist in fast allen Fällen ebenfalls nicht möglich. Es verschiebt im Grunde die Stelle, an der Fehler auftreten können, von der Implementierung zur Spezifikation.

Abhängig von Ihrer Definition von "Bugs" können Sie eine formale Überprüfung versuchen oder einfach versuchen, so viele Bugs wie möglich in Ihrer Software zu finden.

Entweder schreibe nichts komplizierteres als "Hallo Welt!" oder wenn Sie jedem sagen, dass er es niemals benutzen soll.

Fragen Sie Ihren Chef nach Beispielen für diesen sogenannten fehlerfreien Code.

Ich stimme den anderen zu. Hier ist, wie ich das Problem angehen würde

• Holen Sie sich einen Tester. Lesen Sie den Joel-Test, warum.
• Verwenden Sie Bibliotheken ausgiebig. die wurden wohl besser debuggt. Ich bin ein großer Fan von CPAN für Perl.

Sie können sich bemühen, ein Null-Fehler-Programmierer zu sein. Ich bemühe mich, ein Null-Fehler-Programmierer zu sein, wenn ich Code schreibe. Das tue ich jedoch nicht

• mehrere Testtechniken anwenden (außer ATDD)
• Erstellen Sie formelle Überprüfungen unserer Software
• ein separates QA-Team haben
• Analysieren Sie jede an der Codebasis vorgenommene Änderung gründlich
• Verwenden Sie eine Sprache, die mehr auf Sicherheit und Vorsicht abzielt

Ich mache diese Dinge nicht, weil sie für die Software, die ich schreibe, unerschwinglich sind. Wenn ich diese Dinge tun würde, wäre ich wahrscheinlich auf dem Weg zu null Bugs, aber das würde geschäftlich keinen Sinn ergeben.

Ich erstelle interne Tools, die ein großer Teil unserer Infrastruktur nutzt. Meine Standards für das Testen und Codieren sind hoch. Es besteht jedoch ein Gleichgewicht. Ich erwarte keine Null-Fehler, weil ich nicht zulassen kann, dass Leute diese Zeit in eine Arbeit stecken. Die Dinge könnten anders sein, wenn ich die Software zur Steuerung eines Röntgengeräts, von Strahltriebwerken usw. erstellt habe. Wenn meine Software kaputt geht, ist kein Leben in Sicht.

Ich würde den Grad der Sicherheit an den Verwendungszweck der Software anpassen. Wenn Sie Code schreiben, den das NASA-Shuttle verwendet, ist eine Fehlertoleranz von möglicherweise Null sinnvoll. Sie müssen nur eine Reihe zusätzlicher und sehr teurer Methoden hinzufügen.

Ich denke, ein guter erster Schritt, um ein "Null-Fehler" -Programmierer zu werden, besteht darin, Ihre Einstellung gegenüber Fehlern zu ändern. Anstatt Dinge zu sagen "sie passieren", "bessere Qualitätssicherung und Tester" oder "Entwickler saugen am Testen", sagen Sie:

Bugs sind nicht akzeptabel und ich werde alles in meiner Macht Stehende tun, um sie zu beseitigen.

Sobald dies Ihre Einstellung wird, werden die Fehler schnell fallen. Auf der Suche nach Möglichkeiten zur Beseitigung von Fehlern stoßen Sie auf eine testgetriebene Entwicklung. Hier finden Sie viele Bücher, Blogposts und Leute, die kostenlose Ratschläge zu besseren Techniken anbieten. Sie werden erkennen, wie wichtig es ist, Ihre Fähigkeiten durch Übung zu verbessern (z. B. Katas zu programmieren oder zu Hause neue Dinge auszuprobieren). Sie werden anfangen, bei der Arbeit bessere Leistungen zu erbringen, weil Sie zu Hause an Ihrem Handwerk arbeiten . Und hoffentlich , wenn Sie sehen , dass es ist möglich , eine gute Software zu schreiben, wird Ihre Leidenschaft für Ihr Handwerk wachsen.

In gewisser Hinsicht hat Ihr Chef recht. Es ist möglich, Software zu schreiben, die sich null Fehlern nähert.

Das Problem ist jedoch, dass die Kosten für das Schreiben von (fast) Null-Fehler-Programmen unerschwinglich hoch sind . Sie müssen Dinge tun wie:

• Verwenden Sie formale Spezifikationen Ihrer Anforderungen. Formal, wie bei Verwendung von Z oder VDM oder einer anderen mathematisch fundierten Notation.

• Verwenden Sie Theorembeweisungstechniken, um formal zu beweisen, dass Ihr Programm die Spezifikation implementiert.

• Erstellen Sie umfangreiche Einheiten-, Regressions- und Systemtestsuiten und -gurte, um auf jede Art und Weise auf Fehler zu testen. (Und das allein reicht nicht aus.)

• Lassen Sie viele Personen die Anforderungen (formell und informell), die Software (und die Nachweise) überprüfen. Tests und Bereitstellungen.

Es ist äußerst unwahrscheinlich, dass Ihr Chef bereit ist, für all das zu bezahlen ... oder die Zeit in Kauf zu nehmen, die erforderlich ist, um alles zu erledigen.

Ich habe den Status "Null Fehler" erreicht. Ich sage meinen Benutzern, dass es sich um eine nicht dokumentierte Funktion handelt, oder dass sie nach einer neuen Funktion fragen, und daher handelt es sich um eine Verbesserung. Wenn keine dieser Antworten akzeptiert wird, sage ich ihnen nur, dass sie ihre eigenen Anforderungen nicht verstanden haben. Somit gibt es keine Bugs. Programmierer sind perfekt.

Hier sind die Schritte, um ein fehlerfreies Programm zu erstellen:

1. Beginnen Sie niemals mit dem Codieren, es sei denn, Sie haben EINMALIGE SPEZIFIKATIONEN für Ihre Funktionalität.
2. TESTEN SIE NICHT, oder, falls Sie dies nicht tun, VERLASSEN SIE SICH NICHT AUF DAS TESTEN, um Fehler in der Software festzustellen.
3. Wenden Sie alle FEEDBACKs, die bei Tests, Überprüfungen und der Produktion aufgetreten sind, auf einen Prozess und Entwickler an, die den Fehler an erster Stelle eingefügt haben. Entsorgen Sie alle defekten Komponenten vollständig, sobald Defekte festgestellt werden. Aktualisieren Sie Ihre Checklisten und schulen Sie Ihre Entwickler neu, damit sie solche Fehler nicht noch einmal machen.

Testen kann nur beweisen, dass Sie Fehler haben, aber es ist normalerweise sinnlos, das Gegenteil zu beweisen. In Bezug auf die Rückmeldung - wenn Sie einen Münzautomaten haben, der Münzen herstellt, und durchschnittlich jede 10-Sekunden-Münze einen Defekt aufweist. Sie können diese Münze nehmen, flach drücken und wieder in den Automaten einwerfen. Eine Münze, die den recycelten Rohling erkennen lässt, ist nicht so gut, aber akzeptabel. Jede 100er Münze muss 2 Mal neu gestempelt werden und so weiter. Wäre es einfacher, die Maschine zu reparieren?

Leider sind Menschen keine Maschinen. Um einen guten, fehlerfreien Programmierer zu erstellen, muss viel Zeit investiert, trainiert und jeder gemachte Fehler durchlaufen werden. Entwickler müssen in formalen Überprüfungsmethoden geschult werden, die in der Praxis oft schwer zu erlernen und anzuwenden sind. Die Ökonomie der Softwareentwicklung wirkt auch dem entgegen. Würden Sie 2 Jahre in die Ausbildung eines Programmierers investieren, der weniger Fehler machen kann, nur um zu sehen, wie er zu einem anderen Arbeitgeber wechselt? Sie können Maschinen kaufen, die perfekte Münzen herstellen, oder 10 weitere Code-Affen mieten, um eine Reihe von Tests zu denselben Kosten zu erstellen. Sie können diesen umfassenden Prozess als Ihre "Maschine" betrachten, Ihr Kapital - es lohnt sich nicht, in eine umfassende Schulung exzellenter Entwickler zu investieren.

Ziemlich bald werden Sie lernen, wie man Software von akzeptabler Qualität entwickelt, aber wahrscheinlich werden Sie nie einer sein, der fehlerfrei ist, aus dem einfachen Grund, dass es keinen Markt für Entwickler gibt, die perfekten Code erstellen, weil dieser langsam ist.

Defensiv programmieren: http://en.wikipedia.org/wiki/Defensive_programming

Wenn jemand die Konventionen der defensiven Programmierung befolgt, sind Änderungen leicht nachvollziehbar. Kombinieren Sie dies mit strengen Fehlerberichten während der Entwicklung und einer soliden Dokumentation wie bei doxygen, und Sie sollten in der Lage sein, genau zu wissen, was der gesamte Code tut, und alle auftretenden Fehler sehr effizient zu beheben.

Könnte dies ein Ergebnis eines Missverständnisses einer guten Methodik sein, und nicht nur eines generischen Schnickschnack?

Ich meine, es ist möglich, dass Ihr Chef von der "Null-Fehler-Methode" (siehe Abschnitt 5) gehört hat und sich nicht darum gekümmert hat, zu verstehen, was das bedeutet.
Natürlich ist es für das Management unpraktisch, die Entwicklung neuer Funktionen zu verschieben, und zwar zugunsten von Fehlern, die Sie nicht hätten einbauen sollen ...
Und natürlich gefährdet dies seinen Bonus, so dass Sie natürlich keinen bekommen, weil "gute Programmierer dies nicht tun habe Fehler "...

Es ist in Ordnung , Fehler zu machen , solange man sie findet und behebt (natürlich im Rahmen des Zumutbaren).

Eines der grundlegenden Konzepte beim Testen von Software ist, dass Sie NIEMALS absolut sicher sein können, dass das Programm perfekt ist. Sie können es für immer validieren, aber das beweist nie, dass das Programm vollständig ist, da es schnell unmöglich wird, alle Eingabe- / Variablenkombinationen zu testen.

Ihr Chef scheint einer von denen zu sein, die "nicht verstehen, was so schwer mit Programmieren ist, da es nur Tippen ist"

Wenn wir davon ausgehen, dass große Softwarehäuser wissen, wie man erstklassige Entwickler (wie in Zero-Bugs-Programmierern ) bekommt, können wir davon ausgehen, dass die Software von Microsoft fehlerfrei sein muss . Wir wissen jedoch, dass dies weit von der Wahrheit entfernt ist.

Die Entwickler entwickeln ihre Software und sobald sie ein bestimmtes Level an Fehlern mit niedriger Priorität erreichen, geben sie einfach das Produkt frei und beheben diese später.

Wenn Sie nicht etwas Komplexeres als einen einfachen Taschenrechner entwickeln, können Sie Fehler nicht alle zusammen vermeiden. Zur Hölle, sogar die NASA hat Redundanz in ihren Fahrzeugen und auch in ihren Bugs. Obwohl sie viele strenge Tests haben, um katastrophale Ausfälle zu vermeiden. Trotzdem haben selbst sie Fehler in ihrer Software.

Fehler sind unvermeidlich, genauso wie es die menschliche Natur ist, Fehler zu machen.

Keine Bugs zu haben ist wie ein 100% sicheres System. Wenn ein System zu 100% sicher ist, ist es definitiv nicht mehr nützlich (es liegt wahrscheinlich in Tonnen und Tonnen Beton und ist überhaupt nicht mit der Außenwelt verbunden. Weder verkabelt noch drahtlos. Genauso wenig gibt es ein perfekt sicheres System , es gibt kein komplexes fehlerfreies System.

Ich sehe nur Antworten darüber, dass wir menschlich und anfällig für Irrtümer sind, was sehr richtig ist ... aber ich sehe Ihre Frage aus einem anderen Blickwinkel.

Ich denke, Sie können fehlerfreie Programme schreiben, aber das sind normalerweise Programme, die Sie bereits 10 oder 12 Mal geschrieben haben. Wenn Sie das gleiche Programm zum 13. Mal von Grund auf neu schreiben, wissen Sie bereits, wie es geht: Sie kennen das Problem, Sie kennen die Techniken, Sie kennen die Bibliotheken, die Sprache ... Sie sehen es in Ihrem Kopf. Alle Muster sind auf allen Ebenen vorhanden.

Das passiert mir mit sehr einfachen Programmen, weil ich Programmierung unterrichte. Sie sind einfach für mich, aber schwer für die Schüler. Und ich spreche nicht von Lösungen für Probleme, die ich schon oft an der Tafel gemacht habe. Natürlich kenne ich die. Ich meine ~ 300-Zeilen-Programme, die etwas mit Begriffen lösen, die ich wirklich gut kenne (die Konzepte, die ich unterrichte). Ich schreibe diese Programme ohne Planung und sie funktionieren einfach und ich habe das Gefühl, dass ich alle Details kenne und TDD überhaupt nicht brauche. Ich bekomme ein paar oder drei Kompilierungsfehler (meist Tippfehler und ähnliches) und das wars. Ich kann das für kleine Programme tun, und ich glaube auch, dass manche Leute das für kompliziertere Programme tun können. Ich denke, Leute wie Linus Torvalds oder Daniel J. Bernstein sind so klar im Kopf, dass sie einem fehlerfreien Programmierer am nächsten kommen. Wenn duVerstehe die Dinge tief, ich denke du schaffst es. Ich kann das nur für einfache Programme machen, wie ich schon sagte.

Ich glaube, wenn Sie immer versuchen, Programme zu erstellen, die weit über Ihrem Niveau liegen (ich habe Jahre damit verbracht, genau das zu tun), werden Sie verwirrt und machen Fehler. Große Fehler wie die, bei denen Sie plötzlich feststellen, dass Ihre Lösung nicht funktionieren kann, wenn Sie das Problem endlich verstehen und Änderungen vornehmen müssen, die Sie möglicherweise daran hindern, Ihr Problem zu lösen oder den Code schrecklich zu machen. TDD ist für diese Fälle, glaube ich. Sie wissen, dass Sie das Problem, mit dem Sie sich befassen, nicht in den Griff bekommen, und führen daher überall Tests durch, um sicherzustellen, dass Sie eine starke Basis haben. TDD löst jedoch nicht die 10.000-Fuß-Vision. Sie können die ganze Zeit in Kreisen mit perfekt sauberem Code laufen.

Wenn Sie jedoch versuchen, etwas Neues zu tun, das sich jedoch knapp über Ihrem Niveau befindet, erhalten Sie möglicherweise ein perfektes oder fast perfektes Programm. Ich denke, es ist wirklich schwierig zu wissen, welche Programme sich in Ihrer "Wissensgrenze" befinden, aber theoretisch ist dies der beste Weg, um zu lernen. Eigentlich schreibe ich viele Programme von Grund auf neu. Einige Leute tun es, aber Sie brauchen viel Zeit und Geduld, denn wenn Sie ein nicht triviales Programm zum dritten Mal wiederholen, werden Sie nicht so aufgeregt wie beim ersten Mal.

Mein Rat ist also: Denken Sie nicht, dass Sie etwas verstehen, bis Sie ein fehlerfreies Programm nur für diese Sache schreiben können. Versuchen Sie dann, zwei dieser Konzepte, die Sie genau kennen, in einem Programm zu kombinieren. Ich bin mir fast sicher, dass Sie es beim ersten Mal richtig machen werden. Eine der besten Möglichkeiten besteht darin, nicht-triviale Software neu zu schreiben, was beim ersten Mal viel Mühe gekostet hat (das mache ich gerade mit Android-Apps). Jedes Mal, wenn ich wieder anfange, ändere ich etwas oder füge Dinge hinzu, um ein bisschen Spaß zu haben, und ich kann Ihnen sagen, dass ich immer besser und besser werde ... vielleicht nicht fehlerfrei, aber wirklich stolz.

Imho-Bugs und plötzliche, mysteriöse Algorithmus-Artefakte müssen während des Codierungsprozesses auftreten: Sie inspirieren und forcieren die Evolution des Codes.
Es ist jedoch möglich (normalerweise nach einigen Tests), jede Variable zu überprüfen, die vor der Deklaration verwendet wurde, um jeden Fehler zu behandeln, wo immer er auftreten mag - um das Programm fehlerfrei zu machen ... bis Sie eine Anfrage für eine in Betracht gezogene Funktion erhalten unmöglich, wenn Sie über Programmarchitektur diskutierten;)

Denken Sie vielleicht mehr über die Art der Fehler nach, die Sie bekommen. Wenn es sich bei den Fehlern in der Regel um geringfügige Fehler handelt, hilft es, sich auf bessere Tests und ein bisschen Korrekturlesen des Codes zu konzentrieren.

Wenn die Fehler jedoch auf suboptimale Programmierentscheidungen zurückzuführen sind, ist möglicherweise mehr Aufwand für ein besseres Design erforderlich. In diesem Fall ist es meines Erachtens möglich, zu stark von Tests abhängig zu sein, um die Qualität der Software zu verbessern, da das Anwenden eines Patches auf fehlerhaften Code die zukünftige Wartung nur erschweren kann. Einerseits bekommen Sie weniger Fehler, wenn Sie sie finden und beheben, andererseits bereiten Sie den Boden für zukünftige Fehler vor.

Eine Möglichkeit, um zu beurteilen, ob Sie ein Problem mit Versehen oder mit dem Design haben, besteht darin, zu überlegen, wie viel Aufwand erforderlich ist, um die Fehler zu beheben. Wenn die Korrekturen in der Regel umfangreich sind oder Sie der Meinung sind, dass Sie sie nicht gut verstehen, verweist dies auf das Codedesign, das verbessert werden kann.

Das hängt meiner Meinung nach mit einem guten Geschmack am Code zusammen, den Sie durch Übung und Überprüfung entwickeln und über Menschen mit ähnlichen Problemen lesen können.

Letztendlich ist es sinnlos, überhaupt keine Bugs zu erwarten, aber es schadet nicht, zu versuchen, die Anzahl der Bugs zu verringern, es sei denn, Sie haben bereits einen niedrigen Stand erreicht, und dann wird es zu einem Kompromiss zwischen Ihrer Zeit und der Zeit derjenigen, die sie finden Wanzen, die Sie nicht fangen.

Wenn ich dir meine: "Null Fehler beim Schreiben des Codes" -> das ist ein schönes Ziel, aber ziemlich unmöglich.

Aber wenn Sie meinen: "Null Fehler bei geliefertem Code" -> das ist möglich, und ich habe in solchen Umgebungen gearbeitet.

Alles, was Sie brauchen, ist: unglaublich hohe Codequalität und nahezu 100% ige Testabdeckung (Komponententests + Akzeptanztests + Integrationstests).

Meiner Meinung nach ist das beste Buch, um das zu lernen: GOOS . Aber ein Buch reicht natürlich nicht aus. Sie müssen zu einer Benutzergruppe gehen und darüber diskutieren. Kurse, Konferenzen usw. Fehlerfreie Qualität ist nicht einfach.

Zuallererst brauchen Sie einen Chef, der wirklich an hoher Qualität interessiert ist und bereit ist, dafür zu bezahlen.

Programmierer-Lösung:

• Beenden Sie die Programmierung.
• Baue einen mechanischen Computer.
• Tauschen Sie ihn alle 5 Jahre aus, damit kein mechanischer Verschleiß auftritt.

Benutzerlösung:

• Verwenden Sie keine Computer mehr.
• Mach alles manuell.
• Lassen Sie die Ergebnisse immer von einer zweiten Person überprüfen.

Ich bin damit einverstanden, dass man als Null-Fehler-Programmierer einfach nicht programmieren / codieren kann. Es gehört zum Leben eines jeden Programmierers, auf Fehler zu stoßen und diese zu entwickeln. Kein erfahrener Entwickler kann sagen, Hand in Herz, sie haben noch nie einen Fehler in ihrem Code festgestellt.

Pairing mit einem anderen Ingenieur. Schreiben Sie einen nicht bestandenen Test. Lassen Sie jedes Zeichen, das Sie eingeben, erforderlich sein, um den fehlgeschlagenen Test zu bestehen. Überarbeiten Sie Ihren Code, um ihn einfacher zu gestalten. Schreiben Sie einen weiteren nicht bestandenen Test und so weiter und so fort.