it-swarm.com.de

Ein großer Teil meines Codes weist einen großen Designfehler auf. Beenden Sie es oder reparieren Sie es jetzt?

Ich bin ein Gymnasiast, der mit einem Freund an einem C # -Projekt arbeitet und ungefähr die gleichen Fähigkeiten wie ich besitzt. Bisher haben wir ungefähr 3.000 Codezeilen und 250 Testcodezeilen in einem Zeitraum von 100 Commits geschrieben. Aufgrund der Schule habe ich das Projekt für einige Monate verschoben und konnte es kürzlich wieder aufnehmen.

Als ich es wieder aufgenommen hatte, war mir klar, dass der von mir geschriebene Code schlecht gestaltet war, z. B. die Aufnahme übermäßiger Threads in den Renderer, die schlechte Verhinderung von Race-Bedingungen bei der Interaktion zwischen emulierter CPU, GPU und Spielekassette sowie Code, der einfach redundant und verwirrend ist.

Das Problem ist, dass ich noch nicht einmal die Hauptfunktionalität meines Programms fertiggestellt habe, so dass ich nicht wirklich umgestalten kann, und ich fühle mich entmutigt, weiterhin genau zu wissen, dass das Design meines Codes fehlerhaft ist. Gleichzeitig möchte ich das Projekt nicht aufgeben; Es wurden erhebliche Fortschritte erzielt, und die Arbeiten dürfen nicht umsonst sein.

Ich habe das Gefühl, dass ich ein paar Möglichkeiten habe: einfach die Funktionalität zu beenden, indem ich das schlechte Design umarbeite und dann umgestalte, sobald alles funktioniert, alles anzuhalten und darauf hinzuarbeiten, alles zu entwirren, bevor der Rest der Funktionalität abgeschlossen werden kann, und das Projekt zu starten überall, so dass es wieder frisch in meinem Kopf ist oder das Projekt aufgrund seiner übermäßigen Größe (im Wesentlichen "zurück zum Zeichenbrett") regelrecht abbricht.

Was ist der Rückgriff, um mich auf den richtigen Weg zu bringen, basierend auf den Erfahrungen anderer in solchen Projekten? Aus den Antworten auf dieser Website geht allgemein hervor, dass ein Umschreiben ist im Allgemeinen nicht erforderlich , aber eine verfügbare Option, wenn der Code nicht ohne übermäßige Kosten gepflegt werden kann. Ich würde dieses Projekt wirklich gerne weiterverfolgen, aber so wie es aussieht, ist mein Code nicht gut genug gestaltet, um fortzufahren, und ein Gefühl der Verzweiflung lenkt mich davon ab, fortzufahren.

188
oldmud0

Wenn ich in deinen Schuhen stecke, würde ich es wahrscheinlich so versuchen:

  • beenden Sie zunächst das aktuelle Projekt - zumindest teilweise - so bald wie möglich, aber in einem funktionierenden Zustand. Wahrscheinlich müssen Sie Ihre ursprünglichen Ziele reduzieren und über die Mindestfunktionalität nachdenken, die Sie in "Version 1.0" wirklich sehen müssen.

  • dann und nur dann Denken Sie an ein Umschreiben von Grund auf neu (nennen wir dies "Version 2.0"). Vielleicht können Sie einen Teil des Codes aus V1.0 wiederverwenden. Vielleicht können Sie nach dem erneuten Schlafen über die Situation die Entscheidung treffen, V1.0 umzugestalten und das meiste davon zu speichern. Treffen Sie diese Entscheidung jedoch nicht, bevor Sie keinen "Proof of Concept V1.0" zur Hand haben.

Ein Arbeitsprogramm "1.0" können Sie anderen zeigen, auch wenn der Code schlecht ist (worüber sich niemand außer Ihnen selbst Gedanken machen wird). Wenn Sie während der Erstellung von V2.0 feststellen, dass Ihnen die Zeit ausgeht, haben Sie V1.0 immer noch als Teilerfolg, was für Ihre Moral viel besser ist. Wenn Sie jedoch V1.0 nicht zuerst beenden, besteht eine große Chance, dass Sie V2.0 nie fertigstellen, denn wenn Sie zur Hälfte fertig sind, wird es einen Punkt geben, an dem Sie mit dem Design wieder unzufrieden sind, und dann? Wirst du V2.0 wieder verlassen und an V3.0 arbeiten? Es besteht ein hohes Risiko, in diesen nie endenden Kreis zu geraten und niemals zu enden.

Nutzen Sie dies besser als Gelegenheit, um zu lernen, wie Sie Zwischenziele erreichen, anstatt zu lernen, wie Sie Projekte in einem unvollendeten Zustand zurücklassen.

272
Doc Brown

