it-swarm.com.de

Soll ich vorausplanen oder Programme herausfinden, während ich sie schreibe?

Ich habe heute an Paul Grahams Buch "Hackers and Painters" gedacht. Genauer gesagt diese beiden Absätze :

"Im College wurde mir beigebracht, dass man ein Programm vollständig auf Papier herausfinden sollte, bevor man sich einem Computer nähert. Ich stellte fest, dass ich nicht auf diese Weise programmierte. Ich stellte fest, dass ich gerne vor einem Computer saß, nicht vor einem Schlimmer noch, anstatt geduldig ein komplettes Programm zu schreiben und mir zu versichern, dass es korrekt war, neigte ich dazu, nur Code auszuspucken, der hoffnungslos kaputt war, und ihn allmählich in Form zu bringen. Das Debuggen war eine Art letzter Durchgang, bei dem Sie Tippfehler und Versehen gefangen ... [Es] schien, als bestünde die Programmierung aus Debugging.

... Soweit ich das beurteilen kann, war die Art und Weise, wie sie mir das Programmieren am College beigebracht haben, völlig falsch. Sie sollten Programme herausfinden, während Sie sie schreiben, genau wie Schriftsteller, Maler und Architekten. "

So wird es in meinem College unterrichtet und ich bin mir ziemlich sicher, dass die meisten anderen Colleges es auch sind. Sie finden heraus, was Ihr Programm tun wird, und dann finden Sie heraus, wie es zu tun ist. Anschließend geben Sie ein und debuggen. Manchmal erstellen Sie eine Basisversion und fügen Funktionen hinzu, aber die Idee ist, dass Sie überlegen und dann tippen.

Diese Art erinnert an das Kapitel in Feynmans Buch "Er löst Radios durch Denken!" Dort ging er auf und ab und überlegte, wie das Radio kaputt gehen könnte, und reparierte es dann. Für mich geht es beim Programmieren darum, nachzudenken und dann eine Lösung zu finden.

Ist dies der vorherrschende Ansatz für die Codierung? Wenn ja, warum hacken nicht mehr Leute einfach weg und stellen ein Programm zusammen, ohne eine vorgefasste Vorstellung davon zu haben, wie es aussehen wird?

Was sind die Vor- und Nachteile von Think & Type gegenüber Spew & Beat?

56
BlackJack

Dies ist ein perfektes Beispiel für den ausgeschlossenen mittleren Irrtum. Ja, es ist eine schlechte Idee, das gesamte Programm auf Papier zu schreiben, bevor Sie die eigentliche Tastatur berühren. Aber das macht das Gegenteil nicht extrem - sofort in die Codierung springen und anfangen zu hacken - eine gute Idee. In der Tat ist es noch schlimmer.

Es ist sehr wichtig zu verstehen, was Sie schreiben möchten, bevor Sie mit dem Schreiben beginnen. Wenn ich eine neue Funktion bei der Arbeit implementieren muss, stelle ich sicher, dass ich eine Spezifikation habe, die beschreibt, was getan werden muss, bevor ich anfange. Ich schaue es mir an und wenn es etwas gibt, das keinen Sinn ergibt, spreche ich mit den Leuten, die die Spezifikation geschrieben haben, und arbeite an dem Problem, bis wir uns einig sind. Manchmal hatte ich die Anforderungen nicht verstanden und sie können mich klarstellen; In anderen Fällen haben die Leute von PM] die technischen Details nicht verstanden und am Ende die Spezifikation geändert.

Fast jeder, der dies getan hat, kann Ihnen aus eigener Erfahrung sagen, dass es viel einfacher ist, Probleme in der Spezifikation zu beheben, als ein Problem in Ihrem Code in der Mitte der Implementierung zu finden, alles herauszureißen und durch etwas anderes zu ersetzen . Es ist also sehr, sehr wichtig, einen Plan für das zu haben, was Sie schreiben, bevor Sie mit dem Schreiben des Codes beginnen.

70
Mason Wheeler

Sie denken, Michelangelo ist gerade auf die Sixtinische Kapelle geklettert und hat gerade angefangen zu zeichnen? Testzeichnungen wurden gemacht. Genehmigungen des Papstes waren erforderlich. Es musste ein Gerüst gebaut werden. Vorlagen zur Anleitung der Gruppe anderer Künstler. Die Restaurierung war noch komplexer.

