Top-Down oder Bottom-Up beim Programmieren?
-
Umfrage: Nach welchem Ansatz geht Ihr beim Programmieren vor?
Auswahl Stimmen Prozent Top-Down Ansatz 7 13.5% Bottom-Up Ansatz 12 23.1% Situationsabhängiger Ansatz. Mal so, mal so (mit System). 26 50.0% Ohne System mal so, mal so. 5 9.6% Ich will/kann das nicht beantworten. 2 3.8% Hallo.
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?
Mir ist in letzter Zeit nämlich aufgefallen, dass meine Programmierweise recht unsystematisch ist und ich frage mich, ob es Sinn macht, das etwas zu systematisieren.
Was spricht für Top-Down, was für Bottom-Up? Was spricht dafür, eine sehr systematische Programmierweise zu haben und was spricht dafür, sich da mehr Freiheiten zu lassen? Habt Ihr eine systematische Herangehensweise ans Programmieren? Wenn ja: Erklärt Euer System bitte etwas.
-
Also bei mir ist es oft so, dass ich, wenn ich etwas mache es meist etwas experimentelles drin hat, wo ich noch nicht genau weiss, wie das später dann wirklich mit anderen Modulen zusammenarbeiten soll. Da schaue ich mir dann zuerst mal an, wie ich das genau machen will und überlege mir dann, wenn ich weiss, wie etwas funktioniert ich es dann am gescheitesten für eine abstraktere Stufe anbieten soll.
Einfaches Beispiel: Als ich mit Eiffel ein Spielchen machen wollte kannte ich die Arbeitsweise der Bibliotheken noch nicht und daher habe ich einfach mal bei kleinen Bildchen angefangen. Dann wusste ich auch, wie ich das benutzen kann und es abstrahiert.Wenn ich allerdings etwas mache, wovon ich die Feinheiten bereits so in etwa weiss, wie es geht, dann fange ich oftmals zuerst mit abstrakteren Modellen an.
Um das Beispiel zu vervollständigen: Wenn ich jetzt nochmal was mit Eiffel und der Bibliothek machen würde, würde ich von Anfang an die abstrakte Basis legen und dann die Details implementieren, weil ich jetzt weiss, worauf es ankommt.
-
Bei Algorithmen überlege ich mir zunächst den Pseudocode und implementiere dann die kleinen Einheiten zuerst, also Bottom Up.
Beim OOP Design einer Anwendung überlege ich mir zunächst die grundlegende Architektur (Schichten, MVC usw.) und implmementiere dann Top Down, um möglichst schnell den ersten lauffähigen Prototypen zu haben.
Beispiel: Ich möchte eine Service-Schicht implementieren, die Daten aus einer DB holt, aufbereitet und zurückliefert. Ich definiere dann erstmal das Interface des Service und implementiere dann einen Dummy-Service, der erstmal ohne DB irgendwas zurückliefert. Dann kann man die Daten z.B. erstmal auf der Oberfläche darstellen, ohne sich vorher im Datenbank Design und der Implementierung der DAOs zu verlieren.
-
Bei mir bewegt sich eigentlich beides aufeinander zu (Top-Down und Bottom-Up), d.h. ich versuche schon erst mal viel auf abstraktem Level zu machen, aber erledige gleichzeitig auch schon viele konkrete detaillierte Dinge. So merke ich z.B. relativ schnell wenn was am Design nicht so ganz stimmt.
-
nep schrieb:
Bei mir bewegt sich eigentlich beides aufeinander zu (Top-Down und Bottom-Up),
Vor ein paar Jahren las ich ein Buch über Kognitionspsychologie, in dem stand, daß alle Menschen, die es in ihrem Gebiet zur Meisterschaft bringen, Top-Down und Bottom-Up mischen.
-
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)?
Ich plane "Top down" aber kodiere "Bottom up"
-
Da ich fast ausschließlich Sondersteuerungen programmiere und die auf Basis verschränkter Automaten, steht die Grobstruktur meist schon mit der Aufgabenstellung.
Die kniffeligen Sachen sind dann seltener wirklich neue Module, sondern Hardwareports, wenn ich auf andere Controller portiere oder neue Hardware integrieren muß. Sinnvollerweise fange ich dann meistens "unten" an, um schnell testbare Funktionen zusammenzukriegen. Da sieht man, ob und wie z.B. ein neuer Baustein in das DMAC- Konzept des Controllers (und damit auch zu meinen bestehenden Libs) paßt oder ob ich in der Ebene drüber was Neues brauche.
Also ich schmier' mir schon vorher auf, wie's aussehen soll, aber das coden fange ich eher bei den Details an, die klärungsbedürftig sein könnten.
-
ich plane grob Top-Down ("wo will ich hin? Was brauche ich? Was sind die Abhängigkeiten?") und programmiere dann Bottom-Up.
Genauer: Nach der groben Planung suche ich mir irgendein Blatt meines Programmbaumes, also eine Klasse die alleine existieren kann, programmiere die und schreibe dann direkt Unit Tests zu. Der Vorteil für mich ist, dass ich sagen kann: der Codeteil ist fertig, getstet und funktioniert. Der andere Vorteil ist: die unittests geben direkt Aufschluss darüber, ob das Interface okay ist. Naja, und dann wandere ich immer weiter den Baum nach oben immer wissend, dass ich nur auf dem aufbauen muss, was bereits fertig ist. Sehr motivierend meiner Meinung nach. Zumal man nur sehr wenig temporären Code produziert den man nur dafür braucht, dass das wenige was man hat zusammenhält...
Es führt zwar dazu, dass man eher mit unwichtigem beginnt: "Ich schreib zuerst nen Parser fürs verwendete Datenformat", aber da das eh irgendwann gemacht werden muss, bin ich damit ganz zufrieden - ich darf mich nur nicht in den Details verrennen.
-
Ich fange immer Top-Down an und baue die benötigten Komponenten dann Bottom-Up auf. Aber es ist eigentlich immer das, was mir je nach Anwendung intuitiv am sinnigsten erscheint dominant. Ich kann otze da nur zustimmen. Genau so mache ich es meist auch. Besonders der Teil mit "ich darf mich nicht in Details verrennen" hat mich zum schmunzeln gebracht
.
-
Gregor schrieb:
Hallo.
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?
Mir ist in letzter Zeit nämlich aufgefallen, dass meine Programmierweise recht unsystematisch ist und ich frage mich, ob es Sinn macht, das etwas zu systematisieren.
Was spricht für Top-Down, was für Bottom-Up? Was spricht dafür, eine sehr systematische Programmierweise zu haben und was spricht dafür, sich da mehr Freiheiten zu lassen? Habt Ihr eine systematische Herangehensweise ans Programmieren? Wenn ja: Erklärt Euer System bitte etwas.
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?! 
Und wie sogar selbst volkard endlich realisiert hat, ist das nicht nur ein Problem der SW Entwicklung, sondern ein grundsätzliches Problem der Menschen und hauptverantwortlich für die größten Probleme unserer Zeit. Ob globale Erwärmung oder Finanzkrise, ob Entscheidungsträger, Experten oder gewöhnliche Menschen:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch, quick-and-dirty, heuristisch, konservativ, formalistisch, den Status Quo erhaltend, schnell und mit wenig Aufwand im lokalen Maximum nachsteuernd, so dass wir eine 'Einweg'-Entwicklung haben.
Oder arbeiten wir Top-Down - visionär, strategisch, abstakt, langsam Resultate produzierend, bloatig, mit hohen Konfigurationsaufwand, progressiv, viele Veränderungen in Kauf nehmend, auf der Suche nach einem Maximum mit besonders hohen Fitnesswerten, so dass wir deren Bauelemente (Muster, Methoden, Prozesse, Systeme, Konzepte etc.) möglichst oft wiederverwenden können.
Und die Skalierung hängt natürlich von den Persönlichkeitstypen des Menschen und den entsprechen Umständen ab.
Alaaf!
-
Prof84 schrieb:
Und wie sogar selbst volkard endlich realisiert hat, ist das nicht nur ein Problem der SW Entwicklung, sondern ein grundsätzliches Problem der Menschen und hauptverantwortlich für die größten Probleme unserer Zeit.
Nein, davon nehme ich doch Abstand.
Es ist unter Umständen denkbar, daß es vielleicht möglicherweise ein Problem derer ist, die sich mangels Inhalten an leeren Strukturen festhalten wollen.Prof84 schrieb:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch, quick-and-dirty, konservativ, formalistisch, den Status Quo erhaltend, schnell und mit wenig Aufwand im lokalen Maximum nachsteuernd, so dass wir eine 'Einweg'-Entwicklung haben.
Bodenständig in der Softwareentwicklung ist aber TD. Konservativ ist auch TD. formalistisch ist auch TD. Lokale maxima suchend ist auch TD. Du solltest wissen, daß TD eine der Forderungen der Dokmatisten der Strukturierten Programmierung ist.
Prof84 schrieb:
Oder arbeiten wir Top-Down - visionär, startegisch, abstakt, lansam Resultate produzierend, bloatig, mit hohen Konfigurationsaufwand, progressiv, viele Veränderungen in Kauf nehmend, auf der Suche nach einem Maximum mit besonders hohen Fitnesswerten, so dass wir deren Bauelemente (Muster, Methoden, Prozesse, Systeme, Konzepte etc.) möglichst oft wiederverwenden können.
Startegisch kann beides sein. Abstakt zwar auch, aber TD tendiert gerne zu Angstlayern und damit mehr Abstaktion, oder? Langsamheit würde ich mit TD gar nicht in Verbindung bringen. Was war nochmal Rapid Prototyping? Progressiv? Ah, du meinst progressiv langsam.
-
Ich mache immer das zuerst das, was gerade ansteht, wobei fast immer die Lauffähigkeit des Programms erhalten bleibt.
Gibt es mehrere anstehende Sachen zur Auswahl, heißt es zu wählen, zum Beispiel
- Projektkritische Sachen werden vorgeholt. Kann man zeitnah 100MB strukturierte Daten ins RAM hauen? Reicht die Bandbreite des Netzes? Reicht ein Server aus? Kann man das überhaupt automatisieren? Halt so Sachen, die am Ende dafür sorgen können, daß man statt des 31.08.03 erst am 01.01.06 abgeben kann, hihi.
- Einfache Sachen werden vorgeholt, denn die kann man im ersten Anlauf hinkriegen. Und man lernt dazu, sodaß die vormals schwierigen Sachen dann auf einmal einfach sind und auch auf Anhieb funzen.
- Unabhängige Sachen, die völlig unkritisch sind, werden nach hinten geschubst. Wer braucht schon Einstellungsdialoge oder Druckfunktionalität (überhaupt eine grafische Oberfläche)?
Aber das sind nur Beispiele. Jede Aufgabe ist anders. Normalerweise (edit: Nee, idealerweise) sind Oberfläche und Programmlogik einigermaßen getrennt, in verschiedenen Verzeichnissen, in verschiedenen Projekten(im Sinne der IDE). Da wächst dann die Logik BU und die Oberfläche TD.
-
Prof84 schrieb:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch[...]
Oder arbeiten wir Top-Down - visionär, strategischAm Anfang war Bottom-Up und Top-Down noch anders (richtig) rum. Vielleicht ist es nach weiteren 6 Edits wieder richtig
-
volkard schrieb:
Ich mache immer das zuerst das, was gerade ansteht, wobei fast immer die Lauffähigkeit des Programms erhalten bleibt.
Also eher die unstrukturierte, intuitive Vorgehensweise. Warum auch nicht? Jeder wie er am besten kann.
-
volkard schrieb:
Prof84 schrieb:
Und wie sogar selbst volkard endlich realisiert hat, ist das nicht nur ein Problem der SW Entwicklung, sondern ein grundsätzliches Problem der Menschen und hauptverantwortlich für die größten Probleme unserer Zeit.
Nein, davon nehme ich doch Abstand.
Es ist unter Umständen denkbar, daß es vielleicht möglicherweise ein Problem derer ist, die sich mangels Inhalten an leeren Strukturen festhalten wollen.Liebe Leser! Hiermit dementiere ich ganz offizell mein Statement zu volkards Sichtweise, denn wie zu ersehen habe ich Ihn ganz klar überschätzt!
volkard schrieb:
Bodenständig in der Softwareentwicklung ist aber TD. Konservativ ist auch TD. formalistisch ist auch TD. Lokale maxima suchend ist auch TD. Du solltest wissen, daß TD eine der Forderungen der Dokmatisten der Strukturierten Programmierung ist.
Prof84 schrieb:
Oder arbeiten wir Top-Down - visionär, startegisch, abstakt, lansam Resultate produzierend, bloatig, mit hohen Konfigurationsaufwand, progressiv, viele Veränderungen in Kauf nehmend, auf der Suche nach einem Maximum mit besonders hohen Fitnesswerten, so dass wir deren Bauelemente (Muster, Methoden, Prozesse, Systeme, Konzepte etc.) möglichst oft wiederverwenden können.
Startegisch kann beides sein. Abstakt zwar auch, aber TD tendiert gerne zu Angstlayern und damit mehr Abstaktion, oder? Langsamheit würde ich mit TD gar nicht in Verbindung bringen. Was war nochmal Rapid Prototyping? Progressiv? Ah, du meinst progressiv langsam.
Das ist doch nur noch gequirlte Kacke. - Kein Kommentar.
Bashar schrieb:
Prof84 schrieb:
Immer steht man vor der Entscheidung ob man Buttom-Up arbeitet - bodenständig, taktisch[...]
Oder arbeiten wir Top-Down - visionär, strategischAm Anfang war Bottom-Up und Top-Down noch anders (richtig) rum. Vielleicht ist es nach weiteren 6 Edits wieder richtig
Ja, das ist doch ein schönes Beispiel: Ich überlege mir abstrakt (TD), was ich scheiben will. Erstelle den Rohentwurf. Dann drücke ich den Absenden Button, weil ich noch anderes zu tunen habe und meine Existenzberechtigung nicht dadurch fröhne, die Versionenstände von Posts anderer Mitglieder zu kontrollieren und dann editiere ich meine Posts (BU), um formal mehr der Rechtschreibung zu genügen indem ich Fehler heraushole, kleine Zusätze einzufügen oder Sachen neu zu formulieren, um meinen Konzept mehr Reife und Fähigkeiten zu geben.
Insbesondere wenn man einen Kater hat und das erst die Runde 1 ist ...
-
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!