kutombawewe.net

Wie kann ich vermeiden, immer das Gefühl zu haben, wenn ich mein Programm von Grund auf neu erstellt habe, würde ich es viel besser machen?

Ich habe eine beträchtliche Menge an Codierung gelernt, aber es war immer in einem wissenschaftlichen Umfeld (nicht in der Informatik), völlig autodidaktisch, ohne dass mich jemand in die richtige Richtung führte. Daher war meine Codierungsreise ... chaotisch. Ich habe jetzt bemerkt, dass ich am Ende, wenn ich eine Art Programm erstelle, am Ende merke, wie ich es viel eleganter, viel effizienter und auf eine Weise hätte tun können, die viel flexibler und einfacher zu verwalten ist. Unter bestimmten Umständen bin ich tatsächlich zurückgegangen und habe die Dinge von Grund auf neu aufgebaut, aber normalerweise ist dies praktisch nicht machbar. Während die meisten meiner Programme bisher relativ klein waren, scheint es ziemlich unhandlich, große Programme jedes Mal, wenn Sie etwas erstellen, komplett neu zu schreiben.

Ich frage mich nur, ist das eine normale Erfahrung? Wenn nicht, wie verhindern Sie dies? Ich habe versucht, Dinge im Voraus zu planen, aber ich kann nicht wirklich alles vorhersehen, bis ich anfange, Code auszuarbeiten.

92
Ashish

Dieses Gefühl ist völlig normal und wird erwartet. Es bedeutet, dass Sie lernen. Fast jedes Mal, wenn ich ein neues Projekt beginne, beginne ich in eine Richtung und gestalte es am Ende anders.

Es ist gängige Praxis, zuerst einen Prototyp zu entwickeln, bevor Sie mit der Realität beginnen. Es ist auch üblich, alten Code erneut aufzurufen und Refactor it. Dies ist einfacher, wenn Ihr Design modular ist - Sie können problemlos Teile für Stück neu entwerfen, ohne Ihr altes Design komplett in den Papierkorb werfen zu müssen.

Für einige Leute hilft es, zuerst Pseudocode zu schreiben. Andere finden es hilfreich, zunächst Kommentare zu schreiben, um zu beschreiben, was der Code tun wird, und dann den Code zu schreiben, sobald die allgemeine Struktur vorhanden ist. Diese beiden Dinge helfen Ihnen dabei, Ihr Design besser zu planen, und vermeiden möglicherweise die Notwendigkeit eines Umschreibens.

Wenn Sie Teil eines Teams sind, ist ein Überprüfungsprozess für den Entwurfsprozess von entscheidender Bedeutung. Lassen Sie Ihren Code von jemandem überprüfen, damit Sie lernen, wie Sie Ihr Design verbessern können.

4
asrjarratt

Dies ist eine sehr häufige Erfahrung

Die meisten Menschen, mit denen ich interagiere, und ich selbst fühlen sich so. Ein Grund dafür ist, dass Sie mehr über die Domäne und die Tools erfahren, die Sie beim Schreiben Ihres Codes verwenden. Dies führt dazu, dass Sie viele Verbesserungsmöglichkeiten erkennen, nachdem Sie Ihr Programm bereits geschrieben haben.

Der andere Grund ist, dass Sie möglicherweise eine Vorstellung von der idealen Clean-Code-Lösung haben und dann die reale Welt und ihre chaotischen Einschränkungen im Weg stehen, sodass Sie gezwungen sind, unvollständige Workarounds und Hacks zu schreiben, die Sie möglicherweise unzufrieden machen.

"Jeder hat einen Plan, bis er ins Gesicht geschlagen wird."

Was tun?

Bis zu einem gewissen Grad müssen Sie lernen zu akzeptieren, dass Ihr Code niemals perfekt sein wird. Eine Sache, die mir dabei geholfen hat, ist die Einstellung: "Wenn ich den Code hasse, den ich vor einem Monat geschrieben habe, bedeutet das, dass ich gelernt habe und ein besserer Programmierer geworden bin.".

Eine Möglichkeit, das Problem zu beheben, besteht darin, ständig nach möglichen Verbesserungen Ausschau zu halten, während Sie kontinuierlich arbeiten und umgestalten. Stellen Sie sicher, dass ein ausgewogenes Verhältnis zwischen Refactoring und Hinzufügen neuer Funktionen/Beheben von Fehlern besteht. Dies hilft nicht bei großen Designproblemen, hinterlässt jedoch im Allgemeinen eine ausgefeiltere Codebasis, auf die Sie stolz sein können.

