it-swarm.dev

Wie werde ich ein Zero-Bug-Programmierer?

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

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

168
Elaine

Code überhaupt nicht.

Nur so können Sie ein Zero-Bug-Programmierer sein.

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

365
wildpeaks

Null Fehler sind 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 Hochrisikosoftware. Die Space Shuttle Software kommt mir in den Sinn. Ihre Produktivität liegt jedoch in der Größenordnung von wenigen Zeilen pro Tag. Ich bezweifle, dass Ihr Chef das will.

Diese Software ist fehlerfrei. Es ist perfekt, so perfekt, wie es die Menschen 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, eine Änderung, die nur 1,5% des Programms oder 6.366 Codezeilen umfasst. Die Spezifikationen für diese eine Änderung umfassen 2.500 Seiten, ein Volumen, das dicker als ein Telefonbuch ist. Die Spezifikationen für das aktuelle Programm füllen 30 Bände und umfassen 40.000 Seiten.

124
CodesInChaos

"Zero-Bug-Programmierer" ist ein Oxymoron, wie ein stiller Sänger, aber in den letzten 60 Jahren hat das Programmieren einige destillierte Weisheiten hervorgebracht, die Sie zu einem besseren Programmierer machen, 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. Gehen Sie die Aufgabe mit voller Demut an und vermeiden Sie clevere Tricks wie die Pest. [Edsger Dijkstra]
  • Kampf kombinatorische Explosion
  • Werde den veränderlichen Zustand los (wo immer möglich). Ja, lernen Sie funktionale Programmierung.
  • Reduzieren Sie die Anzahl möglicher Codepfade
  • Verstehen Sie (die Größe) der Größe der Eingabe- und Ausgaberäume (Ihrer Funktionen) und versuchen Sie, diese zu reduzieren, um einer 100% igen Testabdeckung immer näher zu kommen
  • Gehen Sie immer davon aus, dass Ihr Code nicht funktioniert - beweisen Sie es anders!
98
Maglob

TDD

Der Punkt von TDD ist, dass Sie keine einzelne Codezeile schreiben, wenn es keinen Test gibt, der diese Codezeile erfordert. Und um es auf das Äußerste zu bringen, entwickeln Sie immer eine neue Funktion, indem Sie einen Abnahmetest schreiben. Hier habe ich festgestellt, dass das Schreiben von Gurke Stiltests ideal ist.

Der TDD-Ansatz bietet mindestens zwei Vorteile.

  • Der gesamte Code wurde geschrieben, um ein bestimmtes Merkmal zu lösen, sodass keine unnötige Überproduktion entsteht.
  • Wenn Sie eine vorhandene Codezeile ändern und eine Funktion beschädigen, werden Sie benachrichtigt

Es beweist keine Null-Fehler, da dies unmöglich wäre (wurde bereits durch unzählige andere Antworten hervorgehoben). Aber nachdem ich TDD gelernt und gut darin geworden bin (ja, es ist auch eine Fähigkeit, die geübt werden muss), habe ich ein viel höheres Vertrauen in meinen eigenen Code, da er gründlich getestet wird. Und was noch wichtiger ist, ich kann vorhandenen Code ändern, den ich nicht vollständig verstehe, ohne mir Sorgen machen zu müssen, dass die Funktionalität beeinträchtigt wird.

Aber TDD hilft Ihnen nicht den ganzen Weg. Sie können keinen fehlerfreien Code schreiben, wenn Sie die Architektur des Systems und die Fallstricke dieser Architektur nicht genau verstehen. Z.B. Wenn Sie 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 (fallen Sie nicht in die Newbie-Falle, um veränderbare Daten zwischenzuspeichern, um die Leistung zu verbessern).

Ich glaube, dass die Entwicklungsteams, die gut in TDD sind, den Code mit den geringsten Fehlern liefern.

25
Pete

Die Sache ist, Fehler sind die Dinge, die Sie nicht erkennen. Wenn Sie nicht über enzyklopädische Kenntnisse der Programmiersprache/des Compilers sowie aller Umgebungen verfügen, in denen Ihre Anwendung ausgeführt wird, können Sie wirklich nicht erwarten, 100% fehlerfreien Code zu erstellen.

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 schrieb einen besonders schönen Artikel über Fehlerbehebung .

