Planen vs. Drauflosprogrammieren
-
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...
-
Jester schrieb:
Hast Du schonmal ein Projekt mit XP durchgeführt?
Ja, ein ganz kleines im Rahmen eines Praktikums im Informatik-Grundstudium. Dort wurde, wenn ich mich richtig erinnere am Anfang ein kleines Klassendiagramm erstellt, in dem die Grundstruktur des Programms zu erkennen war. Dieses Klassendiagramm wurde dann später erweitert verfeinert und verändert.
-
Nein.
Kann es sein, daß Du Dich nicht mit XP beschäftigt hast? Ist wirklich nicht bös gemeint.
Du hast nur die Funktionalität, die Du erfüllen mußt. Damit setzt Du Dich an den Rechner. Den Plan, wie Du das jetzt implementierst machst Du vielleicht im Kopf, aber Du schreibst nichts auf, Du diskutierst nicht lange in einer Gruppe darüber, sondern Du überlegst Dir (ganz kurz aus dem Bauch raus), welche Dienste muß meine Komponente anbieten um das zu leisten was sie soll. Dann suchst Du Dir einen davon raus und schreibst nen Test dafür. Und dann weiter wie oben. Das ganz immer wieder, bis Du fertig bist.
-
Ok. Wie stellst du dir das vor? Du willst ein Projekt mit XP realisieren und hast 10 Leute im Team. Wie fängst du an? Mit einem "Dann fangt mal an zu programmieren!"?
-
Gregor schrieb:
Ok. Wie stellst du dir das vor? Du willst ein Projekt mit XP realisieren und hast 10 Leute im Team. Wie fängst du an? Mit einem "Dann fangt mal an zu programmieren!"?
Tatsächlich habe ich nur 6 Leute im Team. Dafür mache ich das auch wirklich. :p
Natürlich sagt man nicht: "Fang mal an zu programmieren".
Es wird vielleicht überlegt welche Komponenten für den Anfang wohl benötigt werden. Wenn Du natürlich das herausfinden, daß wir eine Fensterklasse brauchen, damit wir die Ergebnisse unserer Anwendung visualisieren können und wir brauchen eine Schnittstelle für den Datenbankzugriff als Planung ansiehst, dann muß ich Dir recht geben.
Die Interfaces der Komponenten werden dann zwischen den Teams, die sie implementieren bzw. Nutzen einfach ausgemacht. Ist ja auch alles kein Problem, man kann's ja anchher schwups wieder ändern.Es stimmt, daß der Planungsanteil solange noch garnichts da ist höher ist, sobald aber mal irgendwas steht (zum Beispiel zweite Iteration), also schon eine gewisse Codebasis da ist, läuft alles wie oben beschrieben.
MfG Jester
-
Jester schrieb:
Natürlich sagt man nicht: "Fang mal an zu programmieren".
Es wird vielleicht überlegt welche Komponenten für den Anfang wohl benötigt werden. Wenn Du natürlich das herausfinden, daß wir eine Fensterklasse brauchen, damit wir die Ergebnisse unserer Anwendung visualisieren können und wir brauchen eine Schnittstelle für den Datenbankzugriff als Planung ansiehst, dann muß ich Dir recht geben.
Die Interfaces der Komponenten werden dann zwischen den Teams, die sie implementieren bzw. Nutzen einfach ausgemacht. Ist ja auch alles kein Problem, man kann's ja anchher schwups wieder ändern.Ja, das sehe ich als Planung an.
Du hast nur die Funktionalität, die Du erfüllen mußt. Damit setzt Du Dich an den Rechner. Den Plan, wie Du das jetzt implementierst machst Du vielleicht im Kopf, aber Du schreibst nichts auf,
Und was siehst du als Planung an? Nach dieser Äußerung von dir hört sich das ja fast so an, als ob die "Wahl des Algorithmus", "Benennung der Variablen" usw. in den Plan gehören sollte.
Aus meiner Sicht gehört gerade die Spezifizierung der Schnittstellen und die damit einhergehende Grundstruktur des Projekts in die Planung.
-
Eine Planung beinhaltet meist mehr als das was nötig ist um die aktuelle Aufgabe zu erledigen. Es werden Design-Patterns aufgefahren und Assoziationen zwischen Klassen definiert. etc.
Wer wohl was alles kennen müßte, wie man das Feature, was später vielleicht mal reinmüßte schonmal vorsehen kann und so weiter. Wenn ich ein Bankkonto implementieren will und ich weiß, es wird später mal Juniorkonten geben, dann sehe ich das in meinem Plan vor. In XP nicht, wenn es nicht die aktuelle Aufgabe ist Juniorkonten zu bauen. Dann implementiere ich, als gäbe es die garnicht und füge sie erst später hinzu, indem ich die eine Klasse zur Basis mache und zwei neue erstelle die davon erben.
Hier wird einfach das getan, was nötig ist und sonst nichts. Wird mehr nötig, so ist man nicht traurig, weil's nicht im Plan stand, sondern ändert das einfach. Da es keine Planungsdokumente gibt können sie auch nicht veralten, so einfach ist das.Die Spezifizierung der Schnittstellen wird nur so weit nötig gemacht. Nicht weiter. Da man zumeist eh weit genug unten im System anfängt können auch leicht mehrere Sachen unabhängig voneinander entwickelt werden, sodaß keinerlei Schnittstellenspezifikation nötig ist.
MfG Jester
-
habt ihr vielleicht ein paar Links oder Buchtips zu XP?
würde mich nämlich auch interessieren