Wie oft führen Sie Ihren Code während der Programmierung aus und testen ihn? [geschlossen]

Besonders wenn ich neuen Code in C von Grund auf neu schreibe, schreibe ich Code stundenlang, sogar tagelang, ohne den Compiler für irgendetwas anderes als eine gelegentliche Syntaxprüfung auszuführen.

Ich neige dazu, größere Codestücke sorgfältig zu schreiben und erst dann gründlich zu testen, wenn ich überzeugt bin, dass der Code das tut, was er tun soll, indem ich den Fluss in meinem Kopf analysiere. Verstehen Sie mich nicht falsch - ich würde nicht 1000 Zeilen schreiben, ohne zu testen (das wäre ein Glücksspiel), aber ich würde eine ganze Unterroutine schreiben und sie testen (und nötigenfalls korrigieren), wenn ich denke, dass ich fertig bin.

Auf der anderen Seite habe ich vor allem Neulinge gesehen, die ihren Code nach jeder Eingabe in den Editor ausführen und testen und der Meinung sind, dass Debugger ein Ersatz für Sorgfalt und Vernunft sein können. Ich halte dies für eine große Ablenkung, sobald Sie die Sprachsyntax gelernt haben.

Was ist Ihrer Meinung nach die richtige Balance zwischen den beiden Ansätzen? Der erste erfordert natürlich mehr Erfahrung, aber wirkt er sich positiv oder negativ auf die Produktivität aus? Hilft Ihnen der zweite, Fehler auf einer feineren Ebene zu erkennen?

Es hängt WIRKLICH von dem Aspekt des Projekts ab, an dem Sie arbeiten.

• Wenn ich irgendetwas mit OpenGL mache (das wie eine Zustandsmaschine funktioniert), kompiliere und starte ich ständig, um sicherzustellen, dass ich nichts versehentlich vermasselt habe. Wenn Sie einen Wert festlegen, ohne daran zu denken, ihn am Ende einer Funktion zurückzusetzen, kann die Anwendung auf einfache Weise nur einen schwarzen Bildschirm rendern.

• Für größere "under the hood" -Entwicklungen versuche ich, so viele Tests wie möglich vorher zu machen. Da die Tests mir leichter sagen können, was kaputt gegangen ist, kann ich eine Weile warten, ohne auf die normalerweise lange Kompilierung warten zu müssen.

• Für das UX-Design verwende ich eine Art visuellen Designer, der immer so aussieht, wie er ausgeführt wird (oder in der Nähe davon). Es kompiliert im Wesentlichen immer den Designcode.

Persönlich muss ich in kleinen Blöcken arbeiten, weil ich nicht klug genug bin, stundenlange Codierung in meinem biologischen L1-Cache zu speichern. Aufgrund meiner begrenzten Möglichkeiten schreibe ich kleine, zusammenhängende Methoden und Designobjekte, um eine sehr lockere Kopplung zu erzielen. Leistungsfähigere Tools und Sprachen vereinfachen das längere Programmieren, ohne etwas zu erstellen, aber für mich gibt es immer noch Grenzen.

Ich bevorzuge es, ein kleines Stück zu schreiben und zu überprüfen, ob es wie erwartet funktioniert. Dann kann ich theoretisch die Details dieses Stücks vergessen und es so weit wie möglich als Black Box behandeln.

Ich schreibe gerne meinen Test, bevor ich meinen Implementierungscode schreibe. Ich mag das aus drei Gründen:

1. Wenn ich meinen Testcode vorab schreibe, kann ich überlegen, wie mein Code verwendet werden soll. Es hilft mir, mir Randfälle vorzustellen, an die ich bei der ursprünglichen Entwicklung meines Programms nicht gedacht habe.
2. Ich weiß, dass ich mit dem Schreiben des Implementierungscodes fertig bin, wenn alle meine Testfälle bestanden sind.
3. Wenn Sie sich angewöhnen, Tests vor dem Schreiben von Code zu schreiben, können Sie auch nachweisen, dass Ihr Code keine neuen Fehler enthält (vorausgesetzt, Sie haben gute Testfälle geschrieben).

Ich schreibe Code stundenlang, sogar tagelang, ohne den Compiler für etwas anderes als eine gelegentliche Syntaxprüfung auszuführen.