Abgeschlossene IT-Projekte, auch fehlerhafte, sind viel besser als unvollendete.

Unfertige können Ihnen auch viel beibringen, aber nicht so viel wie fertige.

Sie sehen es jetzt vielleicht nicht, aber Sie erhalten eine enorme Menge an Wert, wenn Sie mit fehlerhaftem Code arbeiten.

Meine Stimme geht zum Abschluss und dann vielleicht zum Refactoring - falls nötig. Wenn Sie anfangen, mit mehr Projekten zu arbeiten, werden Sie überraschend oft feststellen, dass der Teil, der "überarbeitet werden sollte", jahrelang unberührt bleibt, während andere Teile erweitert werden.

Aus beschäftigungspolitischer Sicht erhalten Sie in den meisten Fällen mehr Lob für ein abgeschlossenes Projekt.

119
tymtam

Ich würde das Projekt gerne von vorne beginnen.

Du bist ein Student und lernst noch. Dies bringt Sie in eine ganz andere Position als die Frage, mit der Sie verlinkt haben.

  • Sie haben keine berufliche Verantwortung für Ihren Code. Wenn Sie das gesamte Projekt jetzt löschen und weggehen würden, würden Sie keine Auswirkungen haben. Dies ist ein großer Vorteil für einen Entwickler. In der von Ihnen verlinkten Frage versuchen diese Entwickler, Software zu warten, für die die Leute Geld bezahlen, und selbst kleine Fehler können große Probleme bei Kunden verursachen, was es gefährlich macht, von Grund auf neu zu schreiben. Sie haben dieses Problem nicht.

  • Als persönliches Projekt ist dies die perfekte Gelegenheit, neue Dinge auszuprobieren und aus Ihren Fehlern zu lernen. Es ist großartig, dass Sie erkennen, dass Ihr alter Code Probleme hat, denn das bedeutet, dass Sie gelernt haben, wie man es besser macht. Erfahrung durch Ausprobieren kann für Anfänger von unschätzbarem Wert sein.

  • Ihr Projekt ist relativ klein und Sie haben im Grunde keine Tests. Es könnte ein paar Nächte dauern, bis 3000 Zeilen von Grund auf neu geschrieben sind, zumal Sie bereits Ideen haben, was Sie beim nächsten Mal besser machen können.

  • Das Arbeiten in einer kaputten Codebasis belastet Ihre Moral weitaus mehr als das Umschreiben.

Abgesehen davon kann dies eine gute Gelegenheit sein, ein modulareres Programm mit Unit-Tests zu schreiben. Dies erleichtert das Verständnis des Codes erheblich, wenn Sie nach einer langen Pause darauf zurückgreifen, und hilft, Fehler zu vermeiden, die Sie möglicherweise versehentlich aufgrund von Vergesslichkeit verursachen.

Schließlich ist hier eine Meinung über die Weisheit, manchmal Schritte rückwärts zu machen, um größere Schritte vorwärts zu machen.

56
Hylianpuffball

Sie befinden sich wahrscheinlich noch im "schnell lernen" Teil Ihrer Entwicklung. Es besteht eine gute Chance, dass Sie in einigen Monaten feststellen werden, dass Ihr neues und fantastisches Design in einer Weise schrecklich kaputt ist, die Sie zu Beginn nicht einmal bemerkt haben.

Dinge erledigen - Dies ist das Wichtigste, was Sie lernen müssen. Glauben Sie mir, ich kenne viele Leute (nicht nur Programmierer), die in der Schleife "von vorne anfangen, da ich so viel gelernt habe, bevor ich mit diesem Projekt angefangen habe" stecken. Das Problem ist, dass es endet nie - bis du aufhörst neue Dinge zu lernen, was kein schöner Ort ist :)

Es ist auch wichtig, um tatsächlich etwas fertigstellen zu können. Neu anzufangen ist aufregend, cool, macht Spaß ... aber wenn Sie das nur lernen, werden Sie nie in der Lage sein, etwas zu beenden. Auch dies ist keine sehr nützliche Fähigkeit, und es fühlt sich tatsächlich nicht so gut an, als würde man etwas Nützliches (oder Spaßiges) machen. Das Leben ist kurz, die Zeit ist begrenzt, und Sie können nicht einfach ohne greifbare Ergebnisse weiter üben - Sie werden davon ziemlich verrückt. Wenn Sie nicht in der Lage sind zu arbeiten, weil Sie sich einfach nicht entscheiden können, welchen Ansatz Sie wählen möchten, befinden Sie sich bereits in der Gefahrenzone.