Wenn ich eine Anwendung erstellen möchte und die Designeinstellungen im Kopf eines anderen nicht berücksichtigen muss, kann ich einfach mit dem Codieren beginnen. Wenn Sie den falschen Weg gehen, ändern Sie einfach Ihre Meinung. Ich wollte diese Funktion sowieso nicht.

Lassen Sie den Maler oder Schriftsteller in einem Komitee sitzen. "Oh, mach einfach weiter und mach die Hauptfigur zu einer Frau. Wenn wir es uns später anders überlegen, werden wir es dich wissen lassen. Und WTF, lass es uns 20 'lang statt 30 machen. Kannst du eine spanische Galeone mit 50 hinzufügen? einzigartige Ruderer vor der Enthüllung morgen? "

36
JeffO

Ich denke, es geht nur darum, ein Gleichgewicht herzustellen. Es ist unmöglich, an alles zu denken, bevor Sie alles abtippen, und genau deshalb ist das Wasserfallmodell so kaputt. Wenn Sie zu wenig nachdenken, können Sie gleichzeitig ein großes Durcheinander verursachen, wenn Sie die ersten Iterationen hinter sich lassen. Schließlich können Sie nicht den gesamten Code in Form bringen, und es wäre sehr bedauerlich, wenn Sie eine Grundvoraussetzung frühzeitig übersehen hätten, die ein Umschreiben in der Mitte des Projekts erforderlich machte.

Im Entwicklungsprozess ist eine bestimmte Anzahl von Iterationen erforderlich, die Waterfall übersieht (es wird 1 perfekte Iteration vorausgesetzt). Agile (oder die breite Gruppe von "agilen" Methoden) übersehen manchmal, dass jede Iteration einen bestimmten Overhead hat, und wenn durch jede Iteration nicht viel gewonnen wird, erhöht sich die Anzahl der Gesamtiterationen und dieser Overhead summiert sich zu erheblichen Kosten.

22

Die Prämisse der Analogie ist falsch: Viele Schriftsteller skizzieren oder überlegen zumindest, was sie schreiben werden, bevor sie mit dem Schreiben beginnen, und viele Maler und Architekten werden Dutzende von Studien und Skizzen durchführen, bevor sie mit ihrer eigentlichen "Arbeit" beginnen.

Da die Analogie falsch ist, lautet die Antwort ja - Programmierer sollten wie Schriftsteller, Maler und Architekten arbeiten.

22
Matthew Flynn

Ich hatte einen Mitbewohner im College, der ein Doppelkunstmajor war und Malerei und Webdesign machte. Er und ich haben viele Notizen über unsere Arbeitsabläufe verglichen. Wenn er malt, findet er das Gemälde nicht nur heraus, während er es malt. Es gab mehrere Dinge, die er vorher tun könnte. Für eine Collagenmalerei könnte er eine Skizze zeichnen. Auf einem fotorealistischen Gemälde skizzierte er die Hauptformen mit Bleistift und malte dann die Details ein. Aber wenn er vorher genau wusste, was er wollte, brauchte er diese Hilfsmittel nicht. Er hat gerade gemalt.

Ich bin sicher, Sie sehen die Ähnlichkeiten. Wir verwenden verschiedene Methoden, um eine gute Lösung für ein Problem zu finden. Wenn wir eine Technologie nicht gut kennen, hacken wir ein bisschen, um herauszufinden, wie die endgültige Lösung aussehen wird. Größere Produkte profitieren häufig von einer umfassenden Design-Sitzung, bei der die Details später ausgefüllt werden. Und manchmal wissen wir genau, was erforderlich ist, also codieren wir es einfach. Nicht weil wir faul sind, sondern weil wir durch Erfahrung und Gedanken keine zusätzlichen Werkzeuge benötigen.

Einige Vorteile bei der Gestaltung im Voraus:

  • Sie sehen das ganze große Ganze.
  • Sie können mehrere Designs durchlaufen, ohne sich auf eines festlegen zu müssen. Wenn Sie bereits Code geschrieben haben, können Sie die Richtung nicht in großem Maßstab ändern.

Vorteile beim Einspringen in den Code:

  • Auf Mikroebene haben Sie die Möglichkeit, viele Dinge schnell auszuprobieren, bevor Sie sich für den One True Parser entscheiden
  • Es kann helfen, einen Entwurfsblock zu brechen. Wenn Sie sich beispielsweise nicht für ein bestimmtes Objektmodell entscheiden können, können Sie ein bisschen Code aufbauen und sehen, wie er passt.