100

Lernen Sie Refactoring - die Kunst des allmählichen Verbesserns Codes. Wir alle lernen die ganze Zeit, daher ist es sehr häufig klar, dass der Code, den Sie selbst geschrieben haben, besser geschrieben werden könnte.

Sie sollten jedoch in der Lage sein, den vorhandenen Code zu transformieren, um diese Verbesserungen anzuwenden, ohne von vorne beginnen zu müssen.

45
JacquesB

Wenn Sie hervorragende statische Anforderungen haben und diese gut verstehen und Zeit für detaillierte Analysen haben, haben Sie die Möglichkeit, ein gutes Design zu entwickeln, mit dem Sie nach Abschluss des Vorgangs immer noch zufrieden sind.

Selbst in diesem glückseligen Fall können Sie neue Sprachfunktionen erlernen, die zu einem besseren Design beigetragen hätten.

Normalerweise haben Sie jedoch nicht so viel Glück: Die Anforderungen sind weniger als hervorragend und unvollständig, und obwohl Sie dachten, Sie hätten sie verstanden, stellt sich heraus, dass es Bereiche gibt, für die Sie ungültige Annahmen getroffen haben.

Dann ändern sich die Anforderungen, wenn die Benutzer einen Blick auf Ihre ersten Ergebnisse werfen. Dann ändert sich etwas, das die Benutzer nicht kontrollieren, z. Steuerrecht.

Alles, was Sie tun können, ist Design, vorausgesetzt, die Dinge werden sich ändern. Refactor, wenn Sie können, aber erkennen Sie, dass Zeit und Budget oft bedeuten, dass Ihr endgültiges Ergebnis nicht so elegant ist, wie es gewesen wäre, wenn Sie am Anfang gewusst hätten, was Sie jetzt wissen.

Mit der Zeit werden Sie besser in die Anforderungen eintauchen können, die Sie erhalten, und eine Nase bekommen, für die Teile Ihres Designs wahrscheinlich Flexibilität benötigen, um Veränderungen zu absorbieren.

Akzeptieren Sie am Ende jedoch, dass die Änderung konstant ist, und ignorieren Sie den Stich, der besagt, dass ich es besser hätte machen können. Seien Sie stolz und glücklich, dass Sie überhaupt eine Lösung geliefert haben.

9
Wildbill

Wie kann ich vermeiden, immer das Gefühl zu haben, wenn ich mein Programm von Grund auf neu erstellt habe, würde ich es viel besser machen?

Was Sie tun können, ist, einen Wegwerfprototyp zu erstellen, bevor Sie mit dem "echten" Projekt beginnen. Schnell und dreckig. Wenn Sie dann einen Prototyp erhalten, um ein Konzept zu beweisen, lernen Sie das System kennen und erfahren, wie Sie die Dinge richtig machen.

Aber wundern Sie sich nicht, wenn Sie nach N Jahren zu diesem Code zurückkehren und "was für ein Durcheinander" denken.

3
BЈовић

Erinnere dich an dieses Mantra:

Das Vollkommene ist der Feind des Guten .

Die perfekte Lösung ist nicht immer die ideale Lösung. Die ideale Lösung erreicht mit dem geringsten Arbeitsaufwand den Status "gut genug".

  • Erfüllt es alle Anforderungen an Funktionalität und Leistung?
  • Ist es frei von kritischen Fehlern, die Sie in der aktuellen Architektur nicht beheben können?
  • Schätzen Sie, wie viel Arbeit Sie in Zukunft in die Wartung dieser Anwendung investieren werden. Wäre der Aufwand für das Umschreiben größer als der langfristige Aufwand, den es sparen würde?
  • Gibt es eine Möglichkeit, dass Ihr neues Design die Situation tatsächlich verschlimmert?

Wenn Sie all diese Fragen mit Ja beantworten, ist Ihre Software "gut genug" und es gibt keinen guten Grund, sie von Grund auf neu zu schreiben. Wenden Sie die Design-Lektionen, die Sie gelernt haben, stattdessen auf Ihr nächstes Projekt an.

Es ist völlig normal, dass jeder Programmierer in seiner Vergangenheit ein paar unordentliche Programme hat. Während meiner Karriere als Softwareentwickler kam es mehrmals vor, dass ich mir Code ansah, mich fragte: "Welcher Idiot hat dieses Durcheinander geschrieben?", Den Versionsverlauf überprüfte und feststellte, dass ich es vor einigen Jahren war.