Es wird immer Impulse geben, von vorne zu beginnen. Selbst in einer Lernumgebung sind diese höchstwahrscheinlich eine schlechte Idee. Das bedeutet nicht, dass Sie jeden einzelnen Prototyp zu einer produktionsbereiten Anwendung bringen müssen, weit davon entfernt. Aber Sie müssen zumindest eine funktionierende Prototypenphase erreichen - dies wird höchstwahrscheinlich Ihrer Moral helfen und ist eine sehr nützliche Eigenschaft für Entwickler jeglicher Art. Dinge erledigen. Und der lustige Teil ist, dass Sie schnell feststellen werden, dass Sie mit Ihrem Prototyp eine Million lustiger oder nützlicher Dinge tun können, anstatt ihn "von Grund auf neu zu schreiben" - und in vielen Fällen sogar umzugestalten. Alles, was Sie tun, ist mit Kosten verbunden - zumindest hätten Sie in der Zwischenzeit etwas anderes tun können.

33
Luaan

Ich folge der "Lass es funktionieren, mach es richtig, mach es schnell" Ideologie in der Softwareentwicklung.

  1. Damit es funktioniert : Schreiben Sie die Kernfunktionalität, damit das Projekt verwendet werden kann. Tun Sie, was Sie tun müssen, damit alles funktioniert, auch wenn es hässlichen Code bedeutet.
  2. Machen Sie es richtig : Beheben Sie Fehler und überarbeiten Sie den Code, damit er leichter zu lesen, zu verstehen und zu warten ist.
  3. Machen Sie es schnell : Optimieren Sie das Programm, um ein ausgewogenes Verhältnis zwischen Geschwindigkeit, Ressourcennutzung und Wartbarkeit zu erreichen.

Im Moment haben Sie Schritt 1 noch nicht abgeschlossen. Lassen Sie es zuerst funktionieren, und dann können Sie sich Sorgen darüber machen, wie hässlich Ihr Code ist. Das Erstellen eines funktionierenden Produkts ist für neue Entwickler eine der schwierigsten Aufgaben, da sie so sehr damit beschäftigt sind, ihren Code beim ersten Mal perfekt zu machen, und daher in der Hölle der Optimierung stecken bleiben und nie wirklich zum Abschluss kommen Implementierung aller Funktionen. Sie müssen lernen, wie Sie all diese Sorgen um Refactoring und Optimierung beiseite legen, damit Sie sich nur darauf konzentrieren können, dass die Software funktioniert. Sobald Sie mehr Erfahrung gesammelt haben, werden Sie natürlich beim ersten Mal mehr Dinge richtig machen, sodass weniger Refactoring erforderlich ist.

Denken Sie daran: vorzeitige Optimierung ist die Wurzel allen Übels (siehe diese ausgezeichnete Programmers.SE-Frage für eine gute Diskussion). Wenn Sie zu viel Zeit damit verbringen, darüber nachzudenken, wie Sie Ihren Code verbessern können, bleiben Sie in Analyse-Lähmung stecken. Dies beendet das Projekt. Es ist besser, das Projekt fertig zu stellen, bevor Sie versuchen, es zu optimieren.

Um einen großartigen Motivationsredner zu zitieren: mach es einfach .

Wie immer gibt es eine relevante xkcd:

