Was ist so schlimm an kreativem Coding? [geschlossen]

42

Ich habe Bob Ross dabei zugesehen, wie er heute Abend ein paar "fröhliche Bäume" gemalt hat, und ich habe herausgefunden, was mich in letzter Zeit an meinem Code gestresst hat.

Die Gemeinschaft der Leute hier und auf Stack Overflow scheint jeden Hauch von Unvollkommenheit abzulehnen. Mein Ziel ist es, seriösen (und daher wartbaren und funktionierenden) Code zu schreiben, indem ich meine Fähigkeiten verbessere. Trotzdem programmiere ich kreativ.

Lassen Sie mich erklären, was ich unter "kreativ codieren" verstehe:

  • Meine ersten Schritte in einem Projekt sind oft, dass ich mich hinsetze und Code ausprobiere. Für größere Dinge plane ich hier und da ein bisschen, aber meistens tauche ich nur ein.
  • Ich zeichne keine meiner Klassen, es sei denn, ich arbeite mit anderen zusammen, die andere Teile im Projekt erstellen. Selbst dann ist es sicherlich nicht das erste, was ich tue. Normalerweise arbeite ich nicht an großen Projekten und finde das Visuelle nicht sehr nützlich.
  • Die erste Runde des Codes, die ich schreibe, wird viele Male umgeschrieben, wenn ich den ursprünglichen Hack teste, vereinfache, erneut durchführe und in etwas Wiederverwendbares, Logisches und Effizientes umwandle.

Während dieses Vorgangs putze ich immer. Ich entferne nicht verwendeten Code und kommentiere alles, was nicht offensichtlich ist. Ich teste ständig.

Mein Prozess scheint dem zu widersprechen, was in der professionellen Entwickler-Community akzeptabel ist, und ich würde gerne verstehen, warum.

Ich weiß, dass das meiste an schlechtem Code darin besteht, dass jemand mit dem Durcheinander eines ehemaligen Mitarbeiters feststeckt, und es viel Zeit und Geld kostet, dies zu beheben. Das verstehe ich. Was ich nicht verstehe, ist, wie mein Prozess falsch ist, da das Endergebnis dem ähnlich ist, was Sie bei der Planung von Anfang an erhalten würden. (Oder zumindest habe ich das gefunden.)

Meine Besorgnis über das Problem war in letzter Zeit so groß, dass ich mit dem Programmieren aufgehört habe, bis ich weiß, dass alle Methoden zur Lösung des jeweiligen Problems, an dem ich arbeite, bekannt sind. Mit anderen Worten, ich habe größtenteils aufgehört zu programmieren.

Ich danke Ihnen von ganzem Herzen für Ihre Beiträge, unabhängig von Ihrer Meinung zu diesem Thema.

Bearbeiten: Vielen Dank für Ihre Antworten. Ich habe von jedem etwas gelernt. Sie waren alle sehr hilfreich.

Brad
quelle
6
An Ihrer Arbeitsweise ist nichts falsch, Sie wissen, worauf es beim Endergebnis ankommt und worauf es wirklich ankommt. Es ist nur so, dass Sie es möglicherweise schwer haben, mit einem großen Team zu arbeiten, aber Sie werden sich wahrscheinlich anpassen, wenn dies der Fall ist. Es hört sich wirklich so an, als würden Sie sich direkt auf den Weg zur Analyseparalyse machen: sourcemaking.com/antipatterns/analysis-paralysis
Bjarke Freund-Hansen
39
Das monatelange Umschreiben erspart Ihnen Tage der Planung!
Jonas
3
@Jonas: Gut. Aber Sie sollten Analysis Paralysis wirklich nicht unterschätzen. Bei all den "guten Ratschlägen" zu Methoden, Entwurfsmustern usw. ist es heutzutage wirklich einfach, den Eindruck zu erwecken, dass Sie tagelang planen, analysieren und entwerfen sollten, bevor Sie überhaupt eine einzelne Codezeile berühren . Und das kann leicht sehr kontraproduktiv werden. Die Realität, von der ich glaube, ist zu verstehen, was Planen und Entwerfen auf lange Sicht für Sie hilfreich sein kann, und zu verstehen, wann Sie eintauchen müssen, um ein Gefühl für das zu bekommen, woran Sie arbeiten, und um tatsächlich etwas zu tun.
Bjarke Freund-Hansen
4
Aus dem Agile-Manifest: "Arbeitssoftware ist das primäre Maß für Fortschritt."
Gary Rowe
2
Es ist fast so, als ob die Programmierwelt voller Primadonnen ist. Ich kann dir nicht sagen, wie frustrierend es ist, auf SO zu gehen und eine perfekt gültige Frage fünfmal heruntergestuft zu sehen, weil der Benutzer nicht in perfektem Englisch schreibt oder der Code als "zu Anfänger" für die Elite betrachtet wird, um damit umzugehen.
Scottie