3
Philipp

Ich habe versucht, Dinge im Voraus zu planen, aber ich kann nicht wirklich alles vorhersehen, bis ich anfange, Code auszuarbeiten.

Es ist verlockend zu glauben, dass eine perfekte Planung zu einem perfekten Software-Design/einer perfekten Architektur führt. Es stellt sich jedoch heraus, dass dies kategorisch falsch ist. Hier gibt es zwei große Probleme . Erstens stimmen "auf Papier" und "der Code" selten überein, und der Grund dafür ist, dass es einfach ist, sagen, wie es gemacht werden soll, im Gegensatz zu tatsächlich machen. Zweitens werden spät im Entwicklungsprozess unvorhergesehene Änderungen der Anforderungen sichtbar, über die von Anfang an nicht nachgedacht werden konnte.

Haben Sie von der Agilen Bewegung gehört? Es ist eine Denkweise, bei der wir Wert darauf legen, "auf Veränderungen zu reagieren" und nicht "einem Plan zu folgen" (unter anderem) Dinge). Hier ist das Manifest (es ist eine schnelle Lektüre). Sie können sich auch über Big Design Up Front (BDUF) und die Fallstricke informieren.

Leider ist die Unternehmensversion von "Agile" eine Menge Schwindel (zertifizierte Scrum-Master, schwerer Prozess im Namen von "Agile", Erzwingen von Scrum, Erzwingen einer 100% igen Codeabdeckung usw.) und führt normalerweise zu asininen Prozessänderungen, weil Manager denke, Agile ist ein Prozess und eine Silberkugel (von denen es keine ist). Lesen Sie das agile Manifest, hören Sie Leuten zu die angefangen haben dieser Bewegung wie Onkel Bob und Martin Fowler, und lassen Sie sich nicht in die Unsinnversion von "Corporate Agile" hineinziehen.

Insbesondere können Sie in der Regel nur TDD (Test Driven Development) für wissenschaftlichen Code ausführen, und es besteht eine gute Chance, dass Ihr Softwareprojekt erfolgreich wird verdammt gut. Dies liegt daran, dass erfolgreicher wissenschaftlicher Code meistens über äußerst benutzerfreundliche Schnittstellen verfügt, wobei die Leistung ein zweitrangiges (und manchmal konkurrierendes) Problem darstellt, sodass Sie mit einem "gierigeren" Design davonkommen können. TDD erzwingt, dass Ihre Software ultra-nutzbar ist , weil Sie schreiben, wie Sie wollen Dinge, die aufgerufen werden sollen (== idealerweise) bevor Sie sie tatsächlich implementieren. Es erzwingt auch kleine Funktionen mit kleinen Schnittstellen , die schnell aufgerufen werden können Eine einfache "Eingabe"/"Ausgabe" -Methode, die Sie in eine gute Position versetzt, um zu überarbeiten , falls sich die Anforderungen ändern.

Ich denke, wir können uns alle einig sein, dass numpy eine erfolgreiche wissenschaftliche Computersoftware ist. Ihre Schnittstellen sind klein, super benutzerfreundlich und alles spielt gut zusammen. Beachten Sie, dass das Referenzhandbuch von numpy TDD ausdrücklich empfiehlt: https://docs.scipy.org/doc/numpy- 1.15.1/reference/testing.html . Ich habe TDD in der Vergangenheit für SAR-Bildgebungssoftware (Synthetic Aperature Radar) verwendet: und ich kann auch behaupten, dass es für diese bestimmte Domäne sehr gut funktioniert.

Vorsichtsmaßnahme: Der Designteil von TDD funktioniert weniger gut in Systemen, in denen ein grundlegendes Refactoring (z. B. die Entscheidung, dass Ihre Software in hohem Maße gleichzeitig ausgeführt werden muss) schwierig ist , wie in einem verteilten System. Wenn Sie beispielsweise etwas wie Facebook entwerfen müssten, bei dem Sie Millionen von Benutzern gleichzeitig haben, wäre es ein Fehler, TDD (um Ihr Design voranzutreiben) auszuführen (immer noch in Ordnung, nach zu verwenden. == Sie haben ein = vorläufig entwerfen und einfach "erste Entwicklung testen"). Es ist wichtig, über die Ressourcen und die Struktur Ihrer Anwendung nachzudenken vorher in den Code zu springen. TDD wird Sie niemals zu einem hochverfügbaren, verteilten System führen.