(xkcd optimization

25
user200929

Schreibe es um. Nicht funktionierender Code hat wenig Wert und dreitausend Zeilen sind nicht viel Code. Es wird nicht annähernd so lange dauern, bis Sie den aktuellen Code geschrieben haben, und es wird viel besser. Ich habe oft fünfhundert oder tausend Zeilen schlechten Codes weggeworfen, und oft ist das Umschreiben ein Fünftel so lang.

Die meisten Begriffe rund um "Nicht umschreiben" beziehen sich auf große Systeme, die wichtige Dinge tun und sich ständig ändern, um den sich ändernden Anforderungen gerecht zu werden. Das Umschreiben komplexer Systeme ist selten erfolgreich.

Ihre Situation ist genau das Gegenteil. Sie haben eine kleine Anwendung ohne Benutzer und die einzigen Anforderungen sind die, die Sie implementieren möchten. Also mach weiter und schreibe es neu.

23
kevin cline

Ein Neustart von Grund auf ist normalerweise ein schlechter Schritt in realen Projekten, hauptsächlich weil in realen Projekten Fehlerkorrekturen gesammelt werden, die einem neuen Entwickler nicht bekannt sind (z. B. siehe Dinge, die Sie niemals tun sollten , from Joel on Software Blog.)

Trotzdem erben Schulprojekte eine solche Geschichte nicht und beginnen normalerweise damit, dass sie gleichzeitig programmieren und entwerfen, wobei sie teilweise über Computerkenntnisse und mangelnde Erfahrung verfügen. Ich würde Ihre erste Version als Prototyp betrachten, der als fehlgeschlagener Proof of Concept verwendet wird, und ich würde sie gerne wegwerfen (siehe Was sind die Unterschiede zwischen wegwerfbaren und evolutionären Prototypen? für eine Diskussion über Wegwerfen vs. evolutionäres Prototyping.)

Das richtige Design ist in Ihrem Kopf gereift und sollte nicht viel Zeit in Anspruch nehmen, um es in Code zu schreiben.

19
mouviciel

Ich würde den Vorschlägen, dass das Umschreiben eine schlechte Idee ist, respektvoll widersprechen.

Im Bereich des Software-Lebenszyklus wird allgemein angenommen, dass der Zeit- und Arbeitsaufwand zur Korrektur eines Fehlers in jeder Schicht des Lebenszyklus um eine Größenordnung zunimmt. Das heißt, wenn es 1 Stunde dauert, um einen Fehler auf der Anforderungsebene zu korrigieren, dauert es 10 Stunden im Design, 100 Stunden im Codierungstest und 1000 Stunden als Fehlerbehebung. Diese Zahlen mögen empörend klingen, aber sie werden von der Industrie als ungefähr korrekt anerkannt. Natürlich weniger in einem kleineren Projekt, aber die allgemeine Idee bleibt. Wenn Ihr Projekt einen grundlegenden Designfehler aufweist, ist es besser, dies als Lernerfahrung zu bezeichnen und zurück zu gehen, Ihre ursprünglichen Anforderungen zu überprüfen und neu zu entwerfen.

Ich würde auch empfehlen, ein testgetriebenes Entwicklungsmodell mit strukturierten Komponententests in Betracht zu ziehen. Sie sind ein Schmerz und scheinen zunächst Zeitverschwendung zu sein, aber ihre Fähigkeit, Fehler aufzudecken, insbesondere bei der Integration in den Code eines anderen, kann nicht überbewertet werden.

12
dlb

Du hast mich bei diesem Satz verloren:

Das Problem ist, dass ich noch nicht einmal die Hauptfunktionalität meines Programms fertiggestellt habe, so dass ich nicht wirklich umgestalten kann, und ich fühle mich entmutigt, weiterhin genau zu wissen, dass das Design meines Codes fehlerhaft ist.

Ich glaube an das Prinzip (angegeben in Systemantics ), dass

  • Ein komplexes System, das funktioniert, hat sich aus einem einfachen System entwickelt, das funktioniert.
  • Ein komplexes System, das von Grund auf neu entwickelt wurde, funktioniert nie und kann nicht gepatcht werden, damit es funktioniert. Sie müssen von vorne beginnen und mit einem funktionierenden einfachen System beginnen.

Das Schreiben eines komplexen Systems umfasst also

  • Ein einfaches System schreiben
  • Stellen Sie sicher, dass es funktioniert

... d. h. die folgenden Schritte:

  1. Schreiben Sie ein bisschen Code
  2. Testen Sie es, um sicherzustellen, dass es funktioniert
  3. Schreiben Sie etwas mehr Code
  4. Nochmal testen
  5. Usw.

Beachten Sie, dass Schritt 3 Folgendes umfassen kann:

  1. Schreiben Sie etwas mehr Code
    1. Refaktorieren Sie vorhandenen Code, um ihn für neue Ergänzungen vorzubereiten
    2. Testen Sie das Refactoring, um sicherzustellen, dass es weiterhin funktioniert
    3. Fügen Sie die neue Funktionalität hinzu

In Schritt 2 "Testen, um sicherzustellen, dass es funktioniert" wird möglicherweise etwas umgeschrieben, wenn dies nicht der Fall ist.

Wenn ich auf einer faulen Codebasis aufbauen würde, wäre ich nicht geneigt, weitere Funktionen hinzuzufügen. Daher würde ich gerne etwas wie "Vereinfachung der vorhandenen Threading-Implementierung" als nächste zu implementierende Arbeit planen. Angenommen, Sie haben im Laufe der Zeit Tests durchgeführt, sollten Sie dies als Refactoring-Übung behandeln können. Die Erfolgs-/Ausstiegskriterien für diese Arbeitsphase wären:

  • Der Quellcode ist einfacher
  • Und keine neuen Bugs eingeführt
  • (Und einige alte Fehler beseitigt)

Im Übrigen bedeutet "Testen, um sicherzustellen, dass es funktioniert" nicht unbedingt "Komponententests". Wenn die Teamstruktur einfach ist, können Sie ein (einfaches) System mit (einfachen) Systemtests (statt Einheit) testen Tests) .

10
ChrisW

Eines der Probleme, mit denen Sie konfrontiert sind, wenn Sie auf ein solches Problem stoßen, ist, dass Sie emotional an den Code gebunden sind, den Sie bisher auf die eine oder andere Weise geschrieben haben.