Die Antwort auf diese Frage ist wie die Antwort auf viele in der Programmierung: Es kommt darauf an. Es hängt vom Projekt ab - benötigen Sie einen Design-Audit-Trail, hilft Ihnen der Prozess und Ihren Mitentwicklern dabei, die von Ihnen benötigten Entscheidungen vollständig zu verstehen, helfen sie Ihnen aktiv oder halten sie Sie davon ab, Dinge zu erledigen? Ist es wichtig, dass das Projekt absolut korrekt ist, oder können einige Fehler später entdeckt und behoben werden? Wie ist Ihr Zeitrahmen? Welche Erfahrungen können Sie mitbringen? Und schließlich verstehen Sie genau, welches Problem Sie lösen müssen?

Was für mich derzeit funktioniert, ist ein großes Bilddesign auf Papier. Dies beschreibt die Hauptteile der Anwendung und wie sie kommunizieren. Normalerweise zeichne ich ein Objektdiagramm und einige Flussdiagramme/Pseudocode/Realcode für die schwierigeren Abschnitte. Dann springe ich abschnittsweise hinein. Wenn ein Fehler im Modell ein Problem verursacht, kann ich jederzeit zu den Konstruktionsspezifikationen zurückkehren und diese für diesen Bereich überarbeiten. Und ein gutes Design im Voraus zu ändern bedeutet normalerweise nicht, dass sich mehr als ein bisschen ändern muss.

9
Michael K

Mir wurde beigebracht, genauso zu programmieren, wie Sie eine Modelleisenbahn bauen.

Beim Bau einer Modelleisenbahn legen Sie ein Stück Gleis und setzen einen Motor auf das Gleis. Wenn es sich bewegt, legen Sie das nächste Stück Spur und prüfen, ob sich der Motor auf dieser Spur bewegt. Sie fahren fort, bis Sie die Schleife abgeschlossen haben und die Engine die Schleife ebenfalls abgeschlossen hat.

Der Vorteil dieser Methode zum Bau einer Modelleisenbahn besteht darin, dass Sie sich ziemlich sicher sind, welches Gleisstück das Problem ist, wenn der Motor stehen bleibt. Die, die du gerade gelegt hast.

Die Programmierung ist ähnlich. Sie müssen die Analyse und das Design durchführen, aber irgendwann müssen Sie mit dem Verlegen beginnen. Ihre erste Iteration besteht möglicherweise nur aus Dummy-Modulen. Das ist in Ordnung, solange Ihr Projekt ohne Abbruch ausgeführt wird.

Sie fügen (idealerweise) jeweils eine Methode oder die Mindestanzahl von Methoden hinzu, um etwas auszuführen. Jedes Mal sehen Sie, ob sich die Engine bewegt (das Projekt wird ausgeführt, ohne abzubrechen).

Möglicherweise stellen Sie beim Verlegen fest, dass Sie ein zusätzliches Abstellgleis benötigen (einige zusätzliche Methoden). Das ist in Ordnung, solange Sie das Design nicht radikal ändern. Wenn Sie das Design radikal ändern, beenden Sie die Codierung. Denken Sie einige Zeit über das Design nach und nehmen Sie die Designänderungen vor, bevor Sie mit der Codierung fortfahren.

Wenn Sie die letzten Spuren gelegt haben (die letzten Methoden abgeschlossen haben), sollte Ihr Projekt ohne Unterbrechung ausgeführt werden. Weil du die ganze Zeit getestet hast. Genau wie Modelleisenbahnbauer.

8

Das Verhältnis von Denken zu Handeln hängt von einer Reihe von Variablen ab, die von der Komplexität des Problems über die Domäne bis zu den Endzielen reichen. Es gibt keinen einheitlichen Ansatz, um herauszufinden, wie viel Gedanken und Planung Sie im Voraus benötigen, und nicht, wenn Sie ein Programm einfach "weghacken" können.

Wenn Sie ein komplexes Problem haben oder an etwas arbeiten, das lebens- oder geschäftskritisch ist, müssen Sie Zeit damit verbringen, es zu verstehen und im Voraus über Lösungen und Kompromisse nachzudenken. Wenn Sie schnell eine Technologie, eine Bibliothek oder ein Framework erlernen möchten, können Sie am besten sofort einspringen und Ihre Fehler in einer wegwerfbaren Prototypumgebung beheben. Weitere Optionen sind evolutionäres Prototyping - genug Gedanken und Design, um sicherzustellen, dass Sie Ihre Arbeit zu einem fertigen Produkt entwickeln können, aber nicht so sehr, dass Sie auf einem einzigen Weg eingeschränkt werden.