Antworten:

29

Es ist nichts falsch an Code-Test-Refactor-Repeat. Sagen Sie einfach den Leuten, dass Sie Prototypen erstellen.

Auf der anderen Seite werden Sie bei größeren Projekten feststellen, dass einige Überlegungen zum Design im Vorfeld viel Zeit in der Oh-Crap-Now-What-Schleife sparen!

PS: Diagrammtechniken helfen Ihnen beim Erlernen visueller Denkfähigkeiten, die auch dann von Nutzen sind, wenn niemand außer Ihnen Ihre Diagramme jemals sieht.

Steven A. Lowe
quelle
4
"Code-Test-Refactor-Repeat" (oder eine Permutation davon) ist, wie wir Code schreiben. Vielleicht ist Superman "code-done", aber Sterbliche müssen iterieren.
Martin Wickman
5
@Martin: Ein bisschen Vorausdenken in dieser Schleife ist oft von Vorteil ;-)
Steven A. Lowe
4
solange du weißt wie viel "einiges" ist!
Frank Shearar
Danke für Ihre Antwort. Ich hatte nie gedacht, dass ich Prototypen bauen würde, aber genau das mache ich. Ihre Antwort hat mir eine neue Sichtweise gegeben, und ich schätze Ihre Antwort sehr.
Brad
7
@Brad, denken Sie daran, dass Prototypen gelegentlich sterben müssen, anstatt sich zu entwickeln.
21

Ich bevorzuge immer klaren, lesbaren, einfachen Code gegenüber visuell dargestelltem UMLed-Code mit Entwurfsmuster, bei dem Klassen- / Schnittstellennamen wie "ItemVisitor" (?!) Enthalten sind. Entwurfsmuster, OO-Techniken und alles andere dienen dazu, Regeln zu formalisieren. Diese Regeln kommen aus dem gesunden Menschenverstand.

Es ist unmöglich, ohne diese Formalisierung zu arbeiten (es sei denn, Sie arbeiten alleine an Ihrem eigenen Projekt), und die Überformalisierung erhöht die Projektkosten. Ignorieren Sie niemals die Bedürfnisse anderer, um Ihren Code zu verstehen. Der beste Code ist der einfachste.

Zögern Sie nie, Ihren Code neu zu schreiben. Ich werde dafür X Abwertungen (X> = 10) erhalten, aber ich werde es fett machen: Wiederverwendbarkeit von Code ist nicht das Wichtigste .

Bevor Sie mit dem Codieren beginnen , sollten Sie die Anwendungsfälle berücksichtigen, die der Code implementieren wird. Weil die Software benutzt und nicht entwickelt werden soll. Benutzerfreundlichkeit, Nützlichkeit sind zwei der wichtigsten Ziele, und es spielt keine Rolle, wer diese Software verwenden wird - ein anderer Entwickler abhängiger Teile des Projekts oder der Endbenutzer.

Duros
quelle
4
+1 für "Wiederverwendbarkeit von Code ist nicht das Wichtigste". Manchmal braucht man ein Schweizer Taschenmesser, manchmal ein Skalpell.
mu ist zu kurz
Vielen Dank für Ihre Kommentare. In Bezug auf die Verwendung der resultierenden Software ist dies während des gesamten Prozesses unbedingt zu beachten. Ich stimme zu, das ist der wichtigste Teil. Ich erwähnte die Wiederverwendbarkeit von Code, da dies einen langen Weg zur Erreichung dieses Ziels darstellt.
Brad
Nochmals +1 für "Wiederverwendbarkeit von Code ist nicht das Wichtigste" und keine einzige Ablehnung (bisher)
Gary Rowe
Ich denke, der extreme Fokus auf "Wiederverwendbarkeit" lag auf einer kleinen Version von Don't Repeat Yourself und der Beseitigung von Duplikaten.
Rob K
"Use before Reuse" hat es sogar in ein schönes kleines Buch geschafft: 97things.oreilly.com/wiki/index.php/…
Lovis
14

