Planen vs. Drauflosprogrammieren
-
Hi alle zusammen ...
Also ich kann den Leuten da nur zustimmen ..... sobald das Projekt größer
würd als ein Taschnrenrechner z.b, ist planung sehr wichtig. Ohne planung kommt man nicht weit. irgendwann gelangt der Programmierer an einen Punkt an seinem Projekt, wo er merkt das da was nicht stimmen kann und dann ist die Motivation nicht mehr so groß
Also ich sach immer, wenn das Projekt für einem zu unüberschaubar wird, sollte man für sich einen Plan erstellen. egal wie der ausschaut .... ob UML Diagramme oder sonst was.cu
-
Also ich habe mal ab und zu vor den Anfaengen von Projekten versucht, den Verlauf, oder das Projekt irgendwie zu planen.. Also habe mir Skizzen gemacht, mir irgendwas aufgeschrieben, aber die Zettel sind ganz schnell in den Muell geflogen, weil ich sowieso nicht draufgeschaut habe.. Also war es dann doch wieder ein spontanes Drauflosprogrammieren..
Das einzige, was man bei mir immer Planung oder was weiss ich was nennen kann sind die Vorstellungen von dem Projekt in meinem Kopf... Der Rest ergibt sich einfach so... Aber meine Projekte sind auch nicht alle so gross.... Naja wer weiss..
MfG Aoeke
-
Optimizer schrieb:
Ich habe es schon oft genug bereut, nicht richtig geplant zu haben.
Ja, ich gehöre auch zu den anonymen Nicht-planern... *bereu*
Ich bin schuldig! :p
-
Bei kleinere Sachen finde ich, geht es sogar noch ohne Kommentare im Quelltext (ja, schlagt mich dafür). Aber ich will mir angewöhnen, dass endlich vernünftig zu machen.
-
Kann mir mal jemand einen Plan von einem Projekt zeigen. Vielleicht ein paar der Skizzen einscannen oder so?
-
man kann doch z.B. die entitäten nicht einfach spontan benennen. da kommt doch nur muell bei raus. class design muss sinnvoll sein. patterns, factories, interfaces, ... alles sehr wichtig.
-
Griffin schrieb:
Bei kleinere Sachen finde ich, geht es sogar noch ohne Kommentare im Quelltext (ja, schlagt mich dafür). Aber ich will mir angewöhnen, dass endlich vernünftig zu machen.
Sogar bei groesseren lasse ich die ( immer noch ) weg... :rolleyes .. Ich hatte mir mal angewoehnt, welche zu schreiben, aber irgendwann hatte ich keine Lust mehr dazu...
Vor allem kann ich meine Gedankenzuege oftmals gar nicht erklaeren... Sachen gibts.... 
MfG Aoeke
-
eXtreme Programming basiert genau darauf einfach direkt drauflos zu programmieren, ohne einen genauen Plan zu machen. Insofern scheint es schon ein Stück weit zu funktionieren. Ich persönlich mache zwar auch lieber einen Grobentwurf und lege dann los, aber es geht auch ohne. Allerdings nutzt XP einige Techniken um das überhaupt zu ermöglichen. Refactoring hat Shade ja schon genannt, Voraussetzung dafür ist allerdings das konsequente schreiben von unit-tests... und alle Programmierer lieben Tests!
-
extrem programming wird doch auch geplant oder nicht?
zumindest meine ich es so gelesen zu haben.
-
Jester schrieb:
eXtreme Programming basiert genau darauf einfach direkt drauflos zu programmieren, ohne einen genauen Plan zu machen.
Das ist IMHO nicht so ganz richtig bzw. erweckt einen falschen Eindruck von XP. Auch bei XP sind "Planungsspiele" vorgesehen. Diese legen zwar keinen "genauen Plan" fest, legen aber sehr wohl fest, was in die nächste Version der Software kommen muss, welche Termine eingehalten werden müssen, welcher technische Weg generell gegangen wird usw.! Es ist also auch hier kein "direkt drauflos programmieren" angedacht.
-
hat jemand dazu vielleichtg ein paar links, die gut und am besten noch in deutsch sind?
-
Im Planungsspiel wird hauptsächlich ermittelt was in das nächste Release bzw. in die nächste Iteration rein soll. Die Ziele werden in Tasks aufgeteilt und an einen Verantwortlichen gegeben. Eine wirkliche Planung im Sinne der Softwarearchitektur findet höchstens im Rahmen eines stand-up-meetings für die Dauer einer halben Stunde statt oder so. Mehr wird für gewöhnlich nicht geplant. Dafür muß man sich aber an einen Haufen anderer Dinge halten, weil sonst das Refactoring nicht funktioniert.
MfG Jester
-
Jester schrieb:
eXtreme Programming basiert genau darauf einfach direkt drauflos zu programmieren, ohne einen genauen Plan zu machen.
Nein. Du planst nur so wenig wie möglich.
In XP legst du dir keinen großen Plan an, sondern machst nur immer kurze Planungen - um flexibel zu bleiben.Drauflosprogrammieren widerspricht dem XP Prinzip "Tue das was nötig ist jetzt, aber nicht mehr. Tue alles andere später.". Wie willst du soetwas ohne Planung schaffen?
-
Shade Of Mine schrieb:
Jester schrieb:
eXtreme Programming basiert genau darauf einfach direkt drauflos zu programmieren, ohne einen genauen Plan zu machen.
Nein.
Nein?
Wieso nein? Man macht keinen genauen Plan. Genau das hab ich geschrieben und Du sagst nein, man macht halt nur keinen genauen Plan.
Man plant die Flexibilität bei XP nicht, sondern vertraut darauf, daß sie sich dadurch ergibt, daß jederzeit Änderungen möglich sind (Refactoring unterstützt durch unit-tests). Dadurch entsteht die Flexibilität an den Stellen, wo sie gebraucht wird und nicht überall. Eben nur dort, wo sie nötig ist.
MfG Jester
-
Jester schrieb:
Nein?
Wieso nein? Man macht keinen genauen Plan. Genau das hab ich geschrieben und Du sagst nein, man macht halt nur keinen genauen Plan.
Es wird hier vor allem der erste Teil deiner Aussage "man programmiert direkt drauflos" kritisiert. Die ist nicht richtig. Der zweite Teil mit dem genauen Plan ist Definitionssache und kann durchaus so gesehen werden.
-
Dann erklät mal, was man Deiner Meinung nach tut. Abgesehen davon geht es hier, wie der Titel sagt um Planen vs. drauflos programmieren. Und XP ist ganz eindeutig bei letzterem einzuordnen. Ich habe das Beispiel auch mehr aus dem Grund gebracht, weil es hier so aussah, als wäre es ohne eine ausführliche Planungsphase garnichts produzieren.
Hast Du schonmal ein Projekt mit XP durchgeführt?
-
Shade Of Mine schrieb:
Drauflosprogrammieren widerspricht dem XP Prinzip "Tue das was nötig ist jetzt, aber nicht mehr. Tue alles andere später.". Wie willst du soetwas ohne Planung schaffen?
Vor allem würde mich interessieren, wie man "Write tests first" ohne Plan realisiert.
-
Das ist ganz einfach. Du überlegst Dir: okay, was muß meine Komponente können, wie soll sie auf was reagieren. Dann schreibst Du dafür einen Test. Anschließend schreibst Du genau ausreichend viel Code, daß sich der Test übersetzen läßt. Dann stellst Du sicher, daß er auch schiefgeht (sonst haste den Test vielleicht vergessen in die Suite reinzuhängen), anschließend arbeitest implementierst Du das ganze so, daß es funktioniert. Dann machste ein Refactoring, weil der Code so unschön geworden ist. Anschließend den nächsten Test etc.
Sollte sich mal etwas nicht gescheit implementieren lassen und ein anderes Design wäre besser gewesen, dann änderst Du das Design einfach (Unit-Tests sei dank einfach möglich) und baust das Feature dann ein. So sieht typische XP-Arbeit aus.Achja, was Deine Komponente letztlich können muß weißt Du meist aus einer Story die Dir der Kunde geschrieben hat.
MfG Jester
-
Jester schrieb:
Das ist ganz einfach. Du überlegst Dir: okay, was muß meine Komponente können, wie soll sie auf was reagieren.
Mit anderen Worten: Du machst dir einen kleinen Plan. Bevor du anfängst zu programmieren, ist die Struktur des Codes klar.
-
Jester schrieb:
Dann erklät mal, was man Deiner Meinung nach tut.
wie würdest du unit tests machen, ohne planung?
abgesehen davon: wenn ein Projekt ein XP Projekt werden soll - ist das bereits eine Planung der vorgehensweise...