Wenn ich etwas Komplexes schreibe, finde ich, dass ich das Schreiben wie 10 Mal neu starte, bevor ich mit dem, was ich will, enden kann, wobei ich oft Hunderte Zeilen Code verwerfe.
Mache ich etwas falsch oder haben andere solche Arbeitsabläufe?
EDIT: Im Moment arbeite ich an einem modularen Compiler. Das letzte Projekt, an dem ich arbeitete, war ein Server in Java. Davor war es etwas Nebenläufigkeit.
Ich mache ein gutes Stück Planung, und ich beginne nie zu programmieren, bevor ich Schnittstellen für alles habe.
Da ist es normal, einfach die Tafel wieder sauber zu machen?
Das Verwerfen vieler Codezeilen ist normalerweise ein positiver Aspekt des Refactorings. Das ist großartig. Wenn Sie jedoch mehr als zehn Mal starten, haben Sie wahrscheinlich Ihr Problem und Ihre Lösung nicht analysiert. Es ist in Ordnung zurückzugehen und manchmal neu anzufangen, aber nicht so oft. Sie sollten Ihren Code so aufstellen, dass Sie beim Zurückverfolgen und Refactoring den größten Teil von dem, was Sie erstellt haben, behalten, da es in schön isolierten und logischen Chunks existieren wird. (Verwendung einer vagen Sprache, da die Sprache der Wahl nicht angegeben wurde.)
Aus dem Kommentar des Autors:
Normalerweise starte ich neu, weil ich komme verwirrt von all dem Zeug, das sich darin abspielt mein Code.
Studieren Sie Ihr Handwerk und nutzen Sie gute Design-Muster und andere beste Programmierphilosophien, um Ihrem Code eine gut definierte Struktur zu geben ... etwas, das Sie Monate und sogar Tage später wiedererkennen werden.
Perfekt normal. Egal, wie viel ich vorausschaue, ich habe oft ein "Aha!" Moment, sobald die Hände die Tastatur drücken.
Genauso oft ist es ein "Was zum Teufel habe ich gedacht?" Moment.
Es ist alles gut. Sie machen besseren Code.
Alle Vorschläge hier sind gültig, aber denken Sie daran, dass es einen Moment in der Lebensdauer eines Programms gibt, der "gut genug" ist. Es ist leicht, in die Falle eines endlosen Refactorings zu geraten, nur weil man sieht, dass "ja, das könnte besser gemacht werden!". Nun, stellen Sie sich der Wahrheit - es sei denn, Ihr Programm hat nur ein paar Zeilen, es gibt IMMER eine Möglichkeit, es besser zu machen.
Ich glaube, es gibt glückliche Programmierer da draußen, die nicht darunter leiden, aber zumindest muss ich mich immer wieder daran erinnern, dass es eine Zeile gibt, die "gut genug" heißt.
Und es ist besonders wahr, wenn Sie Code für jemand anderen schreiben - niemand wird bemerken, dass Sie etwas "netteres" getan haben, alles, was zählt, ist "funktioniert es gut?".
Es ist auch eine SEHR gute Übung, es zumindest vor dem Neuschreiben auf WORK zu bringen. Dann kann man immer wieder auf eine funktionierende vorherige Lösung zurückgreifen.
(seit 12 Jahren schreibe ich ständig ein Spiel um, das ich schreibe, und ich bin noch lange nicht am Ende ...)
Bei einem komplexen Problem ist dies üblich. Wenn Sie nicht völlig im Dunkeln erstechen, hilft es wirklich, zuerst unsere Ideen zu skizzieren, aber dann verschieben Sie einfach die 'Wiederholungen' von Code zu Papier.
Wenn es Ihnen hilft, eine gute Lösung zu finden, wie kann es falsch sein?
Es kommt darauf an, wie gut ich den Problemraum kenne. Wenn es vertrautes Territorium ist, würde ich mir Sorgen machen, wenn es 10 Iterationen braucht. Wenn es sich um ein unbekanntes Gebiet handelt, kann es bis zu 10 Iterationen dauern, aber zumindest einige davon werden auf den Prototyp reduziert - oder ein Versuch eines Prototyps -, bevor sie verworfen werden.
Wenn Sie bei jeder Iteration etwas lernen, gibt es wahrscheinlich kein Problem. Fristen und nervtötende Dinge mögen dein Leben ein bisschen schwieriger machen. :)
Wenn ich an einem neuen Problem arbeite, pseudocode ich es in Kommentaren in der tatsächlichen Funktion Handler, als Teil der Generierung der Stub für meine TDD. Fügen Sie dann den Code zu jedem Schritt hinzu, den ich in den Kommentaren des Funktionskörpers hatte.
Es hilft mir, mich darauf zu konzentrieren, was das Problem ist, das ich löse, und mich nicht in den Details zu früh verliere.
Die größte Änderung, die Sie tun können, um sich selbst zu helfen, wäre, zuerst Ihren Code zu planen . Auf dem Papier.
Ihr Plan muss nicht sehr tiefgründig sein (obwohl das manchmal auch gut ist). Skizzieren Sie einfach eine grobe Vorstellung davon, was Ihr Programm tun soll. Notieren Sie die wichtigsten Funktionspunkte. "Ich möchte, dass es das tut, dies und das" .
Sobald Sie das haben, skizzieren Sie ein grobes Design. Klassen, Methoden, Funktionen, Objekte. Gib es ein wenig Form. Machen Sie eine grobe Zuordnung der Funktionalität zu verschiedenen Teilen Ihres Designs.
Abhängig von der Art des Projekts kann ich ein grobes Design wie dieses nehmen und es in ein viel detaillierteres Design umwandeln. Wenn es ein kleines Projekt ist, vielleicht nicht. Aber egal wie hoch die Komplexität ist, die Entwicklungszeit wird Sie mit besserem Code und weniger Programmieraufwand belohnen. Wenn Sie offensichtliche Fehler haben, bei denen Sie große Teile Ihres Programms umgestalten müssen, sollten sie in Ihrem ursprünglichen Entwurf sichtbar sein und Sie können es anpassen. Sie haben bei einem offensichtlichen Fehler nicht Hunderte von Codezeilen verschwendet.
Compiler sind sehr komplexe Anwendungen, und Sie können keinen optimierenden Compiler von Anfang bis Ende in einem Durchgang schreiben - egal, wie viel Sie zuerst hineingesteckt haben. In der Regel versuchen Sie, etwas von Anfang bis Ende korrekt zu verwenden, um es dann zu modularisieren und neue Funktionen wie Optimierungen hinzuzufügen. Dieser Prozess bedeutet viel Refactoring und ersetzt ganze Abschnitte komplett. Dies gehört auch zu den Lernprozessen - denn niemand kann alles wissen und sich daran erinnern!
(Ich arbeite auch an einem .NET-Compiler im Rahmen des MOSA-Projekts - www.mosa-projet.org.)
Es gibt zwei Situationen. (1) Ich war in der Lage, vorausschauend zu planen und meine Abstraktionen zu isolieren. (2) Ich habe nicht.
Für (1) ist es eine effektive Technik, Dummy-Versionen bestimmter Klassen oder Funktionen zu verwenden, um den Rest des Codes zu steuern. (oder umgekehrt, um die Klassen und Funktionen zu schreiben und sie mit einem Testskript zu steuern.) Dadurch können Sie in jedem Durchgang nur einen Teil der Komplexität bewältigen.
So wie jeder sagt, dass die Leute im Voraus planen sollten, funktioniert das oft nicht so, was zu einer Situation führt (2). Seien Sie hier vorsichtig, was Sie in einer Iteration des Codes erreichen möchten. Sobald Sie feststellen, dass Ihr Gehirn nicht in der Lage ist, mit all den Dingen zu jonglieren, die Sie tun, reduzieren Sie Ihren Ehrgeiz auf das, was Sie vor dem nächsten Kompilieren und Testen erreichen möchten. Erlauben Sie Ihrem Code, fehlerhaft zu sein, aber beim ersten Durchlauf leicht zu schreiben und dann durch Refactoring zu entwickeln. Dies verbessert die Effizienz beim wiederholten Löschen der Schiefertafel.
Zum Beispiel war es eine Sache, die ich in die Irre geführt habe, dass ich gewöhnlichen Code ausspionieren und zu früh in Subroutinen umgestalten konnte, bevor ich wirklich die Form des Codes kannte. Seitdem habe ich mir erlaubt, Code im ersten Durchgang zu duplizieren und dann zurückzugehen und ihn später in Subroutinen zu zerlegen. Es hat enorm geholfen.
Es heißt Refactoring-Kumpel und es ist gut, Sie müssen es nur einschränken, damit Sie am Ende nicht Ihren gesamten Refactoring-Code verschwenden und arbeiten, anstatt neuen Code zu schreiben.
Einige der Gründe, warum man umgestalten muss, sind:
Denken Sie darüber nach, einen Rahmen in der Sprache zu lernen, die Sie verwenden (oder in einer anderen Sprache).
Ich denke, dass das Lernen von Frameworks meinen Code eine Million Mal besser gemacht hat. Indem ich die Frameworks (und vor allem, wie sie funktionieren) lerne, habe ich nicht nur Design Patterns gelernt, sondern auch, wie man diese realistisch umsetzen kann.
Betrachten Sie rails, cakephp oder django (vorausgesetzt, Sie sind in einer Skriptsprache; ich kenne keine Desktop-Sprach-Frameworks. Entschuldigung!). Dann schau, wie ihre Teile zusammenpassen.
Tags und Links workflow