Mir geht es ähnlich. Hören Sie zu, wenn andere Leute Ihnen von Dingen erzählen, die für sie gearbeitet haben, aber ignorieren Sie jeden, der Ihnen sagt, was Sie tun sollten, als gäbe es einen moralischen Imperativ. Wenn Sie etwas finden, das für Sie funktioniert, machen Sie es mit. Ich meine, das Endergebnis ist, was wichtig ist, nicht wahr? Wen interessiert der Weg, den Sie dorthin eingeschlagen haben?

Denken Sie daran: Menschen sind anders . Das ist gut. Hören Sie nicht auf Leute, die versuchen, Sie dazu zu bringen, sie zu mögen, und widerstehen Sie dem Drang, andere Menschen dazu zu bringen, Sie zu mögen, und Sie werden es gut machen.

Jason Baker
quelle
Wer sagt, dass etwas getan werden soll, muss gute Gründe haben, es vorzuschlagen. Wenn sie keinen guten, klaren und logischen Grund liefern können, dann wird ihr "sollte" ein "vielleicht sollte".
der Blechmann
1
@ Greg - Trotzdem könnte ein guter, klarer und logischer Grund für Sie für mich völlig unlogisch sein.
Jason Baker
1
+1. Wer sagt, dass man das unbedingt tun sollte und das ist einfach falsch. Sicher, Sie müssen lernen und anderen zuhören (besonders den großen und erfahrenen), überlegen, alternative Ansätze ausprobieren und vergleichen usw., aber am Ende müssen Sie das tun, was Sie für richtig halten. Wenn Sie nur mittelmäßig sein möchten, folgen Sie dem Designprozess, aber für alles, was es wert ist, müssen Sie sich selbst vertrauen.
Joonas Pulakka
+1 - Ich persönlich beginne vielleicht mit einem Diagramm oder mache es auf offizielle Weise, aber das liegt daran, dass die offizielle Art und Weise für mich funktioniert. Man kann den Leuten nicht wirklich beibringen, schlauer oder kreativer zu werden. Sie sind Erwachsene, die auf ihre Art und Weise eingestellt sind. Sie stellen sie entweder ein oder nicht.
Job
6

Anscheinend sind Sie:

  1. Versuche, den besten Ansatz zu finden (experimentieren, inkrementelles Design)
  2. Code umschreiben, um ihn sauberer zu machen (Refactoring)
  3. Ständig Tests schreiben (testgetriebene Entwicklung)

Was Sie tun, ist fantastisch! Es sieht so aus, als ob Sie es richtig machen, besonders wenn Sie es selbst herausgefunden haben und es nicht aus einem (agilen) Programmierbuch gelernt haben. Das hat natürlich noch mehr zu bieten, aber Sie haben die richtigen Werte gefunden. Denken Sie daran, das Design zu überarbeiten und zu verbessern, während Sie Code hinzufügen, und es sollte kein BDUF erforderlich sein .

Haben Sie darüber nachgedacht, sich auf jeweils eine kleine Funktion zu konzentrieren und diese nach Abschluss jeder Funktion freizugeben? Dies kann Ihnen helfen, sich von Analyseproblemen zu lösen, mit denen Sie zu kämpfen haben, und zeigt Ihrem Arbeitgeber echte Fortschritte auf.

Ich weiß auch nicht, von welcher "Community für berufliche Entwicklung" Sie sprechen, aber wenn Sie es wären, würde ich sie bitten, zu ihren Elfenbeintürmen zurückzukehren, damit Sie mit Ihrer Arbeit weitermachen können!

Martin Wickman
quelle
Ich bin voll auf Ihrer Seite, was meine eigene Antwort widerspiegelt.
Eric O Lebigot
4