4
Thomas Owens

Wie @Thomas feststellte, gibt es keine einheitliche Lösung. In einer Zeit mit reichlich Rechenleistung und Speicher sind die meisten Probleme, mit denen wir konfrontiert sind, nicht schwierig, so dass fast jeder Ansatz eine korrekte Lösung liefert. Es gibt jedoch immer noch Bereiche, in denen Sie kläglich scheitern können, wenn Sie versuchen, eine Lösung im Handumdrehen zu finden, indem Sie sofort Code schreiben.

Eine App, an der ich gearbeitet habe, war beispielsweise die Analyse von Mobilfunknetzen. Wenn Sie Code schreiben müssen, um ein Netzwerk von ein paar tausend Knoten über ein Dutzend verschiedener Netzwerkschichten zu analysieren, das nicht auf Supercomputern, sondern nur auf Dual-Core-Laptops ausgeführt werden soll, sollten Sie die besten Graph-Algorithmen finden, die der Menschheit zuvor bekannt waren Beginn des Schreibens eines Codes. Die Alternative könnte darin bestehen, nach einem halben Jahr eifriger Entwicklung zu erkennen, dass Ihr Algorithmus, obwohl er korrekte Ergebnisse für Ihr Testnetzwerk mit 10 Knoten liefert, O (n) ist4) endet somit nach zwei Jahren auf dem Laptop des Benutzers, wenn er mit dem realen Netzwerkplan versorgt wird, an dem er gerade arbeitet ...

2
Péter Török

Warum hacken nicht mehr Leute einfach weg und stellen ein Programm zusammen, ohne eine vorgefasste Vorstellung davon zu haben, wie es aussehen wird?

Viele Menschen tun genau das während ihrer gesamten Karriere. Diese Seite ist voll von ihren Fragen. Die anderen Partner-Websites sind voller Fragen von anderen Personen, die versuchen, die von ihnen geschriebene Software zu verwenden.

Die Art von Leuten, die, wie Sie sagen, nur Code ausspucken, sagen oft etwas wie "Code ist seine eigene Dokumentation". Code ist nicht Dokumentation. Code ist keine Demonstration Ihrer Absicht, sondern eine Version dessen, woran Sie sich als Absicht erinnern, sowie eine Reihe von Dingen, die Sie auf Ihrem Weg interessiert haben. Einige davon erwiesen sich als nicht nützlich, aber Sie hatten keine Zeit dafür entfernen. Oh, und diese erstaunliche Idee, die Sie nach zwei Nächten ohne Schlaf, aber viel Koffein hatten und die das gesamte Projekt revolutionieren würde, wissen nur, dass Sie nicht einmal wissen, wie es kompiliert wird, geschweige denn, was es tun sollte - oder genau Welchen Effekt hat es, wenn Sie es entfernen?.

Wie sagen Ihre Mitarbeiter (oder Nachfolger) ohne ein noch so minimales Designdokument, welche Bits erweitert und welche gelöscht werden sollen? Dieses Dokument muss nicht am Anfang geschrieben werden, aber für ein Projekt jeder Größe und jedes Wertes muss es irgendwann passieren.

Spew-and-Refactor arbeitet bis zu einem gewissen Punkt für Soloprojekte (und Leute, die gut beurteilen, wo dieser Punkt ist, sind wissenswert). Es ist weniger praktisch für Teams; Wie arbeiten Menschen effizient parallel ohne einen minimalen Konsens über die Spezifikation? Die agile Methodik ist größtenteils ein Versuch, dieses Problem zu lösen, ohne die native Begeisterung der Menschen für das Codieren zu zerstören.

2
itsbruce

Im Allgemeinen ist Programmieren eine Übung in der Abstraktion. Daher führt jeder Versuch, eine bestimmte Lösung zu stark zu aktualisieren, zweifellos dazu, dass Sie den Umfang Ihrer Bemühungen falsch einschätzen.

Sie sind einfach nicht so gut darin, Komplexität zu beurteilen. Vertrau mir, du bist es einfach nicht.

Der beste Code beginnt mit einem Überblick darüber, was Sie erreichen möchten, und wird iterativ in Blöcken erweitert. Mit dem aufeinanderfolgenden Code, der auf sich selbst aufbaut. In der Planungsphase eines Projekts ist es viel nützlicher, sich hinzusetzen und aufzulisten, was Ihr Programm NICHT tun wird. Auf diese Weise erliegen Sie zumindest nicht dem Versuch, den verdammten Ozean zu kochen.