Ein Kollege erzählte mir, dass er während seines Studiums ein Programm schrieb, während er Unterricht bei einem berühmten Professor erhielt (ich glaube, es war Dijkstra). Er bat den Professor, sich den Code anzusehen, an dem er seit über einem Monat gearbeitet hatte. Der Professor fragte ihn, ob er ein Backup gemacht habe, er antwortete nein. Der Professor löschte dann seinen gesamten Code und forderte ihn auf, ihn erneut zu schreiben.

Er war sauer, aber 3 Tage später beendete er das Programm mit sauberem Code und weniger Fehlern und weniger Codezeilen.

Versuchen Sie, eine ehrliche Schätzung darüber abzugeben, welche Option in der für das Projekt verfügbaren Zeit am besten ist.

Die 3 Möglichkeiten sind

  • Löschen Sie es (vollständig, kein Rückblick)
  • Arbeiten Sie weiter im alten Design
  • Refactor-Code, während Sie gehen.

Ich bin seit über 10 Jahren ein professioneller Programmierer, und in meiner Arbeit bin ich zu dem Schluss gekommen, dass die letzte Option meistens die gewählte ist, aber nicht immer die beste.

7
Alfons

Refactor. Refactor. Refactor! REFACTOR !!!!

Ganz ehrlich, egal wie erfahren Sie sind, dies ist ein häufiges Problem. Sie haben Code geschrieben, etwas gelernt und möchten das neue Wissen für den alten Code nutzen. Sie möchten den alten Code mit dem neuen Wissen messen.

Das wird einfach nicht funktionieren. Wenn Sie dies tun, wird Ihre Anwendung/Ihr Spiel niemals abgeschlossen. Versuchen Sie stattdessen, Ihre Zeit dem Projekt zuzuweisen, damit einige Ihrer "Aufgaben" darin bestehen, den fehlerhaften Code zu überarbeiten. Nehmen wir zum Beispiel an, Sie hatten eine schreckliche Methode, um das Spiel zu speichern. Arbeiten Sie weiter am Spiel selbst, aber finden Sie etwas Zeit, um diese schreckliche Methode zu überarbeiten (zu ersetzen). Versuchen Sie, die Refaktoren klein zu halten, und es sollte kein Problem sein.

Wenn Sie zu einem Großteil der Anwendung gelangen, der einen Refactor benötigt, machen Sie es ernsthaft falsch. Teilen Sie das Refactoring in kleinere Teile auf. Versuchen Sie, sieben Stunden lang Code zu schreiben und eine Stunde lang umzugestalten.

Wenn Sie mit dem Projekt fertig sind und auf Feature Freeze klicken, können Sie einige Zeit mit Refactoring verbringen. Machen Sie das Spiel erst einmal fertig, aber versuchen Sie trotzdem, einige zu überarbeiten. Das ist das Beste, was du tun kannst.

Es wird immer etwas zu überarbeiten geben.

6
coteyr

Es hört sich so an, als ob Ihre Fähigkeiten in diesem Zeitraum erheblich gewachsen sind. Vielleicht hat die Arbeit an diesem Projekt dazu beigetragen. Es wäre fruchtbar, es erneut als gezielte Lernerfahrung zu gestalten.

Denken Sie daran, dass Sie dies nicht als Arbeitsprogramm für einen Kunden bereitstellen müssen. Es wurde speziell für die Praxis geschrieben. Wenn Sie also nicht üben möchten, Versandprobleme und fehlerhafte Lieferung zu haben, befinden Sie sich derzeit in einer Entwicklungsphase, in der sich die Arbeit an Ihren "Design-Muskeln" als fruchtbar erweisen würde.

Konzentrieren Sie sich dabei auf den Entwurfsprozess und die Planung, überlegen Sie sich Ihre vorhandenen Inhalte und überlegen Sie, was Sie besser verstehen.

6
JDługosz

Ich würde sagen, es hängt ein bisschen davon ab, welche Art von Code Sie jetzt haben und wo genau die Probleme liegen. Das heißt, wenn Ihre Grundlagen gut sind (größtenteils richtiges Klassendesign, gute Entkopplung/Kohäsion usw., nur ein paar schlechte Entscheidungen wie die von Ihnen erwähnten Fäden), dann holen Sie auf jeden Fall einen Bare-Bones 1.0 heraus und dann wie einen Refactor es gibt kein Morgen.

Auf der anderen Seite, wenn es wirklich nur ein Haufen hässlicher zusammengeschlagener Textdateien ist, die irgendwie am Compiler vorbeikommen, ohne erkennbare Struktur usw. (mit anderen Worten, ein Proof-of-Concept-Prototyp für das Lernen am Arbeitsplatz), dann lösche ich es lieber und fange von vorne an.