Brad, du bist nicht allein. Ich kenne sehr gute Programmierer, die genau so arbeiten, wie Sie es beschreiben. :)

Wenn Sie Ihren Code bereinigen und wissen, wie Sie ihn effizient und lesbar machen, haben Sie mit Sicherheit ein Gespür dafür entwickelt, wie Sie sauberen und effizienten Code auch im Voraus schreiben können.

Darüber hinaus kann nichts vollständig im Voraus geplant werden, und der kürzeste Weg zur Entdeckung von Feinheiten besteht häufig darin, den Code auszuführen und übersehene Details zu verstehen.

Ich denke, dass es Ihnen gut geht und dass der von Ihnen beschriebene Programmierstil vollkommen gültig ist.

Eric O Lebigot
quelle
4

Ich denke, es lohnt sich, die obigen Antworten mit einem Zitat von Alan J. Perlis aus dem Vorwort des bekannten MIT-Buches "Structure and Interpretation of Computer Programs" (Struktur und Interpretation von Computerprogrammen) zu vervollständigen, das allgemein als "SICP" bezeichnet wird:

Jedes Computerprogramm ist ein im Kopf schraffiertes Modell eines realen oder mentalen Prozesses. Diese Prozesse, die sich aus menschlicher Erfahrung und menschlichem Denken ergeben, sind zahlreich, im Detail kompliziert und werden zu jedem Zeitpunkt nur teilweise verstanden. Sie werden von unseren Computerprogrammen selten zu unserer ständigen Zufriedenheit modelliert. Obwohl unsere Programme sorgfältig handgefertigte diskrete Sammlungen von Symbolen, Mosaiken von ineinandergreifenden Funktionen, sind, entwickeln sie sich ständig weiter: Wir ändern sie, während sich unsere Wahrnehmung des Modells vertieft, vergrößert, verallgemeinert, bis das Modell letztendlich einen metastabilen Platz innerhalb eines weiteren Modells erreicht, mit dem wir kämpfen. "

Yugo Amaryl
quelle
gut gesagt. Sie sind primitive Modelle, humanistische Modelle und schließlich übermenschliche Modelle, wenn der Programmierer mehr und mehr über die Aktionen nachdenkt, die im Code stattfinden.
easymoden00b
3

Es gibt gute und schlechte Clever.

Guter Schlauer - hohes Verhältnis zwischen geschickten Codezeilen und Zeilen in einer nicht geschickten Alternative. 20 Codezeilen, die Sie vor dem Schreiben von 20000 Zeilen bewahren, sind extrem gut und clever. Bei Good Clever geht es darum, sich die Arbeit zu sparen.

Schlecht klug - Geringes Verhältnis zwischen geschriebenen und gespeicherten Codezeilen. Eine Zeile cleveren Codes, die Sie davon abhält, fünf Zeilen Code zu schreiben, ist Bad Clever. Schlecht klug ist über "syntaktische Masturbation".

Nur zur Erinnerung: Bad Clever wird so gut wie nie "Bad Clever" genannt. es wird oft unter den Pseudonymen "schön", "elegant", "prägnant" oder "prägnant" reisen.

user8865
quelle
1
"schön", "elegant", "prägnant" oder "prägnant". ..... Ich glaube, ich habe das einmal auf der Ruby on Rails-Homepage gesehen. :-D
Brad
1
Vielleicht bin ich es nur, aber ich denke, eine 80% ige Reduzierung des LOC ist etwas Klugheit wert.
rekursiver
Ich habe viele gefunden, die Sachen als "syntaktische Masturbation" bezeichnen, obwohl es eigentlich nur darum geht, dass sie zu faul sind, die Sprache zu lernen, die sie benutzen ...
Svish
3

Ich kann mich definitiv daran erkennen, wie Sie Ihren Workflow beschreiben. Hier ist die Sache: Als ich anfing, in einer Gruppenumgebung zu arbeiten, musste sich fast alles ändern.