Stunden bis Tage - das ist ein klares Zeichen dafür, dass Sie die Möglichkeit verpassen, Ihren Code in kleinere Teile zu zerlegen, die einzeln überprüft und getestet werden können. Daran sollten Sie unbedingt arbeiten.

Ich neige dazu, größere Codestücke sorgfältig zu schreiben und erst dann gründlich zu testen, wenn ich überzeugt bin, dass der Code das tut, was er tun soll, indem ich den Fluss in meinem Kopf analysiere.

Anstatt größere - und damit komplizierte - Codestücke zu schreiben, die Stunden benötigen, um in Ihrem Kopf analysiert zu werden, sollten Sie versuchen, kleinere, nicht so große Bausteine ​​zu erstellen. Dies baut genannt Abstraktionen - und das ist der Kern der guten Programmierung, definitiv kein Zeichen für einen Neuling beeing.

Exzellentes Programmieren ist wie exzellentes Billardspielen - ein guter Spieler spielt keine harten Schläge. Stattdessen spielt er so, dass die Bälle nach jedem Schlag an einer Stelle anhalten, an der der nächste Schlag wieder leicht fällt. Und ein Programmierer ist nicht gut, weil er komplizierten Code schreiben kann - er ist gut, weil er komplizierten Code vermeiden kann.

Ich kompiliere und teste, ob eine der folgenden Bedingungen erfüllt ist:

• Letzte Kompilierung war vor 15 Minuten
• Letzte Kompilierung war vor 25 Zeilen
• Neue Funktion / Unterprogramm wurde implementiert
• Große Änderung
• Neues Feature (oder ein als Feature getarnter Bug)
• Bugfix (ein "Feature" wurde entfernt)
• Ich langweile mich

Wie oft ich Code ausführe und teste, hängt davon ab, in welcher Sprache ich gerade arbeite. Wenn ich eine gespeicherte Prozedur codiere, warte ich normalerweise, bis alles da ist.

Auf der anderen Seite, wenn ich in Lisp programmiere, werde ich jede Funktion ausprobieren, nachdem ich sie eingegeben habe.

Wenn ich in Haskell codiere, werde ich in der Regel nach jeder Funktion eine Kompilierung durchführen, um alle Typfehler abzufangen, und den Code ausführen, nachdem alles erledigt ist.

Ich schreibe gerade genug Code, um den Test auf Grün zu bringen. Das heißt, ich führe alle paar Minuten einen Test durch. Das ist mein C ++ - Stil. In Ruby verwende ich jedoch den Autotest. Jedes Mal, wenn ich auf Speichern drücke, erhalte ich ein Test-Feedback über ein nettes Popup. Ich höre nicht einmal auf, Code zu schreiben, es passiert einfach im Hintergrund.

Dreimal in der Stunde, ob es nötig ist oder nicht.

Wir führen die Erstprogrammierung durch und übertragen nur den Arbeitscode in das VCS. Der Smoulderbot checkt alle 20 Minuten das Repo aus und führt die Testsuite aus. Alle Fehler werden sofort an das gesamte Programmierteam zur sofortigen Behebung gesendet.

Für mich geht es nicht darum, wie viel ich schreibe. Ich kann Tausende von Zeilen einfachen Codes schreiben, ohne ihn testen zu müssen. Wenn ich jedoch schwierigeren Code schreibe, neige ich dazu, jede Funktion einzeln zu testen, nachdem ich einen zusammenhängenden Satz von ihnen geschrieben habe.

Manchmal ist es jedoch ein großer Motivationsschub, den Code laufen zu sehen, wenn Sie eine Weile nichts ausgeführt haben.

Für mich: -
Kurze Zeitspanne (nicht viel Zeit zum Nachdenken) - Code schreiben, kompilieren, testen. Debuggen
Ausreichende Zeit - während (erledigt) {kleinen Code schreiben, kompilieren}, testen, debuggen

Ich teste für jedes Codierungskonzept. Manchmal ist dies eine Funktion oder Klasse und manchmal nichts anderes als eine if-Anweisung. Sobald das Konzept funktioniert, fahren Sie mit dem nächsten fort.

Ich versuche, Tests vor dem Code zu schreiben. Ich führe meine Tests vor einem Commit mindestens zweimal durch. Anschließend wird es erneut mit dem Continuous Integration-Server ausgeführt.