19
user7007

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, du wirst immer Fehler haben" ist nur eine Ausrede, um die Anzahl der Fehler in deinem Code nicht zu verringern. Niemand ist perfekt, aber wir können und sollten uns bemühen, besser zu werden. Bei 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 zu versuchen, fantastische Designmuster zu erstellen, aber auf lange Sicht spart das Schreiben, was Sie benötigen, Zeit und beugt Fehlern vor.
  • Komplexität ist der Feind. Weniger zählt nicht, wenn es sich um ein obskures, kompliziertes Durcheinander handelt. Code Golf macht Spaß, aber es ist die Hölle zu verstehen und eine schlimmere Hölle zu debuggen. Wann immer Sie komplizierten Code schreiben, öffnen Sie sich einer Welt voller Probleme. Halten Sie 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 das Schreiben von Programmen, die Sie mit Leichtigkeit schreiben können, sondern das Schreiben von Programmen, die ein wenig weh tun und zum Nachdenken anregen.
  • Der andere Weg, um besser zu werden, ist zu lesen. Es gibt viele schwierige Themen in der Programmierung zu lernen, aber Sie werden sie nie lernen können, wenn Sie nur programmieren. Sie müssen sie studieren. Sie müssen das harte Zeug lesen. Dinge wie Sicherheit und Parallelität sind unmöglich, 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 Websites wie Gawker hatten. Wenn sie sich die Zeit genommen hätten, um zu lernen, wie man Sicherheit richtig macht und nicht nur etwas macht, 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 die Programmierung anzusehen und darüber nachzudenken. Dies wird Ihnen helfen, ...
  • Lerne die schmutzigen Details. Die kleinen Details, wie dunkle Teile Ihrer Sprache und Anwendung funktionieren, sind sehr wichtig. Sie können Geheimnisse enthalten, die Ihnen helfen, das Schreiben von kompliziertem Code zu vermeiden, oder Teile, die eigene Fehler aufweisen, 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 genug in ihre Köpfe eindringen, um die fremden Dinge zu kennen, die sie möglicherweise versuchen, und um sicherzustellen, dass Ihre App damit umgehen kann.
17
AmaDaden

Keine Fehler? Es klingt wie Sie benötigen LISP (folgen Sie dem skeptischen Pfad und vermeiden 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 Code-Analyse-Tools verwenden (z. B. FindBugs , PMD und so weiter), die - kombiniert mit strengen Compiler-Warnungen - alle möglichen Probleme mit Ihrem Code aufdecken. Beachten Sie, was sie Ihnen sagen, bemühen Sie sich wirklich, die Art des Fehlers zu verstehen, und ergreifen Sie dann Maßnahmen, um Ihre Programmiersprache so zu ändern, dass es unnatürlich ist, auf eine Weise zu codieren, die diesen Fehler erneut einführt.

8
Gary Rowe

Persönlich denke ich, dass das Streben nach fehlerfreier Programmierung teurer zu sein scheint (sowohl in Bezug auf Zeit als auch Geld). Um einen Fehler von Null oder sogar einen Fehler nahe Null zu erreichen, müssen Sie die Entwickler gründlich testen lassen. Dies bedeutet, dass Sie alle Regressionstests durchführen, bevor Sie Code zur Patch-Überprüfung einreichen. Dieses Modell scheint mir nicht kostengünstig zu sein. Es ist besser, wenn die Entwickler sorgfältige Tests durchführen und die eingehenden Tests dem QS-Team überlassen. Hier ist warum:

  • Entwickler saugen am Testen. Es ist wahr und du weißt es. (Ich bin ein Entwickler!) Ein gutes QS-Team wird immer die Edge-Fälle finden, an die Entwickler nie denken.
  • Entwickler können gut codieren. Lassen Sie sie zu dem zurückkehren, was sie in Excel beherrschen (und normalerweise, was sie sowieso lieber tun).
  • Das QA-Team kann in einem Durchgang Fehler finden, die sich auf mehrere Entwickleraufgaben beziehen.

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

Wie viele Berufe können Sie nennen, die ihre Aufgabe immer gleich beim ersten Mal richtig erledigen, ohne Peer Review und/oder Tests?

8

Alle "Überhaupt nicht codieren". Antworten fehlen völlig den Punkt. Auch Ihr Chef scheint 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 ziemlich oft auch Kopieren/Einfügen/Ändern). Während Versuch und Irrtum ein gültiger 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 basiert und mit ein wenig Disziplin und Sorgfalt, die Sie nicht haben werden Das Problem wurde nur gelöst, 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 von etwas nachdenken möchten. Wenn Sie dies tun, werden Sie folglich viel Erfahrung darin sammeln, Code zu schreiben, der fast fehlerfrei ist. - Es stehen unzählige Ressourcen zur Verfügung, um ein besserer Programmierer zu werden, der Ihnen auf Ihrer Reise helfen kann ...

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