Der Job, in dem ich jetzt seit ungefähr 8 Monaten bin, ist wirklich meine erste Erfahrung, in einem Entwicklerteam an einem einzigen Projekt zu arbeiten. Bis jetzt war meine ganze Karriere buchstäblich als Einsamer-Wolf-Kodierer, der sich nicht um alles kümmern musste, was mit Teamarbeit verbunden ist. Sogar wenn ich in einer Gruppe arbeitete, war es immer ziemlich albern - ich hatte mein Projekt, das MINE war, oder meinen Abschnitt, der MINE war, usw. Es war eine interessante Lernkurve, als ich mich mit a auf den neuesten Stand brachte wirklich kollaborative Teamarbeitsumgebung.

Das Wichtigste, was mir aufgefallen ist: Wenn nicht ganz klar ist, was Sie tun, schreiben Sie wahrscheinlich die nächsten Kopfschmerzen eines Kollegen. Die meiste "prozessorientierte" Aufregung, die Sie hier sehen, hat damit zu tun, dass viele von uns der Kollege mit den Kopfschmerzen waren. Und die meisten Softwareprozessmanagement-Theorien haben mit der Minimierung dieser Kopfschmerzen zu tun.

Also Dinge wie die Planung eines vereinbarten Plans im Voraus, usw. ... Es geht darum, ein Team an Bord und synchron zu haben. Wenn Sie das Team sind, sind Sie bereits mit sich selbst synchronisiert, und das ist nicht wirklich notwendig.

Dan Ray
quelle
2

Es ist nichts Falsches an Ihrer Herangehensweise als kreative Kunstform. Wenn Sie sich zum persönlichen Vorteil entwickeln und das, was Sie tun, für Sie funktioniert und Spaß macht, sind Sie wahrscheinlich genauso wichtig wie das Endergebnis wie das Produkt selbst.

In einem professionellen Arbeitsumfeld spricht man von einem Rapid Prototyping-Ansatz, wenn die Projektlaufzeiten kurz sind, z. B. 2-3 Wochen oder weniger, und er ist für die anstehenden Aufgaben angemessen.

Bei längeren Projekten, auch wenn Sie alleine arbeiten, ist ein solcher Ansatz wahrscheinlich ein teurer Luxus für Ihren Arbeitgeber. Ein paar Tage des Projektbudgets für das Design von Upfront-Architekturen und das Testen der Architektur im Vergleich zu dem, was passiert, wenn das Management beschließt, die Spezifikation zu ändern, bis ... ist in der Regel viel Zeit aufgewendet in deiner Karriere.

Michael Shaw
quelle
2

Zwei Perspektiven:

  1. Niemand muss ein Gemälde pflegen.

  2. Jeder, der jemals Bob Ross beim Malen eines Gemäldes zugesehen hat, weiß, dass Gemälde eine Struktur haben. Wenn Sie Bob Ross eine Lektion abnehmen würden, ließe sich der Prozess reibungslos und einfach gestalten, wenn Sie vorausplanen und auf organisierte Weise arbeiten.

Caleb
quelle
1
Bob Ross hat die glücklichen Bäume nie gemalt, bevor er den Himmel dahinter gemalt hat.
Rob K
1

Ich codiere ziemlich genau so. Ich werde einfach anfangen zu schreiben und als ich Muster auftauchen sehe, überarbeite ich sie. Sie können sich auf diese Weise in eine Ecke malen. Sie müssen wissen, wann Sie sich zurücklehnen und über ein Problem nachdenken müssen, aber manchmal müssen Sie nur einen Stich hineinstecken, um das Problem wirklich zu verstehen .

Aber ich bin neugierig:

Die Gemeinschaft der Leute hier und auf Stack Overflow scheint jeden Hauch von Unvollkommenheit abzulehnen. [..] Mein Prozess scheint dem zu widersprechen, was in der professionellen Entwickler-Community akzeptabel ist, und ich würde gerne verstehen, warum.

Wie sollte jemand auf Stack - Überlauf kennen Ihren Prozess? Und was meinst du mit "ablehnen"? Natürlich wird Code, der an eine Programmiergemeinschaft gesendet wird, kritisch geprüft. Aber wenn jemand Bereiche entdeckt, in denen Ihr Code verbessert werden kann, kann das nur gut sein, oder?

