Top-Down oder Bottom-Up beim Programmieren?
-
Prof84 schrieb:
Gratuliere zum Aufstieg! - "Zweifel ist das Vorzimmer zur Erkenntnis." (indisches Sprichwort) - 
- Ich habe gerade in den letzten Jahren Tonnen von Folien erstellt, die sich genau mit diesen Thema beschäftigen. Mal abgesehen von den 15 Jahren Erfahrung als Consultant, Manager und System- und Prozessingieur :). Nur wenn Du Jahre deines Lebens "geopfert" hättest, um solche im doppelten Sinne 'globalen' System zu entwickeln und ca. 3.000 € Tagessatz dafür kassierst, würdest Du den Leuten das noch für Lau im Internet stecken?! 
Ja, tu's doch mal, so ein "Testpackage". Gibt's sogar kostenlos von L. Ron Hubbage/Scientology.
Ich vermute eher, daß Hausmeister- Prof Nullpeilung hoch Laberbacke gar keine Ahnung vom Programmieren hat - in welcher Sprache auch immer. Prozessingenieur" - ich lach' mich tot
Was suchst Du hier überhaupt - hast Du je irgendwem geholfen? Oder immer nur Hilfe gesucht? Oder immer nur das Quatschforum bedient
Du bist nichts, kannst nichts und bist den Beweis immer schuldig geblieben, daß es anders ist. :p
-
Prof84 schrieb:
Gratuliere zum Aufstieg! - "Zweifel ist das Vorzimmer zur Erkenntnis." (indisches Sprichwort) - -Meinst Du, die Fähigkeit oder Neigung zur Selbstreflektion ist sooo außergewöhnlich?
Prof84 schrieb:
Ich habe gerade in den letzten Jahren Tonnen von Folien erstellt, die sich genau mit diesen Thema beschäftigen. Mal abgesehen von den 15 Jahren Erfahrung als Consultant, Manager und System- und Prozessingieur :). Nur wenn Du Jahre deines Lebens "geopfert" hättest, um solche im doppelten Sinne 'globalen' System zu entwickeln und ca. 3.000 € Tagessatz dafür kassierst, würdest Du den Leuten das noch für Lau im Internet stecken?!
Ich weiß nicht. Meinst Du, das würde Deinen Wert für Unternehmen schmälern? Ich meine, hier sind ja nicht unbedingt viele Leute, die direkte Konkurrenten für Dich sind. Und ich denke auch nicht, dass ein Unternehmen auf Deine Dienste verzichtet, weil Leute hier etwas über diese Thematik lesen. Insofern würde es wohl eher darauf hinauslaufen, dass Du etwas verwertest, das bei Dir eh da ist, ohne dass dies negative Auswirkungen hat. Ist das nicht eh das, was die Leute in den ganzen Fachforen hier machen? Anderen einen Einblick in ihr Fachwissen zu ermöglichen?
EDIT: Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
-
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so?
Im Vordergrund stehen vorallem Rückkopplung zum Design/Konzept und relative schnelle Prototyp.
-
Gregor schrieb:
Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
Bist Du nur Labertasche oder programmierst Du selber?
Topdown Ansatz ist OK, Bottom Up realisieren Praxis. TopDown realisieren heißt Dummies zu produzieren, die so tun, als ob sie so tum würden, wie Du denkst.
Tun die "echten" Funktionalitäten oft nicht, dabnei hast Du so einen wunderbaren Dummy gebastelt. Tut leid, aber bitte nochmal.
Als naturfaules Stück fang' ich wirklich bei den kritischen Sachen an und schau' zu, sie in mein Schmierfetzen- Konzept zu integrieren.
-
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein.
Ich finde es nicht ungewöhnlich. Zuerst hat man noch ein grobes Bild vor Augen. Das wird dann während der Planungsphase immer klarer, verdichtet sich, Teilprobleme kristallisieren sich heraus, man fängt an das System in kleinere Einheiten zu zerlegen usw. Wenn dann der Punkt gekommen ist, es in Code zu giessen, beginnen wir sinnvollerweise bei den atomaren Bestandteilen. Woher bekomme ich sie? Muss ich sie selbst entwickeln? Wir können diese separat testen und bauen schliesslich unser Gesamtsystem daraus zusammen. Ich denke, nicht wenige arbeiten so oder so ähnlich.
An die anderen: Streitet euch doch nicht so. Das ist ja furchtbar!
-
Baba Yaga schrieb:
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein.
Ich finde es nicht ungewöhnlich. Zuerst hat man noch ein grobes Bild vor Augen. Das wird dann während der Planungsphase immer klarer, verdichtet sich, Teilprobleme kristallisieren sich heraus, man fängt an das System in kleinere Einheiten zu zerlegen usw. Wenn dann der Punkt gekommen ist, es in Code zu giessen, beginnen wir sinnvollerweise bei den atomaren Bestandteilen.
Das dachte ich heute mittag auch irgendwann. Aber ich bin mir da niht mehr so sicher. Ja, zuerst hat man ein grobes Bild vor Augen, Top-Down. Und dann plant man rum. Aber beim rumplanen schweife ich auch schnell ab in die Bestandteile und überlege rum, wie die in groben Zügen gehen, ob sie gehen, welche Ausweikungen sie haben, und fummle sie wieder in den Hauptplan ein. Ich schätze, Planen ist nur das grobe Vorwegnehmen des Ausprogrammierens und geschieht nicht notwendigerweise in einer anderen Reihenfolge.
Gregor kann programmieren. Das merkt man gleich, wenn man sich mal mit ihm zankt. Er kann viele treffsichere Argumente aufstellen und einen damit bombardieren.
-
volkard schrieb:
Das dachte ich heute mittag auch irgendwann. Aber ich bin mir da niht mehr so sicher. Ja, zuerst hat man ein grobes Bild vor Augen, Top-Down. Und dann plant man rum. Aber beim rumplanen schweife ich auch schnell ab in die Bestandteile und überlege rum, wie die in groben Zügen gehen, ob sie gehen, welche Ausweikungen sie haben, und fummle sie wieder in den Hauptplan ein. Ich schätze, Planen ist nur das grobe Vorwegnehmen des Ausprogrammierens und geschieht nicht notwendigerweise in einer anderen Reihenfolge.
Ja das stimmt. Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden. Ideal wärs, wenn man sie ausschliessen kann. Leider gelingt das nicht immer. Ein guter Programmierer sollte wenn möglich, wenn er an einen Modul arbeitet, auch das Gesamtkonzept oder einen grossen Teil davon im Kopf haben. Divide et impera ist theoretisch ein guter Ansatz, aber verliert viel von seiner Wirksamkeit, wenn man den Überblick verloren hat.
-
Baba Yaga schrieb:
Ja das stimmt. Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden. Ideal wärs, wenn man sie ausschliessen kann. Leider gelingt das nicht immer.
Hmm.
Baba Yaga schrieb:
Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden.
Sind es nicht die g.W.u.S, die das Planen erst ausmacht?
Ich meine, zum bloßen Runterplanen (rein-planlos nur mit Top-Down) kann ich auch einen Prof nehmen, der nie selber programmiert hat, nur wird das nix.
Was das Planen ausmacht, ist vielleicht, daß man am ersten Tag aus den unzähligen Planungsmöglichkeiten bereits welche ausschließen kann, die einem ein drei Monaten erst das Knie brechen, weil Modul X und Modul Y nicht harmonieren. Oder noch besser von den noch guten Möglichkeiten sieht man eine, daß nach sechs Monaten abkacken wird, weil die Engine es einfach nicht hergeben wird, daß man zufriedenstellend foo und bar machen kann.Was waren denn meine weitsichtigtsen Entscheidungen? Mhhm. Eigentlich immer welche, wo ich das Modul schon recht detailgenau durchüberlegt habe und es paßte einfach nicht zum ganzen Rest. Da geht fühlt man sich dann ganz schlecht. Und bald geht die Warnlampe an und dann hat man auch schnell den technischen Nachweis, daß da dir Kacke am dampfen ist (wobei der Nachweis auch falsch sein kann, weil man ein supi dupi passendes Entwurfsmuster einfach nicht kennt).
-
pointercrash() schrieb:
Gregor schrieb:
Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
Bist Du nur Labertasche oder programmierst Du selber?
volkard schrieb:
Gregor kann programmieren. Das merkt man gleich, wenn man sich mal mit ihm zankt. Er kann viele treffsichere Argumente aufstellen und einen damit bombardieren.
@volkard: Danke!
...aber eigentlich programmiere ich recht wenig. Ich habe in letzter Zeit zwar ein paar tausend Zeilen Code in den Rechner gehackt, aber offensichtlich habe ich immer noch keine wirkliche Systematik beim Programmieren entwickelt. Sonst würde ich solche Fragen, wie ich sie hier stelle, nicht stellen. Außerdem habe ich in letzter Zeit gemerkt, dass mir das Programmieren bei etwas komplizierteren Dingen doch recht schwer fällt und, dass ich viele Fehler mache. Ich habe letztens zum Beispiel den Ball Pivoting Algorithmus zur Oberflächenrekonstruktion zu implementieren. Es hat glaube ich gut 10 Tage gedauert, bis ich den halbwegs fehlerfrei hingekriegt hatte. Deshalb überlege ich, was ich beim Programmieren wohl falsch mache und wie ich gezielter an die Sache herangehen kann. So, dass schnell guter Code herauskommt und ich komplizierte Codeteile bei der Programmierung besser beherrschen kann.
@pointercrash(): Wie gesagt: Ich habe diesen Thread eröffnet, weil ich da bei mir ein vermutlich suboptimales Vorgehen bei der Programmierung festgestellt habe. Ich habe mir auch noch keine wirklich tiefgehenden Gedanken bezüglich des Themas dieses Threads gemacht. Die Antworten, die es in diesem Thread gab, waren für mich aber sehr interessant und ich finde, als Threadersteller muss man so etwas auch irgendwo zum Ausdruck bringen. Und wenn mehrfach ein bestimmter Ansatz genannt wird, der mich etwas überrascht, dann sag ich auch, was mich bezüglich dieses Ansatzes wundert. In dem Zusammenhang verstehe ich zumindest nicht, was das mit "labern" zu tun hat.
Naja, ich hoffe, es kommen noch viele weitere interessante Beiträge zum Thema dieses Threads. Gibt es diesbezüglich eigentlich hilfreiche Literatur?
-
Gregor schrieb:
Ich habe letztens zum Beispiel den Ball Pivoting Algorithmus zur Oberflächenrekonstruktion zu implementieren. Es hat glaube ich gut 10 Tage gedauert, bis ich den halbwegs fehlerfrei hingekriegt hatte. Deshalb überlege ich, was ich beim Programmieren wohl falsch mache und wie ich gezielter an die Sache herangehen kann. So, dass schnell guter Code herauskommt und ich komplizierte Codeteile bei der Programmierung besser beherrschen kann.
Ich habe jetzt nicht so den Eindruck, daß 10 Tage dafür grottenlangsam wären. Mein erster Baum hat viel länger gedauert, aber gut, da war ich kackboon. Meine erste Welt mit dynamischem LOD hat so lange gedauert, das sage ich mal besser nicht, diese verkackte Bäume wiedermal haben sich dauernd so dumm zusammengefaltet, daß Lücken sichtbar waren. Es könnte sein, daß ich allein zum Rollen des Raumschiffs länger gebraucht habe, als 10 Tage.
Vielleicht solltest Du mehr Gamecoders-Foren lesen. Das gibt immer wieder Auftrieb. In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst. Aber bohr weiter, so tief du kommst, und berichte!
-
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?
-
Gregor schrieb:
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?
a) Nette Bücher lesen. Hast Du schon ein nettes über Xtreme Pr0gramming gelesen? (edit: Nicht den Wikipedia-Artikel lesen! Davon wird man blind. Er pervertiert die Sache, dann lieber sich von Prof84 erklären lassen, wie man Kühe melkt.)
b) Drogen essen. Ähnlich gut kann sein, Die Quelle in der S-Bahn, die Du nur zu diesem Zweck benutz, zu lesen, sich zum Lesen zu zwingen, und nicht nur halbherzig, obwohl junge Arbeitslose mit Kampfhunden, die es nicht mehr gibt, neben einem stehen.
c) C++ natürlich und Struppis Literaturhinweise, die OO-lastige SOftwareentwicklung zeigen und nicht gerade in Richtung Shlaer-Mellor!
Nee, dazu kenne ich Dich dann doch zu wenig. Alles nur Spekulation. Ich denke, a) fehlt Dir tatsächlich. Aber sonst? Wie kriege ich mein Kind dazu, nicht an Gott zu glauben? Das kann ich nicht. Wie kriege ich Dich dazu, nicht an Formalismen zu glauben? Das kann ich auch nicht.
-
volkard schrieb:
Gregor schrieb:
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?
a) Nette Bücher lesen. Hast Du schon ein nettes über Xtreme Pr0gramming gelesen?
b) Drogen essen. Ähnlich gut kann sein, Die Quelle in der S-Bahn, die Du nur zu diesem Zweck benutz, zu lesen, sich zum Lesen zu zwingen, und nicht nur halbherzig, obwohl junge Arbeitslose mit Kampfhunden, die es nicht mehr gibt, neben einem stehen.
c) C++ natürlich und Struppis Literaturhinweise, die OO zeigen und nicht gerade in Richtung Shlaer-Mellor.
Nee, dazu kenne ich Dich dann doch zu wenig. Alles nur Spekulation. Ich denke, a) fehlt Dir tatsächlich. Aber sonst? Wie kriege ich mein Kind dazu, nicht an Gott zu glauben? Das kann ich nicht. Wie kriege ich Dich dazu, nicht an Formalismen zu glauben? Das kann ich auch nicht.Keine Angst, ich folge Formalismen nicht blind. ...zumindest nicht dauerhaft, höchstens als Zwischenstufe.
zu a) XP ist natürlich ein Ansatz. Ich habe vor langer Zeit mal etwas in ein entsprechendes Buch hineingeguckt und habe auch ein Praktikum in der Uni mitgemacht, in dem nach XP vorgegangen wurde. Ich setze es allerdings nicht ein. Habe das irgendwie aus den Augen verloren. Vielleicht wäre es aber ganz gut, einige der dortigen Techniken in meine Codeentwicklung einfließen zu lassen. Vielleicht sollte ich mir auch mal einige andere Bücher zu Softwareentwicklungsmethodiken ansehen. Vielleicht habe ich das Thema bis jetzt nicht ernst genug genommen. Ich sollte mal gucken, ob XP auch Aussagen zu genau dem Thema dieses Threads macht.
zu b) Das Lesen der speziellen Literatur interpretiere ich mal als "Bring Dich in eine Position, in der Du Deiner Aufgabe fachlich überlegen bist!". Das ist sicherlich ein Punkt, der mich etwas aufgehalten hat. Gerade, wenn man mathematisch der Sache bei solchen Algorithmen nicht komplett überlegen ist, braucht man doch recht lange, um die entsprechenden Codeteile zu implementieren. Das hat mich auch etwas aufgehalten und hat die Reihenfolge der Codeentwicklung beeinflusst. Ich habe die entsprechenden Codeteile, wenn ich sie auf den ersten Blick nicht überblickt habe, erst am Schluss implementiert. Naja, der Hauptgrund, warum das 10 Tage gedauert hat, war aber, dass das Debugging wirklich lange gedauert hat. Sicherlich die Hälfte der Zeit. Und das waren eigentlich keine mathematischen Fehler, sondern Fehler im Programmfluss. "Nicht bedachte Fälle", "etwas falsche if-Bedingungen" und so weiter. Ich vermute, solche Fehler im Programmfluss sind mindestens teilweise eine Folge einer schlechten Programmierweise.
zu c)
-
Standardanwendungen kriegst Du mit Standardvorgehen gut hin.
-
Gregor schrieb:
Keine Angst, ich folge Formalismen nicht blind. ...zumindest nicht dauerhaft, höchstens als Zwischenstufe.
zu a) XP ist natürlich ein Ansatz...Ich sollte mal gucken, ob XP auch Aussagen zu genau dem Thema dieses Threads macht.
Das meinte ich nicht so. Es scheint, Du würdest Du in Erwägung ziehen, Dir aus einigen XP-Tricks ein Kochrezept zusammenzubauen. Die Tricks sind Anti-Tricks, nur viel besser verpackt.
Gregor schrieb:
zu b) Das Lesen der speziellen Literatur interpretiere ich mal als "Bring Dich in eine Position, in der Du Deiner Aufgabe fachlich überlegen bist!". ..."etwas falsche if-Bedingungen" und so weiter. Ich vermute, solche Fehler im Programmfluss sind mindestens teilweise eine Folge einer schlechten Programmierweise.
Das meinte ich nicht so. Es gibt gewisse Geisteszustände, die jenseits des rein Rationalen sind. Wer kennt das nicht, daß man beim Duschen oder beim Kacken auf die grandiosesten Programmierideen kommt?
Gregor schrieb:
zu c)
Das meinte ich nicht so. Sein "C++ Die Programmiersprache" behandelt ein wenig mehr als nur C++ und die Literaturhinweise beim DingenserstellenUndPlanen sind gut, finde ich. Wenn ich mich recht erinnere, zeigt er da auf nicht ein C++-lastiges Buch.
-
Gregor schrieb:
Nach welchem Ansatz geht Ihr beim Programmieren vor? Programmiert Ihr erst auf einem relativ abstrakten Level, um dann später in die Details zu gehen (Top-Down)? Oder programmiert Ihr erst die Details und fügt sie nachher zu einem Ganzen zusammen (Bottom-Up)? Oder macht Ihr es mal so und mal so?
Beides und weder noch. Beim Programmieren (Coden) würde ich sagen ist es uninteressant. Beim Planen dessen was man Programmieren will könnte man zwischen Bottom-Up und Top-Down unterscheiden, aber auch nicht so wirklich. Es gibt wohl keinen der bei ner Schleife anfäng und daraus ein Programm macht, ohne zu wissen, was er eigentlich für ein Programm will. Und da sieht man auch schon was man plant. Das, was man nicht weiß. Will man nen Tetris-Klon programmieren, muss man nicht mehr planen, was Tetris machen soll, weil man das Spielprinzip kennt. Willst du ein Content-Business-Controlling-Management-System(TM) programmieren, musst du erst mal wissen und planen was das Ding machen soll, aber das unten ne Datenbank hin kommt und wie die funktioniert, ist schon klar.
Willst du irgend ein bestehendes System erweitern, musst du das bestehende System kennen(lernen) und planst dann irgendwo mittendrin. Am Schluss validierst du nochmal Bottom-Up und Top-Down und baust es ein. Bei der Umsetzung von nem (Ball Pivoting) Algorithmus würde ich nicht sagen, dass es um Bottom-Up oder Top-Down geht, sondern darum zu verstehen, wie der Algo im Detail funktioniert und beim Programmieren merkt man dann, dass man manche Details nicht verstanden hat. Allgemein hilft die simple Erkenntnis, dass man Dinge verstehen sollte, bevor man sie zusammen baut, ungemein, um schneller zum Zeil zu kommen, egal ob Oben, Unten oder in der Mitte. Man kommt auch zum Zeil, wenn man nicht alles verstanden hat, aber meistens braucht man länger und es wird nicht so gut. Bis man aber so weit ist, dass man alles versteht, braucht man nocht viel länger. Alles klar?
-
Bei der Implementation eiens Algorithmus gehe ich auch völlig anders vor. Meiner Meinung nach kann man einen komplexen Algorithmus nicht implementieren, wenn man ihn nicht vollständig verstanden hat. An dem Punkt gehts auch nicht mehr um Top-Down oder Bottom-Up weil man nichts mehr planen muss. der Algorithmus selbst ist bereits das Resultat einer Planung, die Aufgabe des Progrmamierers ist jetzt nur noch, diesen Plan zu verstehen. Bei Algorithmen gehe ich demnach so vor:
1. Algorithmus verstehen
1.a. versuchen den Algorithmus jemandem zu erklären um sich selbst zu beweisen, dass man ihn verstanden hat
1.b. Code einer Implementierung an Land ziehen und versuchen, DIE zu verstehen.
2. zu verwendende Datenstrukten bestimmen
3. Datenstrukturen implementieren, wenn nicht vorhanden
4. Algorithmus runterprogrammieren.
-
Was versteht Ihr eigentlich unter Planung?
Ich meine, ich mache das eigentlich gar nicht. Zumindest betreibe ich keine explizite Planung. Bei mir sieht Planung so aus:
1. Ich lese etwas über den Algorithmus oder definiere mir anderweitig mein Programmierziel.
2. Ich schlafe.
3. Die grobe Klassen- und Algorithmenstruktur hat sich von selbst in meinem Kopf gebildet. Ich setze jeweils das um, bei dem mir auch die Details sofort klar sind. Nur bei sehr komplizierten Dingen mache ich mir nochmal explizite Gedanken. Stift und Papier benötige ich eigentlich nur, wenn irgendwo ne Menge Mathematik drinsteckt, die ich nicht einfach so aus dem Ärmel schütteln kann.Mit anderen Worten, eine explizite Planung gibt es bei mir eigentlich nicht. Damit kriege ich durchaus relativ komplizierte Dinge hin, aber ich merke so langsam, dass ich damit an meine Grenzen komme. Deshalb suche ich momentan nach etwas Systematik beim Programmieren.
@volkard: Ok, Formalismen sind kein Allheilmittel, aber ich verstehe sie als Werkzeuge. Werkzeuge, um Komplexität zu beherrschen. Ich denke, es gibt Situationen, in denen es gut ist, ein Konzept zu haben, nach dem man vorgeht. Ein Konzept, auf das man sich im Zweifelsfall zurückziehen kann. Dieses Werkzeug fehlt mir bei der Programmiermethodik momentan.
-
Macht eine strikte Trennung überhaupt Sinn? Ich gehe eigentlich so vor, dass ich mir vorher grob überlege, welche Teile es gibt, was man braucht und wie das alles zusammen hängt (Top-Down). Aber beim programmieren fange ich dann in der Regel "unten" an (Bottom-Up). Gerade wenn man sich in einem Gebiet nicht gut auskennt, übersieht man beim planen oft Details. Außerdem habe ich gerne etwas, was man schon benutzen/testen kann. Natürlich erfordert dieses Vorgehen auch regelmäßig Refactoring.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.