Ihr Chef sagt zu Recht, dass Sie die Ergebnisse und Auswirkungen des Codes, den Sie auf das vorhandene System schreiben, verstehen sollten. Werden Fehler auftreten? Ja natürlich. Diese Fehler sind jedoch auf Ihr unvollständiges Verständnis des Systems/der Tools zurückzuführen, mit denen Sie arbeiten, und mit jeder Fehlerbehebung erhalten Sie eine bessere Abdeckung.

8
Patrick Klug

Wie die anderen Kommentare bereits richtig betonten, gibt es keine nicht triviale Software ohne Fehler.

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

Abhängig von Ihrem Arbeitsbereich können Sie versuchen, Ihre Software formal zu überprüfen. Mit formalen Methoden können Sie ziemlich sicher sein, dass Ihre Software genau der Spezifikation 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. Grundsätzlich wird der Ort, an dem Fehler auftreten können, von der Implementierung zur Spezifikation verschoben.

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

7
FabianB

Schreiben Sie entweder nichts Komplizierteres als "Hallo Welt!" oder wenn Sie jedem sagen, dass er es niemals benutzen soll.

Fragen Sie Ihren Chef nach einigen Beispielen für diesen so genannten fehlerfreien Code.

6
JeffO

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

  • Holen Sie sich einen Tester. Im Joel-Test erfahren Sie, warum.
  • Verwenden Sie Bibliotheken ausgiebig. Die wurden wahrscheinlich besser getestet. Ich bin ein großer Fan von CPAN für Perl.
5
Brian Carlton

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

  • mehrere Testtechniken anwenden (andere als ATDD)
  • erstellen Sie formale Überprüfungen unserer Software
  • ein separates QS-Team haben
  • führen Sie eine gründliche Analyse jeder Änderung an der Codebasis durch
  • verwenden Sie eine Sprache, die mehr auf Sicherheit und Vorsicht ausgerichtet ist

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 weiter in Richtung Null Bugs, aber es würde keinen geschäftlichen Sinn ergeben.

Ich erstelle interne Tools, die ein großer Teil unserer Infrastruktur nutzt. Meine Standards zum Testen und Codieren sind hoch. Es besteht jedoch ein Gleichgewicht. Ich erwarte keine Null-Fehler, weil ich nicht 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 Düsentriebwerken usw. erstellen würde. Wenn meine Software kaputt geht, stehen keine Leben auf dem Spiel, daher setzen wir uns nicht für diese Sicherheit ein.

Ich würde das Maß an Sicherheit an die beabsichtigte Verwendung der Software anpassen. Wenn Sie Code schreiben, den das NASA-Shuttle verwendet, ist möglicherweise eine Fehlertoleranz von Null angemessen. Sie müssen nur eine Reihe zusätzlicher und sehr teurer Praktiken hinzufügen.

5
dietbuddha

Ich denke, ein guter erster Schritt, um ein "Zero-Bug" -Programmierer zu werden, besteht darin, Ihre Einstellung zu Bugs zu ändern. Anstatt Dinge zu sagen, "sie passieren", "bessere Qualitätssicherung und bessere 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. Bei Ihrer Suche nach Möglichkeiten zur Behebung von Fehlern stoßen Sie auf eine testgetriebene Entwicklung. Sie finden viele Bücher, Blog-Beiträge und Leute, die kostenlose Ratschläge zu besseren Techniken geben. Sie werden sehen, wie wichtig es ist, Ihre Fähigkeiten durch Übung (wie das Codieren von Katas oder das Ausprobieren neuer Dinge zu Hause) zu verbessern. Sie werden anfangen, bei der Arbeit bessere Leistungen zu erbringen, weil Sie anfangen, an Ihrem Handwerk zu arbeiten zu Hause. Und hoffentlich, sobald Sie sehen, dass es ist möglich ist, gute Software zu schreiben Ihre Leidenschaft für Ihr Handwerk wird wachsen.

4
Darren