Wie kann ich vermeiden, dass ich mich immer besser fühle, wenn ich mein Programm von Grund auf neu erstellt habe?

Angesichts des oben Gesagten sollte es etwas offensichtlich sein, dass ein perfektes Design tatsächlich unmöglich zu erreichen ist, also ist die Jagd nach einem perfekten Design ein Narrenspiel. Das können Sie wirklich nur nah kommen. Selbst wenn Sie denken Sie von Grund auf neu gestalten können, gibt es wahrscheinlich noch versteckte Anforderungen, die sich nicht gezeigt haben. Außerdem dauert das Umschreiben mindestens so lange, bis der ursprüngliche Code entwickelt wurde. Es wird mit ziemlicher Sicherheit nicht kürzer sein, da es wahrscheinlich ist, dass das neu Design selbst unvorhergesehene Probleme hat und Sie alle Funktionen des alten Systems neu implementieren müssen.

Eine andere zu berücksichtigende Sache ist, dass Ihr Design nur wirklich wichtig ist wenn sich die Anforderungen ändern. Es spielt keine Rolle, wie schlecht das ist Design ist, wenn sich nie etwas ändert (vorausgesetzt, es ist für die aktuellen Anwendungsfälle voll funktionsfähig). Ich arbeitete an einer Basislinie mit einer 22.000-Zeilen-Switch-Anweisung (die Funktion war sogar noch länger). War es schreckliches Design? Verdammt ja, es war schrecklich. Haben wir es behoben? Nein, es hat gut funktioniert, und dieser Teil des Systems hat nie wirklich Abstürze oder Fehler verursacht. In den zwei Jahren, in denen ich an dem Projekt beteiligt war, wurde es nur einmal berührt, und jemand, Sie haben es erraten, hat einen weiteren Fall in den Schalter eingefügt. Aber es lohnt sich nicht, sich die Zeit zu nehmen, um etwas zu reparieren, das so selten berührt wird, dass es einfach nicht so ist. Lassen Sie das unvollkommene Design so sein, wie es ist, und wenn es nicht kaputt ist (oder ständig bricht), reparieren Sie es nicht. Vielleicht machen Sie könnten besser ... aber wäre es eine Umschreibung wert? Was wirst du gewinnen?

HTH.

3

Ich stimme der Antwort von Andreas Kammerloher voll und ganz zu, bin jedoch überrascht, dass noch niemand vorgeschlagen hat, einige bewährte Methoden für das Codieren zu lernen und anzuwenden. Natürlich ist dies kein Wundermittel, aber wenn Sie einen offenen Ansatz verwenden, Muster entwerfen, verstehen, wann Ihr Code riecht usw., werden Sie zu einem besseren Programmierer. Untersuchen Sie, wie Bibliotheken, Frameworks usw. am besten genutzt werden können. Es gibt noch viel mehr. Ich kratzte nur an der Oberfläche.

Es bedeutet nicht, dass Sie Ihren alten Code nicht als totalen Müll betrachten (Sie werden tatsächlich die ältesten Programme noch mehr Müll sehen als ohne dieses Wissen), aber mit jeder neuen Software, die Sie schreiben, werden Sie sehen du verbesserst dich. Beachten Sie auch, dass die Anzahl der Best Practices für die Codierung mit der Zeit zunimmt. Einige ändern sich einfach, sodass Sie tatsächlich nie zur Perfektion gelangen. Akzeptiere dies oder ganz den Weg.

Eine weitere gute Sache ist eine Code-Revision. Wenn Sie alleine arbeiten, ist es einfach, Ecken zu schneiden. Wenn Sie eine zweite Person haben, die Ihren Code überprüft, kann diese darauf hinweisen, wo Sie diese Best Practices nicht befolgen. Auf diese Weise produzieren Sie besseren Code und lernen etwas.

2
Ister

Um die anderen hervorragenden Antworten hier zu ergänzen, ist eine Sache, die ich hilfreich finde, zu wissen, wohin Sie wollen.

Es ist selten, dass man die Erlaubnis für ein größeres Refactoring alleine erhält. Sie können jedoch häufig kleinere Refactoring-Schritte ausführen, während Sie an jedem Bereich der Codebasis „unter dem Radar“ arbeiten. Und wenn Sie ein Ziel vor Augen haben, können Sie diese Möglichkeiten nutzen, um Schritt für Schritt in die richtige Richtung zu gehen.

Es kann lange dauern, aber die meisten Schritte verbessern den Code und das Endergebnis wird es wert sein.