Wenn Sie eine Frage an Stackframe senden, bereinigen Sie hoffentlich Ihren Code und versuchen, ihn aus Respekt vor Ihren Lesern auf die einfachste Form zu reduzieren (manchmal lösen Sie Ihr eigenes Problem, indem Sie nur versuchen, ihn für andere präsentierbar zu machen) Bei jedem Feedback ist das gut. Wenn Sie wissen , dass eine Postleitzahl schlecht ist und Sie wissen, warum sie schlecht ist, bevor Sie sie veröffentlichen, sollten Sie sie nicht persönlich nehmen, wenn die Leute bemerken, dass sie schlecht ist.

Schlamm
quelle
Ich bezog mich nicht auf Fragen oder Antworten, die ich persönlich gestellt habe. Wenn ich Fragen stelle, teile ich sie in den einfachsten Fall ein, und das Gleiche gilt für meine Antworten. Mir ist aufgefallen, dass andere, die in ihren Fragen nicht so perfekten Code posten oder nicht genau wissen, wie sie die richtige Frage stellen sollen, wiederholt abgeschossen werden. In Grenzfällen, in denen die Frage einer guten nahe kommt, bearbeite ich sie häufig oder füge Kommentare hinzu, um das OP in die richtige Richtung zu lenken. Ich glaube nicht, dass das normalerweise passiert. [mehr im nächsten Kommentar]
Brad
Nachdem ich die Antworten auf meine Frage hier gelesen habe, habe ich auf jeden Fall das Gefühl, die Community falsch gelesen zu haben und die Kritik an Antworten auf die Kritik an vollständigen Projekten projiziert zu haben, was, wie Sie deutlich gemacht haben, zwei verschiedene Dinge sind.
Brad
1

Ich benutze auch Ihren Ansatz. Es funktioniert besser für mich, da es das Risiko von Überentwicklung verringert.

Was ich sehr oft tue, ist, ein Problem mit wahrscheinlich dem geringstmöglichen Code zu lösen, was normalerweise zu offensichtlich unnötigen Abhängigkeiten oder anderen Designproblemen führt. Dann überarbeite ich Arbeitscode in schönen Code.
Zum Beispiel reduziere ich die Abhängigkeiten zwischen verschiedenen Modulen, um die Schnittstellen kurz zu halten, und überlege, welche Daten wo gespeichert werden sollen, bis jedes Modul nur noch von sehr minimalistischen Abstraktionen der anderen Module abhängt. Man könnte sagen, ich verschiebe die endgültige Entscheidung, welches Modul welche Verantwortung tragen soll. Ich verschiebe die Abstraktion.
Es ist nicht gut, zu viel darüber nachzudenken, ein Problem in unterschiedliche Verantwortlichkeiten, in unterschiedliche Abstraktionen zu unterteilen. Es wird Sie zwingen, Ihre Implementierung so zu verbiegen, dass sie zu den von Ihnen erstellten Abstraktionen passt. Code funktioniert, wenn er die gewünschten Ergebnisse liefert und wartbar ist. Ein Design funktioniert, wenn Sie es durch guten Code implementieren können. Wenn der Code nicht funktioniert, ändern Sie ihn. Ergo, wenn ein Design nicht funktioniert, müssen Sie es ebenfalls ändern. Sie können erst sehen, ob ein Entwurf funktioniert, wenn Sie ihn implementiert haben.

Eine einfache Skizze zu haben, reicht also als Entwurf aus, bevor Sie sie zum Leben erwecken. Redesign, Abstract und Refactor nach Bedarf .

back2dos
quelle
1

Ich denke, wenn man gut programmieren kann, muss es zumindest manchmal Spaß machen, und das bedeutet, kreativ zu sein.

Sicherlich gibt es beim Programmieren in Gruppen zumindest Mindeststandards, die befolgt werden sollten, nicht aus "moralischen" Gründen, sondern aus praktischen Gründen, wenn sie gelten.

Abgesehen davon ist es interessant und macht Spaß, nach den Grenzen zu suchen, um zu sehen, was dort zu finden ist. Als ich an einem Mini in Assembler-Sprache arbeitete, stellte ich fest, dass Sie Co-Routinen erstellen können, die mit einer Anweisung von einer zur anderen wechseln. Dann fand ich heraus, wie man eine Selbst-Co-Routine macht, die zwei Schritte vorwärts, einen Schritt zurück usw. gehen kann. War es nützlich? Das bezweifle ich. Das ist nicht der Punkt.