http://en.wikipedia.org/wiki/On_Exactitude_in_Science

1
splicefracture

Ich denke, der Workflow ist für jeden Programmierer sehr individuell. Verwenden Sie die für Sie am besten geeignete Methode.

Ich persönlich beginne normalerweise mit einem leeren Papier und einem Bleistift (oder einem sehr großen Whiteboard, wenn ich eines habe). Ich zeichne zuerst Klassendiagramme und Beziehungen. Dann verfeinere ich es, bis ich eine Grundstruktur habe. In dieser Phase mache ich auch die Zustandsmaschinen. Zu diesem Zeitpunkt wurde kein Code geschrieben oder gedacht, nur Klassen und Beziehungen.

Dies ist nur eine lose Skizze, und während ich anfange, meine Klassen zu programmieren, werde ich auf weitere Designfragen stoßen. Ich gehe dann zurück zu meinem Whiteboard (oder Papier) und löse die neuen Probleme auf, was manchmal bedeutet, dass ich einen Teil des ursprünglichen Designs zerreiße.

Dies ähnelt auch der Funktionsweise von Agilem Design (Anmerkung [~ # ~] ähnlich [~ # ~] an alle, die sich darüber beschweren werden). Es gibt eine ganze Wissenschaft darüber, wie der Projektfortschritt mit dieser Methode verfolgt werden kann, da sich die Anzahl neuer Aufgaben zu Beginn beschleunigt und bis zum Ende des Projekts verblassen sollte.

Die Idee ist, Code und Design zu iterieren. Wir haben diesen Prozess in meiner früheren Firma (mit 130 Entwicklern) verwendet und er funktioniert hervorragend. Wir haben Doxygen auch verwendet, um Klassen- und Beziehungsdiagramme aus Code zu erstellen. Dies war eine schnelle Möglichkeit, sich einen guten Überblick über das tatsächlich codierte Design zu verschaffen, Fehler und fehlende Beziehungen zu erkennen.

Ob das bei Ihnen funktioniert oder nicht, kann ich nicht sagen. Sie müssen versuchen, herauszufinden, was für Sie am besten funktioniert.

0
Max Kielland

Ich werde mich auch mit meinen zwei Cent einschalten.

Das Schreiben eines vollständigen Programms auf Papier, bevor Sie beginnen, ist eine "CS 101" -Übung, die für Hello World funktioniert. Es ist jedoch auch Zeitverschwendung, Code auszuspucken, ohne sich die Zeit zu nehmen, über das nachzudenken, was Sie erreichen möchten.

Zwischen diesen beiden Extremen haben Sie die gesamte Palette an Softwaremethoden, von hartem Wasserfall (umfangreiche Spezifikationen, so ziemlich eine Ausgabe am Ende) bis hin zu agilen ("leichten" Spezifikationen mit sehr schnellem Turnaround zwischen Releases und ständigem "Kunden" -Dialog ).

In jedem Fall müssen Sie wissen, was Sie erstellen, bevor Sie beginnen können, unabhängig von der Methodik. Dies wird dazu beitragen, die Architektur des Programms zu gestalten. Waterfall legt einen Schwerpunkt darauf, dass das gesamte System vor Beginn der Codierung architektonisch gestaltet wird, damit Sie wissen, was Sie am Ende haben werden. Agile legt einen Schwerpunkt auf "Spezifizieren der Mindestfunktionalität, die für die nächste Iteration erreicht werden soll" und ermahnt Sie, sich auf eine ständige Neuarchitektur vorzubereiten (indem Sie geeignete Testsuiten und dergleichen erstellen, damit Sie solche Arbeiten tatsächlich ausführen können ).

Beachten Sie, dass KEINE Methode Ihnen sagt, dass Sie einfach ohne nachzudenken mit dem Codieren beginnen sollen. In der Tat sollten Sie eine ziemlich gute Vorstellung davon haben, was Sie versuchen (sei es das Ganze mit Waterfall oder ein kleinerer Bereich mit Agile). Sie improvisieren etwas in "WIE" Sie etwas tun, nicht in "WAS", das Sie versuchen zu tun.

Ich kann eine Parallele zu dem ziehen, was Sie im Schauspielunterricht lernen. Ein großer Teil ist "Improvisation". Wenn Sie mit einer Improvisation beginnen, müssen Sie so wenig Stein wie möglich verwenden und bereit sein, Ihre Idee aufzugeben, wenn jemand die Szene in eine andere Richtung nimmt. Sie benötigen hervorragende Hörfähigkeiten und müssen die Vorschläge der anderen akzeptieren. Die Hauptsache ist, mit einer Figur auf die Bühne zu kommen, eine Situation, vielleicht ein Gefühl, das Sie vermitteln möchten, und möglicherweise ein Ende, zu dem Sie die Szene führen möchten. Aber je weiter die Idee in der Szene entfernt ist, desto wahrscheinlicher ist es, dass Sie woanders landen. Am Ende ist es eine sehr "agile" Denkweise, mit der Sie hier möglicherweise zu kämpfen haben.

Wenn Sie auf der Ebene "Schreiben wir Code" sprechen (Spezifikationen, Geschichten oder was auch immer verfügbar ist), liegt es an Ihnen. Einige Leute schreiben Pseudocode, andere schreiben Kommentare vor dem eigentlichen Code (in einer "leeren Form") und andere beginnen mit dem Schreiben von Tests (siehe Test Driven Development). In jedem Fall ist das Ziel, Ihre Idee so zu gestalten, dass Sie Erreichen Sie das, was Sie sich für Ihre spezielle Methode vorgenommen haben. Auf dieser Ebene denken die meisten Menschen nach, bevor sie den eigentlichen Code schreiben. Aber es scheint mir übertrieben, den Code vorher auf Papier aufzuschreiben ...

0
Denis Troller

Ich weiß, dass dies beantwortet wurde, aber ich bin nicht davon überzeugt, dass Graham beabsichtigte, alle Übersichten auf hoher Ebene oder das Design im Vorfeld zu ignorieren. Ich denke vorher über das Problem nach, habe Spezifikationen usw., verstehe aber immer noch vollständig, was er sagt, da ich genauso arbeite.

Für mich kommt das "Weghacken" nicht darin, was Sie tun werden, sondern wie Sie es tun werden. In der Schule wurde mir Pseudocode beigebracht und ich entwarf den eigentlichen Code im Voraus. Für mich ist das albern. Ich werde einen Überblick auf hoher Ebene, einen Kompass und von dort weg hacken. Ich werde nicht versuchen, an den gesamten Code zu denken, weil ich kein Compiler oder Computer bin und die Konsequenzen meines gesamten Code-on-Paper im Vorfeld nicht nachvollziehen kann. Ich werde eine ineffiziente oder kaputte Implementierung der Spezifikationen oder des Designs heraushacken und dann von dort aus "in Form bringen".

0
Bob

Nun, wer bin ich, um zu bestreiten, was pg sagt, aber ... Ich denke, der beste Ansatz variiert wahrscheinlich von Person zu Person, und dass - soweit es bis zu diesem Punkt eine objektive Wahrheit gibt - die Wahrheit wahrscheinlich irgendwo in der Mitte liegt . Zumindest denke ich, dass eine Dichotomie zwischen "überhaupt keine Vorausplanung" und "alles im Voraus herausfinden" eine falsche Dichotomie ist. Nach meiner Erfahrung ist es ein Kontinuum.

Ich persönlich neige eher zum explorativen Programmierstil und zum "Herausfinden, wie ich gehe", aber gleichzeitig sind zwei meiner bevorzugten Programmierwerkzeuge ein Künstler-Skizzenblock und ein Satz Buntstifte. Es gibt definitiv eine Zeit und einen Ort, an dem Sie sich hinsetzen und Beziehungen auf hoher Ebene skizzieren und Dinge visualisieren können, um zu verstehen, wie die Dinge zusammenpassen. Nun, da ist für mich.

Auch hier denke ich, dass dies sehr vom Einzelnen abhängt ... und auch von der Problemdomäne und der inhärenten Komplexität des Programms. Das heißt, ein einfaches Befehlszeilenrechnerprogramm (denken Sie an "Poor Man's BC") würde wahrscheinlich weniger Vorausplanung erfordern als ein ERP System für ein Unternehmen mit 30.000 Mitarbeitern).

0
mindcrime

Obligatorisches Zitat von Hunter S. Thomson aber es funktioniert immer bei mir

Wenn Sie eine klare Vorstellung davon haben, was Sie erreichen möchten, wissen, wie Sie Ihren Code strukturieren und ein guter Codierer sind, ist es oft schneller, nur den Code zu schreiben.

0
James Anderson