In gewissem Sinne 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) Zero-Bug-Programmen nerschwinglich 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 Theoremprüftechniken, um formal zu beweisen, dass Ihr Programm die Spezifikation implementiert.

  • Erstellen Sie umfangreiche Einheiten-, Regressions- und Systemtestsuiten und -geschirre, 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), Software (und Beweise) ü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.

2
Stephen C

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 es sich daher um eine Verbesserung handelt. Wenn keine dieser Antworten akzeptiert wird, sage ich ihnen lediglich, dass sie ihre eigenen Anforderungen nicht verstanden haben. Somit gibt es keine Fehler. Programmierer sind perfekt.

1
angryITguy

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

  1. Beginnen Sie niemals mit dem Codieren, es sei denn, Sie haben UNAMBIGUOUS SPEZIFIKATIONEN für Ihre Funktionalität.
  2. NICHT TESTEN oder oder wenn Sie sich nicht auf Tests verlassen, um Softwarefehler zu erkennen.
  3. Wenden Sie alle FEEDBACK-Fehler, die beim Testen, Überprüfen und Produzieren festgestellt wurden, auf einen Prozess und Entwickler an, die Fehler zuerst 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.

Tests können nur beweisen, dass Sie Fehler haben, aber es ist normalerweise nutzlos, das Gegenteil zu beweisen. In Bezug auf das Feedback - wenn Sie einen Münzautomaten haben, der Münzen herstellt, und jede 10s-Münze im Durchschnitt einen Defekt aufweist. Sie können diese Münze nehmen, flach drücken und wieder in die Maschine einlegen. Eine Münze, die diesen recycelten Rohling erkannt hat, ist nicht so gut, aber vielleicht 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, müssen Sie viel Zeit investieren, um jeden gemachten Fehler zu trainieren und zu wiederholen. Entwickler müssen in formalen Verifizierungsmethoden geschult werden, die oft schwer zu erlernen und in der Praxis anzuwenden sind. Die Wirtschaftlichkeit der Softwareentwicklung arbeitet auch dagegen - 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 einen Automaten kaufen, der perfekte Münzen herstellt, oder 10 weitere Code-Affen mieten, um eine Reihe von Tests zu gleichen Kosten zu erstellen. Sie können diesen umfassenden Prozess als Ihre "Maschine" wahrnehmen, Ihr Kapital - die Investition in eine umfassende Schulung exzellenter Entwickler zahlt sich nicht aus.

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, der perfekten Code erstellt, weil er langsam ist.

1

Wenn wir von großen Softwarehäusern ausgehen wissen wie man erstklassige Entwickler bekommt (wie in Zero Bugs Programmer), können wir die Software von Microsoft abziehen muss sein) ohne Fehler. Wir wissen jedoch, dass dies weit von der Wahrheit entfernt ist.

Sie entwickeln ihre Software und wenn sie ein bestimmtes Maß an Fehlern mit niedriger Priorität erreichen, geben sie das Produkt einfach 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 bei ihren Fahrzeugen und Bugs. Obwohl sie viele strenge Tests haben, um katastrophale Ausfälle zu vermeiden. Trotzdem haben selbst sie Fehler in ihrer Software.

Bugs sind unvermeidlich genauso wie es die menschliche Natur ist, sich zu irren.

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

0
Robert Koritnik

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 Ihr gesamter Code tut, und auftretende Fehler sehr effizient zu beheben.

0
Jason McCarrell

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

Was ich meine ist, dass es möglich ist, dass Ihr Chef von "Null-Fehler-Methode" gehört hat (siehe Abschnitt Nr. 5) und sich nicht die Mühe gemacht hat, zu verstehen, was das bedeutet?
Natürlich ist es für das Management unpraktisch, die Entwicklung neuer Funktionen zugunsten von Fehlern zu verschieben, die Sie nicht hätten einfügen sollen ...
Und natürlich bedroht das seinen Bonus, also bekommst du natürlich keinen, weil "gute Programmierer keine Fehler haben" ...

Es ist in Ordnung, Fehler zu machen, solange Sie sie finden können und behebe sie (natürlich im Rahmen der Vernunft).

0
AviD

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, sogar alle Eingabe-/Variablenkombinationen zu testen.

Ihr Chef scheint einer von denen zu sein, die "nicht verstehen, was an der Programmierung so schwer ist, da sie nur tippt".

0
SpacePrez