Gehen Sie bei Ihrer nächsten Version agil vor: Legen Sie einen festen Zeitplan für die Wiederholung fest, z. B. 2 Wochen oder was auch immer zu Ihrem Zeitplan passt. Setzen Sie sich zu Beginn jedes Blocks (nennen wir es einen Sprint) Ziele, die in den zwei Wochen erreichbar sind. Mach weiter und mach sie, versuche dein verdammtes Bestes, damit es funktioniert. Setzen Sie Ihre Ziele so, dass Sie alle 2 Wochen etwas haben, das einem Freund gezeigt werden kann, nicht nur eine abstrakte interne Arbeit. Google "Scrum" und "Smart Goal". Dies ist alles sehr einfach, wenn Sie alleine sind, nur ein Stück Papier mit ein paar schnell notierten Aufzählungspunkten.

Wenn Sie das können, ist es gut, von vorne zu beginnen. Wenn Sie tief im Inneren wissen, dass Sie nach dem Neustart wahrscheinlich sowieso dort landen, wo Sie jetzt sind, bleiben Sie bei Ihrem Code und lassen Sie ihn funktionieren.

4
AnoE

Sie müssen sich in die Lage des Arbeitgebers versetzen.

Für die meisten Personalvermittler wären Sie am wertvollsten, wenn Sie diesen Weg gehen: - Beenden Sie den Vorgang mit 100% -Tests für den neuen Code, den Sie schreiben. - Fügen Sie Tests für den alten (schlecht gestalteten) Code hinzu. - Refactor es, um das zu erreichen, was Sie als Design wollten.

Machen Sie das alles mit einem guten Versionsprozess, Zweigen und Tags.

Das Umschreiben ist oft eine sexy Idee, aber es ist oft eine Idee, die Neulinge haben, was im wirklichen Leben irgendwie gefährlich ist. Zu zeigen, dass Sie eher bereit sind, die Qualität Ihrer bereits geleisteten Arbeit zu verbessern, als von vorne zu beginnen, ist ein gutes Zeichen dafür, dass Sie eine ernsthafte Person sind.

Sie können es natürlich umschreiben, aber dann ein anderes Projekt daraus machen.

3

Nur um einige meiner bisherigen Erfahrungen in die Mischung aufzunehmen. Ich arbeite jetzt seit über einem Jahr an einem Nebenprojekt, wenn ich ein paar Minuten Zeit habe. Dieses Projekt ging von einem einfachen Prüfstand über eine statische Klasse zu einem objektorientierten, schlanken Design über, das es derzeit ist.

Während all dieser Änderungen habe ich die gleiche Funktionalität des Codes beibehalten, mit Ausnahme von Fehlerkorrekturen und Leistungsvorteilen (muss so schnell wie möglich sein). Die gleiche Codebasis, obwohl überarbeitet, ist dieselbe geblieben, und als solche habe ich sie massiv verbessert, ohne den Code von Grund auf neu schreiben und Zeit verschwenden zu müssen.

Dies hat dazu geführt, dass ich den Code schneller verbessern konnte als zuvor. Es bedeutete auch, dass es auf meinem Weg einfacher war zu sagen, was entfernt werden musste, d. H. Unnötige Klassen, und was einfacher bleiben konnte, als mit der alten Idee, die ich noch im Kopf hatte, neu zu schreiben.

Daher würde ich raten, Ihren Code umzugestalten und von dort aus gegebenenfalls Verbesserungen vorzunehmen. Denken Sie jedoch daran, wenn Sie sich entscheiden, von Grund auf neu zu schreiben, sollten Sie die guten Ideen des alten Projekts aufgreifen und sie genau betrachten, um festzustellen, wo sie fehlerhaft sind. Das heißt, Kopieren Sie nicht nur alten Code in das neue Projekt.

3
TheLethalCoder

Die Antwort hängt von etwas ab, das ich gerne als "Komplexitätsobergrenze" bezeichne. Wenn Sie einer Codebasis mehr und mehr hinzufügen, besteht die Tendenz, dass sie immer komplexer und immer weniger organisiert wird. Irgendwann werden Sie eine "Komplexitätsgrenze" erreichen, an diesem Punkt wird der Fortschritt sehr schwierig. Anstatt zu versuchen, mit brutaler Gewalt in Bewegung zu bleiben, ist es besser, zu sichern, neu zu organisieren/neu zu schreiben und dann weiter vorwärts zu gehen.