Einmal hörte ich einen Vortrag von Edsger Dijkstra über Kreativität in der Programmierung. Er erwähnte, wie ein Student einen Weg fand, ein n-Bit-Rotation eines n + m-Bit-Wortes durchzuführen. Es wurde mit 3 Bitswaps gemacht. Zuerst vertauschen Sie die n Bits, dann die m Bits und dann die gesamten n + m Bits. Nützlich? Clever? Ja.

Es tut gut, Dinge auszuprobieren, die niemand mit Verstand tun würde.

Mike Dunlavey
quelle
1

Dies kann ein Fall von "eine Größe passt nicht für alle" sein. Sie haben Ihren Stil für die Projekte, an denen Sie gearbeitet haben, zum Tragen gebracht. Wen streitet das? Die Kritiker, die Sie hier und in SO lesen, arbeiten jedoch möglicherweise an größeren Projekten oder an Projekten, die eine komplexe Koordination zwischen den Teammitgliedern erfordern.

Ihr Entwicklungsstil könnte zu einem Problem werden, wenn Sie jemals in größere Projekte involviert waren, bei denen mehrere Entwickler zusammenarbeiten. Es ist schwer, dies zu planen, es ist schwierig, Ihre Fortschritte zu verfolgen, und es gibt keine Möglichkeit für Ihre Programmierkollegen, den Teil ihrer Arbeit zu planen, der davon abhängt, zu wissen, was Ihr Teil Ihrer Arbeit tut.

Vielleicht möchten Sie Dreaming in Code lesen, um zu sehen, was passieren kann, wenn ein großes Projekt einen ähnlichen Entwicklungsstil wie Ihren annimmt.

Charles E. Grant
quelle
1
Danke für Ihre Antwort. Ihre Kommentare sind für mich hilfreich.
Brad
1

Ich versichere Ihnen, dass Ihre Methode nicht falsch ist, aber lassen Sie mich einige persönliche Erfahrungen hinzufügen. Ich habe mich auf den Weg gemacht, aber in der Zwischenzeit habe ich den Vorteil gelernt, zumindest einen Teil der allgemeinen Struktur im Voraus zu planen, und zwar aus einer Reihe von Gründen:

  • Das größte Extra ist, dass es einfacher ist zu sehen, welcher Code wiederverwendet werden kann, wenn ein wenig herumgearbeitet wird. Ich schreibe oft einen Code, der beim Schreiben plötzlich für einen anderen Teil des allgemeinen Schemas nützlich erscheint, den ich neben meinem Bildschirm habe (auf Papier in einem für mich nur lesbaren Stil gezeichnet).

  • Mit einem Schema können Sie nicht nur den Code, sondern auch das Schema umgestalten. Manchmal bin ich damit beschäftigt, eine Klasse zu schreiben, die plötzlich auch für einen anderen Teil des Schemas nützlich erscheint. Infolgedessen wird das Schema einfacher, wenn das Projekt ausgeführt wird

  • Jedes Mal, wenn ich dieses Schema aktualisiere, werden auch die erforderlichen Eingaben und Ausgaben von Funktionen / Methoden sowie die verfügbaren Slots in Klassen angegeben. Dies geht schneller für die Wiederverwendung von Bits: Ich muss nicht jedes Mal in den Code eintauchen, um zu überprüfen, was genau rein und raus geht. Auch wenn es in den Kommentaren steht, muss ich mich noch umsehen, um die Kommentare zu lesen

Also verwende ich auch deine Methode. Ich fange einfach an, probiere es aus, überarbeite es, probiere es erneut aus, ändere ein anderes Stückchen und so weiter, aber mein Zyklus beinhaltet auch das Schema. Und wenn das erledigt ist, füge ich die Informationen für die nächste hinzu, die mit diesem Code funktioniert.

Wohlgemerkt, das ist für Projekte, an denen ich alleine arbeite. Wenn Sie mit mehreren Personen am selben Code arbeiten, ist Vorausplanung nicht nur logisch, sondern auch von wesentlicher Bedeutung. Aber das wissen Sie bestimmt schon.

Und wie andere gesagt haben: Das ist meine Art, Ihre Laufleistung kann variieren.

Joris Meys
quelle