Stückchenprogrammierer vs. Ganzdurchdenker
-
Was ist besser alles ganz zu planen und zu machen oder immer nur ein kleinen Teil und dann wieder nen Teil und am Schluss gibt es das ganze? was ist der einfachere Weg, oder geht einer garnicht?
-
Aender das Topic bitte mal in "Bottum-up vs. top-down".
-
metromatro schrieb:
Was ist besser alles ganz zu planen und zu machen oder immer nur ein kleinen Teil und dann wieder nen Teil und am Schluss gibt es das ganze? was ist der einfachere Weg, oder geht einer garnicht?
allein sind stückchen optimal, denn an den ersten einfachsten stückchen lernt man für die schwierigeren und an denen für die noch schwierigeren und so.
im großen team hingegen muß einer zuvor alles ganz durchdenken und die aufträge verteilen, sonst gibts nur chaos und man bringt mit 1000 programmieren nicht wesentlich mehr zustande als allein. außer natürlich man hätte 1000 programmierer mit uberskills, besonders in zusammenarbeit und übersicht-haben. aber das ist ganz ganz unrealistisch.
-
Doktor Prokt schrieb:
Aender das Topic bitte mal in "Bottum-up vs. top-down".
Weil Unregistrierte das so gut können ...
Ansonsten: Ich plane das Grundkonzept, die Detailsachen schreib ich dann aber relativ frei.
-
also die stückchenprogrammierer sind oft gute 'teamplayer', weil die ihre 'stückchen' gut pflegen. die, die das gesamtsystem betrachten, sind nicht so gut im stückchencoden, aber auch wichtig....
-
Also mir gehts so, dass ich nicht genügend Geduld habe, alles zu Planen, deshalb gehöre ich wohl auch zu den "Strückchenprogrammieren"
Aber es passiert dann ja mal öffters, dass ich alles nochmal umkrempeln muss
-
interessanter wäre imho die frage: ab welcher systemgrösse verliert ihr den überblick und werdet zum 'stückchenprogrammierer' ?
-
IMHO macht es keinen Sinn, egal bei welcher Größe oder ob alleine oder im Team, bottom-up zu programmieren. Selbst bei kleinen Projekten mache ich erst einen Plan von den einzelnen Modulen und deren Schnittstellen. Bei kleinen Projekten im Kopf, bei größeren in UML.
Man braucht doch eigentlich immer min. 3 Module: Input, Berechnung, Output. Da macht es schon Sinn die Schnitstelle des Inputs auf die der Berechnung zu optimieren.
-
vista schrieb:
also die stückchenprogrammierer sind oft gute 'teamplayer', weil die ihre 'stückchen' gut pflegen.
Kann ich nicht bestätigen. Ich kenn ein paar die meinen immer, dass der Fehler nicht in ihrem Stückchen liegt, sondern, dass erst mal der andere suchen soll, bis man dann merkt, dass er doch bei denen liegt.
-
ich hab mal bei einem projekt mitgemacht, bei dem eig nur stückchenprogger waren. Leider auch der, der sich für den chefe hielt...das ende kann man sich denken
.
Ich progger aber alleine auch immer drauf los bei kleineren sachen, aber wenn es dann womöglich auch noch ein projekt mit mehreren kommunizierenden proggys is, wird mir das zu unübersichlich. Dann überleg ich mir eig was und progge parallel zur abwechslung die sachen, die schon feststehen
-
Wenn man nicht wenigstens ein grobes Gesamtbild im Kopf hat wird jedes mittlere oder größere Projekt daran scheitern oder ein vielfaches der Zeit kosten die eigendlich notwendig wäre, abhängig davon ob man entweder den Überblick ganz verliert oder aber permanent bereits fertig Teile umschreiben muß weil das nächste "Stückchen" mal wieder bis dahin nicht berücksichtige Anforderungen erzeugt die eine Anpassung der vorhandenen Software kosten...
Sicher, der Sinn von Modulen ist es ja gerade autarke Elemente zu bauen die nur über Schnittstellen mtieinander kommunizieren. Das funnktioniert aber nur, wenn diese Schnittstellen von Anfang an 100%tig sauber definiert sind (naja, oder wenigstens 90%tig).
Jedes Umschreiben einer Schnittstelle bedeutet bereits vorhandenen Code anfassen zu müssen, also Mehraufwand für das Gesanmtprojekt. Und hier gilt auch noch, daß der Mehraufwand immer größer wird, je weiter man bereits ist... Will sagen, eine Änderung der Schnittstelle am ersten Tag ist wahrscheinlich kostenlos im Bezug auf Mehraufwand. Die gleiche Änderung sechs Monate später kann aber mehrere Tage bis Wochen Arbeit nach sich ziehen...