Ist Ihre Codebasis also so schlecht, dass Sie sich einer Komplexitätsgrenze nähern? Wenn Sie dies spüren, nehmen Sie sich etwas Zeit, um zu bereinigen und zu vereinfachen, bevor Sie fortfahren. Wenn der einfachste Weg zum Aufräumen darin besteht, einige Teile neu zu schreiben, ist das in Ordnung.

3
Alex D

Die erste Frage, die Sie sich stellen sollten, lautet: "Wie schlimm ist der Fehler?"

Was genau hast du falsch gemacht?

Wenn etwas so schlimm ist, dass Sie Tonnen von Stunden damit verschwenden, mit dem Problem zu arbeiten, vertrauliche Daten (Passwörter/Kreditkarten) offen zu legen oder eine schlechte Sicherheitslücke zu verursachen, sollten Sie es vielleicht bearbeiten, aber die meiste Zeit können Sie es Nehmen Sie, was Sie haben, beenden Sie es und beheben Sie das Problem später.


Programmierer lieben es, ihre Anwendungen zu verbessern und möchten, dass sie "das Beste sind, was es sein kann", aber das ist nicht der richtige Ansatz.

WENN Sie Ihre Anwendung so schnell wie möglich veröffentlichen, auch wenn es nicht 100% sind, Fehler und alle, dann erhalten Sie FEEDBACK von anderen, während Sie Zeit haben, diese zu beheben die Bugs und andere Sachen für Version 1.1. Andere Leute können Ihnen helfen, die Anwendung so viel besser zu machen, und Sie haben möglicherweise verschwendete Zeit etwas getan, das den Leuten möglicherweise nicht gefallen hat.

Holen Sie es sich in Ihrem Fall heraus, holen Sie sich Feedback, und strukturieren Sie dann Version 2.0 mit allen Änderungen und beheben Sie den Fehler, den Sie haben.


Eine andere Sache, an die wir uns erinnern sollten, ist, dass wir uns ständig verbessern. Es gibt ein Sprichwort: Wenn Sie sich Ihren Code von vor einem Jahr ansehen und feststellen können, dass er schlecht ist, bedeutet dies, dass Sie sich immer noch verbessern, und das ist eine großartige Sache.

2
XaolingBao

Wenn Ihr Code modular aufgebaut ist, sollten Sie in der Lage sein, den Rest des Codes um die schlecht geschriebenen Komponenten herum fertigzustellen und dann die schlecht geschriebenen Komponenten neu zu schreiben, ohne den Rest des Codes zu beeinflussen.

In diesem Fall liegt es an Ihnen, die schlecht geschriebenen Komponenten neu zu schreiben. Wenn die schlecht geschriebenen Komponenten so schlecht geschrieben sind, dass der fertige Code nicht so funktioniert, wie sie sind, müssen Sie sie neu schreiben, bevor Sie den Rest des Codes fertigstellen können.

2
Micheal Johnson

Weder? Beide?

Fahren Sie fort, nehmen Sie sich etwas Zeit, um das vorhandene Design zu überarbeiten und neue Funktionen hinzuzufügen.

Wenn Sie rassige Interaktionen haben, ist dies möglicherweise ein guter Ausgangspunkt ("übermäßige Threads im Renderer" klingen eher nach Ineffizienz als nach etwas, das zu Korrektheitsproblemen führen würde). Sehen Sie nach, ob Sie entweder einen allgemeinen Weg finden können, um von Rennen (und möglicherweise Deadlocks) wegzukommen, oder zumindest mehrere spezifische Wege, dies zu tun.

Ich weiß nicht, inwieweit Deadlock- und Race-Detektoren für C # verfügbar sind, aber wenn sie vorhanden sind, können sie hilfreich sein, um festzustellen, welche Probleme vorliegen, und um zu überprüfen, ob Ihre Korrekturen funktionieren.

Ich finde, dass ich im Allgemeinen motivierter bin, Probleme mit Code zu beheben, der etwas Nützliches bewirkt, anstatt ihn wegzuwerfen und wieder von vorne zu beginnen. Es gibt Fälle, in denen die Entwicklung von verbranntem Feld (in Analogie zu Greenfield und Brownfield ...) zufriedenstellender ist, aber dies gilt normalerweise für Dinge, bei denen der bestehende Ansatz so weit von dem entfernt ist, wo er sein sollte, dass er nicht einmal mehr falsch ist.

2
Vatine

