Okay, ich weiß, es ist eine blöde Frage zu stellen, also lassen Sie mich das klären.
Mein Chef denkt, dass "mit Ihrem Wissensstand Sie nie mehr Fehler in Ihrer Software haben sollten". Auch wenn es richtig sein mag, sind mir die richtigen Werkzeuge und die richtige Methode nie erlaubt, vielleicht weil ich nicht weiß, was ich genau antworten soll (ich bin der einzige Entwickler hier, also tue ich nicht t jemanden zu wenden, wenn es passiert).
Also, hier ist meine Frage: Welche Werkzeuge und Methoden verwenden Sie, um die weniger möglichen Fehler in Ihrer Software zu haben?
Unterm Strich: Ein Code ohne Fehler ist unmöglich. Hier ist jedoch, was möglich ist:
Ein paar Ideen:
Ich würde gerne wiederholen, was andere Leute über das Schreiben von fehlerfreiem Code gesagt haben - es ist unmöglich. Die Verwendung einiger oder aller der oben genannten Techniken sollte jedoch zumindest helfen, Ihre Fehler zu reduzieren.
Offensichtlich, und vielleicht sogar am wichtigsten, sollten Sie jemanden haben, der Ihre Software testet (d. h. nicht nur automatisierte Tests), bevor sie bereitgestellt / ausgeliefert wird.
Vor allem: Fehlerfreie Software ist ein Mythos!
Zweitens hängen die Werkzeuge selbst von vielen Dingen ab, aber wenn Sie die Dinge so allgemein wie möglich halten wollen:
cosmo0, es tut mir leid, aber ich habe Mitleid mit dir.
Für mich ist Ihr Chef der Meinung, dass Sie fehlerfreien Code schreiben müssen, genauso wie Sie denken, dass Sie ein unbegrenztes Gehalt haben müssen. Das Hinzufügen des Wortes "fast" zu diesem "fehlerfreien" ändert nichts an der Bedeutung.
Es gibt einen fehlerfreien Code. Der Code mit der 0-Funktionalität ist fehlerfrei. Aber es ist nutzlos.
Das Schreiben von Computerprogrammen ist dem Schachspielen sehr ähnlich. Tigran Petrosian, ein Schachweltmeister, der für seine starken Verteidigungsfähigkeiten bekannt ist, wurde einmal von einem nicht sehr höflichen Journalisten gefragt, warum er manchmal Fehler macht. Die Antwort war überraschend einfach: "Weil Schachspielen nicht einfach ist. Versuchen Sie, sich selbst zu spielen und Sie werden sehen."
Natürlich würde ich empfehlen, dieses Beispiel nur dann zur Rechtfertigung zu verwenden, wenn Ihr Chef ein kluger Mensch ist und es richtig macht. Sonst könnte es besser sein, nach einem anderen Job zu suchen.
Sie müssen es wirklich in den Kopf Ihres Chefs bringen, dass es praktisch unmöglich ist, Software beliebiger Komplexität ohne Fehler zu schreiben.
Sobald Sie akzeptieren, dass das Schreiben von fehlerfreiem Code eine unmögliche Aufgabe ist, können Sie sich auf das konzentrieren, was wirklich wichtig ist: macht alle Ihre Fehler leicht erkennbar
Komponententests sind ein großartiger Weg, dies zu tun, und es gibt viele kleine Tricks, die Sie im Laufe der Zeit aufgreifen, die Ihnen helfen werden, sie zu vermeiden, obwohl dies nur mit Erfahrung und Wissen, welche Arten von Fehlern < em> Sie werden wahrscheinlich machen.
Ein oft zitiertes (und wahrscheinlich jetzt irrelevantes) Beispiel besteht darin, die Reihenfolge Ihrer Vergleiche umzukehren, zB:
%Vor%statt
%Vor% Sie tun also nicht eine Zuweisung ( foo = "bar" ), wenn Sie einen Vergleich durchführen möchten ( foo == "bar" ). Wenn Sie die Reihenfolge umkehren, ist der Fehlerfall ( "bar" = foo ) ein leicht erkennbarer Syntaxfehler und kein viel schwieriger zu findender Logikfehler. Aber das ist wirklich nur nützlich, wenn das der Fehler ist, den du regelmäßig machst.
Kann Ihr Chef Ihnen fehlerfreie und vollständige Spezifikationen geben, die sich nicht von der Minute, an der er sie abschließt, bis zur Fertigstellung der Software ändern? Wenn ich vollständig sage, meine ich nicht nur eine Liste von Features. Wie wäre es mit allen Interaktionen zwischen allen Features, allen Erwartungen des Verhaltens für jede mögliche Benutzereingabe, jedem möglichen Zustand der Umgebung (zB Betriebssystem, vorhandene Dateien, andere laufende Anwendungen, Zugriff auf gemeinsam genutzte Ressourcen, Schriftgröße, Farbschemata, Tastatur) Layouts), welche Prozesse Vorrang vor anderen haben, Timing auf die Millisekunde usw.
Test Driven Development ist ein guter Anfang, aber es ist nicht genug. Gute Praktiken, Pair Code Review und Programmierung, ein hohes Maß an Aufmerksamkeit und die Zusammenarbeit eines guten Testers können die Fehlerkontrolle effektiv verbessern.
Aber ich denke, dass "fehlerfreie Software" Science Fiction betrifft ...
Vielleicht kennt Ihr Chef menschliche Fehler nicht. Nichtsdestotrotz kann die Verwendung von Methoden wie Komponententests, kontinuierliche Integration und statische Codeanalyse die Codequalität verbessern und bestimmte Arten von Fehlern reduzieren.
Bug-freie Software ist ein Mythos. Zum Vergleich, wenn Ihr Chef sagt, dass Sie jetzt keine Fehler in Ihrer Software haben sollten, ist das so, als würde man einem Mathematiker sagen, dass sie den genauen Dezimalwert von π inzwischen herausgefunden haben sollten oder alle Primzahlen gefunden haben sollten. Fehlerfreie Software ist ein Ziel, das Sie erreichen, kein Ziel, das Sie erreichen.
Das soll nicht heißen, dass wir nicht für Fehler in unserer Software verantwortlich sind oder dass erfahrene Entwickler keine geringere Anzahl von Fehlern haben. Aber Ihr Chef muss realistische Erwartungen an Ihre Fähigkeiten haben. Es gibt keine perfekten Treiber, keine perfekten Manager und keine perfekten Programmierer.
Ich denke, "mit Ihrem Wissensstand sollten Sie nie mehr Fehler in Ihrer Software haben" ist nicht möglich.
Sie können jedoch ein TDD (Test Driven Development) in Ihrem Projekt verwenden, um Fehler in Release-Versionen zu minimieren. Aber das ist keine Gesamtlösung. einige Bugs sind sehr kompliziert und können durch ein Update der 3rd Party Komponente oder was auch immer verursacht werden.
JUnit (oder ein anderes Unit-Test-Programm) ist nützlich, wenn Sie klare Anforderungen zum Testen und zur Verhinderung von Regressionen haben. Wenn die Tests automatisiert sind und häufig ausgeführt werden, können Sie sicher sein, dass Ihre Änderungen andere Teile des Systems nicht beschädigen. Es ist auch hilfreich, wenn Sie schwierige Klassen entwerfen, da Sie alle (gut, viele) Randfälle planen können, die Sie testen und alle zusammen testen möchten.
Die wichtigsten Punkte sind
Ich sympathisiere sowohl mit Ihnen als auch mit Ihrem Chef. Ich denke, es ist bemerkenswert, dass Software heute "perfekt" so teuer ist, dass niemand dafür bezahlen möchte. Am Ende akzeptieren Kunden das Maß an Bugginess, das Software erschwinglich macht.
Ich werde ein einfaches Stück "Methode" beisteuern. Es ist die Idee eines Null-Fehler-Meilensteins . In Softwareprojekten wird häufig über Meilensteine gesprochen, die wichtige Punkte in der Zeitleiste des Projekts darstellen. In den meisten Fällen, die ich gesehen habe, sagen Nutzer, dass sie einen Meilenstein erreicht haben, an dem Punkt, an dem sie den Code für die Funktionen in diesem Meilenstein eingegeben haben. In der Realität gibt es natürlich keine Ahnung von Fortschritt bis zur Fertigstellung.
Der Null-Fehler-Meilenstein versucht nicht, Null-Fehler zu haben. Es bedeutet vielmehr, dass Sie nicht erklären, dass Sie einen Meilenstein erreicht haben, bis Sie einige Tests durchgeführt haben und ein gewisses Maß an Vertrauen haben, dass Sie wissen, was all Ihre Fehler sind . Sie können einige vor dem Erklären des Meilensteins reparieren, oder Sie können nicht, aber Sie wissen zumindest, was sie sind. Sie bestimmen, wie viel zu testen ist und welche Fehler akzeptabel sind, aber diese Dinge sind im Voraus vereinbart.
Diese Art von Meilenstein ist ein weitaus besseres Maß dafür, wie weit Sie bis zur Fertigstellung fortgeschritten sind, aber es ist überraschend, wie selten Sie Projekte auf diese Weise verwalten. Ich empfehle es.
Welche Art von Fehlern haben Sie in Ihrer Software?
Fehler außerhalb der Grenzen? Nicht initialisierte Variablen lesen? Dereferenzieren ungültiger Zeiger? Diese können von einem statischen Analysetool erkannt werden.
Unvollständiges Verständnis der Anforderungen? Hier hilft testgetriebene Entwicklung und eine Review-Kultur.
Designprobleme? Auch hier sind Bewertungen eine große Hilfe.
Verwenden Sie veralteten Code? Das erfordert Versionskontrolle.
Und: Behalte ein Defektprotokoll, damit du weißt, welche Art von Fehlern du machst.
Ich war erfolgreich mit dem "Release early, release often" -Muster, bei dem Sie weniger Features gleichzeitig auswählen und diese Features ausgiebig testen, bevor Sie sie in ein Release aufnehmen. Funktionen, die die Qualitätskriterien nicht erfüllen, sind in der Iteration nicht enthalten.
Natürlich funktioniert das nicht alleine und Sie müssen gute Entwicklungspraktiken wie die von Phil, Manrico, Twan und anderen haben ...
Es ist dumm von Grund auf und nicht auf Programmierung beschränkt. Nur ein paar Gegenbeispiele. Die meisten von uns haben ihren Führerschein seit Jahren und sollten deshalb nie mehr in einen Unfall verwickelt werden. Wie real ist das?
Ein anderes Beispiel, es sollte nie passieren, dass Schrauben unter "normalen" Bedingungen brechen, aber sie tun es immer noch. Sie können überladen sein, oder sie können anfangen zu rosten oder jemand könnte denken, dass es eine gute Idee ist, eine schlechtere Qualität zu verwenden. Und rate mal, was du nicht siehst, du kannst mit hoher Wahrscheinlichkeit sagen, dass eine Ladung Schrauben in Ordnung ist, aber du kannst sie nicht erschöpfend testen. Es kann schwache Stellen geben, zum Teufel, es könnte Luft sein, die man kaum sieht, wenn man sie nicht röntgt. Und so geht es immer wieder weiter, wenn diese Einstellung nur ein bisschen klingen würde, würden wir in einer völlig anderen Welt leben ....
Unit-Test! Es ist kein Silber Bullit, aber es spart viel Zeit für die Fehlersuche.
Tags und Links language-agnostic methodology