Das Gefühl, dass Sie es besser machen könnten, ist ein gutes Zeichen ! Es zeigt, dass Ihnen die Qualität Ihrer Arbeit am Herzen liegt und dass Sie sie kritisch bewerten. Sie lernen also wahrscheinlich und verbessern sich. Lassen Sie sich von diesen Dingen nicht beunruhigen - aber hören Sie nicht auf, sie zu tun!

1
gidds

Sie sind versehentlich auf eine der größten Herausforderungen (Abenteuer) der Menschheit gestoßen, die Brücke zwischen Mensch und Maschine. Die Brücke zwischen Mensch und physischer Struktur, zum Beispiel im Bauwesen, besteht seit mindestens 200 Jahren.

Da die Softwareentwicklung erst in den 90er Jahren zum Mainstream wurde, ist sie ungefähr 30 Jahre alt. Wir haben gelernt, dass es sich weniger um eine Ingenieurdisziplin als um eine Sozialwissenschaft handelt, und wir haben gerade erst begonnen.

Ja, Sie werden TDD, Refactoring, funktionale Programmierung, das Repository-Muster, Ereignisbeschaffung, MV-etwas, Java Skript (<- Tun Sie dies, es ist verrückt)), Modellbindung, kein SQL, Container ausprobieren , Agile, SQL (<- mach das, es ist mächtig).

Es gibt keine Lösung. Sogar die Experten greifen immer noch nach Strohhalmen.

Willkommen und seien Sie gewarnt, es ist ein einsamer Ort. aber absolut faszinierend.

1
Marius

Ich werde ein wenig gegen den Strich gehen. Dies ist unglaublich üblich , aber nicht akzeptabel . Dies weist darauf hin, dass Sie beim Schreiben keine guten Möglichkeiten zum Organisieren Ihres Codes erkennen. Das Gefühl kommt von Ihrem Code nicht einfach.

Ihre Erfahrung war auch lange Zeit meine, aber in letzter Zeit (in den letzten paar Jahren) habe ich mehr Code produziert, der nicht das Gefühl vermittelt, ich müsste werfen alles weg. Folgendes habe ich ungefähr getan:

  1. Machen Sie sich klar, welche Annahmen ein bestimmter Codeblock macht. Wirf Fehler, wenn sie nicht erfüllt werden. Denken Sie isoliert darüber nach , ohne von Details darüber abhängig zu sein, was der Rest der Software tut. (Was der Rest der Software tut, beeinflusst, welche Annahmen Sie erzwingen und welche Anwendungsfälle Sie unterstützen, hat jedoch keinen Einfluss darauf, ob Sie einen Fehler auslösen, wenn eine Annahme verletzt wird.)
  2. Hören Sie auf zu glauben, dass das Befolgen von Regeln, Mustern und Praktiken zu gutem Code führt. Werfen Sie Denkweisen und Praktiken weg, die nicht offensichtlich und unkompliziert sind. Dieser war riesig. OO und TDD werden normalerweise auf eine Weise unterrichtet, die nicht auf praktischen Überlegungen beruht, als eine Reihe abstrakter Prinzipien, denen Sie beim Schreiben von Code folgen sollten. Dies ist jedoch für die tatsächliche Entwicklung von gutem Code völlig nicht hilfreich Wenn Sie OO oder TDD überhaupt) verwenden, sollte es als Lösung für Probleme verwendet werden, von denen Sie verstehen, dass Sie haben. Mit anderen Worten, sie sollten es tun Verwenden Sie es nur, wenn Sie sich ein Problem ansehen und denken: „Okay, das ist absolut sinnvoll und als gute Lösung äußerst offensichtlich.“ Nicht vorher.
  3. Konzentrieren Sie sich beim Schreiben von Code auf zwei Fragen:
    • Benutze ich Features und Bibliotheken so, wie sie verwendet werden sollen ? Dies schließt die Verwendung für die Arten von Problemen ein, die gelöst werden sollten, oder zumindest für sehr ähnliche.
    • Ist es einfach ? Werden meine Mitarbeiter und ich später in der Lage sein, der Logik leicht zu folgen? Gibt es Dinge, die aus dem Code nicht sofort ersichtlich sind?