Es hängt davon ab, wie durcheinander Ihr Code ist.

  • Wenn Sie echte n00b-Fehler gemacht haben, die Ihren Code zu komplex oder ausführlich machen, würde ich empfehlen, diese Teile neu zu schreiben.

  • Wenn Sie glauben, dass Sie schwerwiegende Fehler haben, die Sie ohnehin beheben müssen, schreiben Sie einige Komponententests, mit denen überprüft werden kann, ob Sie den Fehler behoben haben (... da Sie das Programm noch nicht starten können). Es ist besser, Fehler frühzeitig zu beheben, und es ist definitiv besser, Fehler zu beheben, während Sie sich noch daran erinnern, was der Code tut.

  • Wenn Ihnen der Name der Methoden oder die Klasse, zu der sie gehören, oder solche kleinen Dinge nicht gefallen, verwenden Sie einfach die IDE. (Denken Sie daran, dies ist C #, nicht Javascript, Python, Perl, PHP usw.) Wenn Sie an Code arbeiten, der die betroffene Komponente verwendet, und Sie ein klares Bild im Kopf haben, was diese Komponente tun sollte, Überarbeiten Sie es dann, wenn Ihre IDE es schmerzlos macht.

Andernfalls können Sie es zum Laufen bringen und Ihre Fähigkeiten beim nächsten Projekt verbessern.

1

Wie andere vorgeschlagen haben, würde ich, da dies ein persönliches Projekt ist, (noch) kein professionelles Projekt, ernsthaft eine Neufassung in Betracht ziehen.

Sie können die wissenschaftliche Methode hier jedoch nutzen, indem Sie ein Experiment durchführen. Stellen Sie sich zunächst eine Hypothese vor. Meins wäre: "Es ist wahrscheinlich Zeit für ein Umschreiben." Um Zeit zu sparen, die Ausfallkosten zu senken und die Abweichung von vornherein etwas einzuschränken, bevor Sie weitere Programmierungen vornehmen, legen Sie eine Zeitspanne fest ("Zeitfenster"). Ich würde vielleicht 4 Wanduhrstunden vorschlagen. Entscheiden Sie sich auch für eine Methode zur Bewertung der Hypothese. Da die Einsätze niedrig sind, würde ich als Methodik vorschlagen, fragen Sie sich einfach: "Bin ich froh, dass ich das getan habe?" Beginnen Sie nun mit dem Experiment. Wie wird die Hypothese nach dem von Ihnen gewählten Zeitrahmen bewertet? z.B. Sind Sie nach meinem Beispiel froh, dass Sie mit dem Umschreiben begonnen haben, nachdem Sie 4 Stunden damit verbracht haben? Dann ist es wahrscheinlich die richtige Wahl.

Sie können um alle Ratschläge der Welt bitten, aber es gibt nichts Schöneres, als eine Hypothese empirisch zu testen.

Einige Gründe, warum Sie eine Umschreibung als Experiment auswählen sollten:

  • Nach meiner Erfahrung macht es normalerweise mehr Spaß. Ein wichtiger Grund, warum Umschreibungen in beruflichen Situationen oft nicht ausgewählt werden, ist, dass Spaß nicht das einzige Kriterium ist. Aber Sie sind noch relativ neu im Codieren, daher ist Spaß wahrscheinlich ein ziemlich wichtiges Kriterium und auch ein Indikator für andere Faktoren, die für Sie in diesem frühen Stadium möglicherweise nicht greifbar sind (Spaß deutet darauf hin, dass Sie mehr lernen werden usw.).
  • Ihre Erfahrung und wahrscheinlich ein nagendes Gewissen scheinen Ihnen zu sagen, dass ein Umschreiben eine Überlegung wert ist. Hören Sie diese Stimme, wenn es eine gibt. Auch wenn Sie den Ratschlägen nicht folgen, hören Sie zumindest zu. In Zukunft wird es mehr externe Stimmen geben, und Sie müssen üben, auf Ihren eigenen gesunden Menschenverstand zu hören.
  • Ich vermute, dass Sie mit einem Umschreiben Ihren Code eher modularisieren. Wenn Sie Module erstellen, verfügen Sie über wiederverwendbarere und zuverlässigere Komponenten, die Sie für andere Projekte nutzen können. Vielleicht stellen Sie am Ende sogar fest, dass sich das, was als bloßes Modul Ihres Hauptprojekts erschien, als das interessanteste und wertvollste Stück Code herausstellt, das Sie schreiben.

Etwas zu beenden ist eine gute Idee, aber nicht im luftleeren Raum. Wenn Sie mit dem Umschreiben beginnen, können Sie sich dafür entscheiden, etwas zu beenden, indem Sie ein bestimmtes Untermodul fertigstellen. Sie können dies als erstes Ziel nach dem obigen Experiment festlegen. Die Fertigstellung muss noch nicht die Fertigstellung Ihres ersten Hauptprojekts bedeuten. Wenn Sie ein Modul fertiggestellt haben, beenden Sie ein anderes usw., bis Sie den gesamten Umfang Ihres ursprünglichen Projekts neu geschrieben haben, wenn Sie möchten.

1
Will