Mein Code ist jetzt "prozeduraler", womit ich meine, dass er nach organisiert ist, welche Aktionen er ausführt und nicht nach welchen Datenstrukturen er verwendet. Ich verwende Objekte in Sprachen, in denen eigenständige Funktionen nicht im laufenden Betrieb ersetzt werden können (C # und Java kann Funktionen im laufenden Betrieb nicht ersetzen, Python kann). Ich habe die Tendenz, jetzt mehr Utility -Funktionen zu erstellen, die nur ein nerviges Boilerplate aus dem Weg schieben, damit ich die Logik meines Codes tatsächlich lesen kann. (ZB wenn ich es brauchte Um alle Kombinationen von Elementen in einer Liste zu verarbeiten, habe ich die Indexschleife auf eine Erweiterungsmethode verschoben, die Tuples zurückgibt, damit die ursprüngliche Funktion nicht mit diesen Implementierungsdetails überladen wird.) Ich übergebe viel mehr Dinge als Parameter für Funktionen jetzt, anstatt dass eine Funktion ein anderes Objekt erreicht, um es abzurufen. (Der Aufrufer ruft es ab oder erstellt es stattdessen und übergibt es.) Ich hinterlasse jetzt weitere Kommentare, die Dinge erklären, die sind nicht nur beim Betrachten des Codes offensichtlich, was das Befolgen der Logik einer Methode erleichtert. Ich schreibe Tests nur in begrenzten Fällen, wenn ich über die Logik o besorgt bin Für etwas, das ich gerade gemacht habe, und ich vermeide es, Mocks zu benutzen. (Ich mache mehr Eingabe-/Ausgabetests für isolierte Logikteile.) Das Ergebnis ist Code, der nicht perfekt ist, aber tatsächlich in Ordnung zu sein scheint , auch 2 oder 3 Jahre später. Es ist Code, der ziemlich gut auf Änderungen reagiert. Kleinere Dinge können hinzugefügt oder entfernt oder geändert werden, ohne dass das gesamte System auseinander fällt.

Bis zu einem gewissen Grad müssen Sie eine Zeit durchlaufen, in der die Dinge durcheinander sind, damit Sie etwas Erfahrung haben, von der Sie abgehen können. Aber wenn die Dinge immer noch so durcheinander sind, dass Sie alles wegwerfen und von vorne anfangen möchten, stimmt etwas nicht. du lernst nicht.

1
jpmc26

Indem Sie sich daran erinnern, dass Ihre Zeit begrenzt ist. Und Ihre zukünftige Zeit ist ebenfalls begrenzt. Ob für Arbeit, Schule oder persönliche Projekte, wenn es um Arbeit Code geht, müssen Sie sich fragen: "Ist das Umschreiben die beste Verwendung meiner begrenzten und wertvollen Zeit?". Oder vielleicht "ist dies die verantwortungsvollste Nutzung meiner begrenzten Zeit"?

Manchmal ist die Antwort eindeutig ja. Normalerweise nicht. Manchmal ist es auf dem Zaun und Sie müssen Ihre Diskretion anwenden. Manchmal ist es eine gute Nutzung Ihrer Zeit, einfach wegen der Dinge, die Sie dadurch lernen werden.

Ich habe viele berufliche und persönliche Projekte, die von einem Port/Rewrite profitieren würden. Ich habe auch andere Dinge zu tun.

0
Jared Smith

Es ist ein ganz normaler Teil des Lernens. Sie erkennen Fehler, wenn Sie gehen.

Auf diese Weise werden Sie besser und sollten dies nicht vermeiden.

0
mathreadler

Sie können sich die Erfahrung machen, zu wissen, dass der verführerische Drang zum Umschreiben normalerweise unproduktiv ist. Finden Sie ein altes, haariges, unelegantes Open-Source-Projekt von mittlerer Komplexität. Versuchen Sie, es von Grund auf neu zu schreiben, und sehen Sie, wie Sie es tun.

  • War Ihr Design von Grund auf so elegant, wie Sie es sich erhofft hatten?
  • Ist Ihre Lösung wirklich genau das gleiche Problem? Welche Funktionen haben Sie ausgelassen? Welche Edge-Fälle haben Sie verpasst?
  • Welche hart verdienten Lektionen im ursprünglichen Projekt haben Sie im Streben nach Eleganz gelöscht?
  • Ist es nach dem Hinzufügen dieser fehlenden Teile zu Ihrem Design so sauber wie ohne sie?

Irgendwann wird sich Ihr Instinkt von dem Gedanken "Ich könnte dieses System so viel besser umschreiben" zu dem Gedanken "Die Kruftigkeit dieses Systems kann auf eine Komplexität hinweisen, die nicht sofort erkennbar ist" ändern.

0
Maxpm