Ich weiss auch nicht wie genau xp definiert ist und was für paradigmen es hat. Und ich bezweifle auch, dass ich alle paradigmen ( mensch ist das ein tolles wort) von xp Anwende.
Aber ich lese bei gelegenheit mol den Artikel den ich kürzlich irgendwo gefunden habe, falls ich den wiederfinde. Sonst hilft mir google gerne weiter auch wenn der immer noch nicht weiss weshalb metti das mail verschikt hat (metti weiss worums geht)
ok, Zusammenfassung von dem was ich weiss (nicht ganz alles, ich fass mich _sehr_ kurz):
-Pair Programming - zwei Leute, ein Computer
-Tests - für _jeden_ Teil einer Software wird _zuerst_ ein Test geschrieben
Die Tests kann man dann alle nach einer Änderung an der Software durchlaufen lassen, und sieht sofort, wenn man was geschlissen hat
-rewrites - wenn man was nicht mehr versteht, wird es neu geschrieben
-Kundenwünsche werden seperat "geschichtenmässig" formuliert, auf kleine (A6-A5) Karten geschrieben. Beispiel: "Herr xyz von der Abteilung abc will immer am Montag auf den Knopf 123 drücken und dann den Umsatz der letzten Woche sehen"
Eigentlich ists noch mehr, fällt mir auf die schnelle nicht mehr alles ein (hab einen ca. 2h Vortrag gesehen und 2 oder 3 Artikel gelesen)
Cool ist, dass man damit nur ca. einen drittel langsamer entwickelt, dafür mit einem Zehntel der Fehler. Das dürfte sich in vielen Fällen lohnen.
tönt doch gar nicht so schlecht. da hab ich gar nicht so viel dagegen. das meiste finde ich gut. tests mache ich auch immer. allerdings schreibe ich die im nachhinen. (wenn die funktion steht, nicht wenn die ganze software steht)
nur das pair programming finde ich einen elend verfluchten huren bockmist!!! das müssten dann schon zwei personen sein, die haargenau den selben coding-stil haben. nur so als beispiel, zwischen tschuder und mir würde das NIE funktionieren und man würde mindestens 100x so lang brauchen, bis man was hat.
muss imfall nicht sein, dass es an zweien liegt... habe auch schonmal versucht, mit jemandem zu programmieren, der war in der beziehung echt ätzend. er hatte immer irgendwelche bescheuerten ideen, die ganz sicher nicht funzen würden, und teilte mir die immer genau dann mit, wenn ich gerade meine idee (von der ich ihn gerade in mühseliger arbeit überzeugt hatte) umsetzen wollte.
meiner meinung nach kann pair programming nur funktionieren, wenn derjenige, der zuschaut nur syntax korrigiert. also das, was nachher sowieso der compiler noch machen würde. da brauchts den 2. gar nicht.
Ne nicht unbedingt, ich würde es jetzt so machen, der, der daneben sitzt, braucht von der Sprache eigentlich nicht unbedingt einen blassen zu haben. Er muss nur das System schnallen und was der ablauf so seien sollte. dann kann er dem der an der Maschine Sitzt sagen, was für funktionen er progen soll.
z.B. jetzt einen DB-Request, der diese und diese sortierten Daten in ein ListenObjekt wirft, oder so. Und nun soll die Liste sortiert werden, je nach heufigkeit des wortes in einer Zeile. Und... Und....
Und der, der progt, sollte die Sprache etwas gut beherrschen und fungiert dann wie ein Überstzer, er progt dies was du Ihm sagst.
Fehler werden dadurch sicherlich vermieden, da einer den Ablauf mecht und der ander progt und ihn so gut möglich korriegiert.
Ich hab das Pair Programming mol mit dem milamber ausprobiert und das hat super geklappt. Obwohl ich zugeben muss, dass er mehrheitlich Programmiert hat und ich mir dabei überlegt hab, was er er macht, weshalb er das macht, wie man das noch machen könnte und das nachher noch alles kommt.
Meiner Meinung nach ist das ne sehr gute Idee.
@biko. ich glaub nicht, dass wir beide zusammen so viel länger hätten. Weil man beim Coden gleich ausprobieren kann und/oder aufschreiben kann was korrekt wäre. Sonst haben wir doch immer das Problem, dass wir entweder das selbe meinen und es Unterschiedlich beschreiben, oder wir das ganze so beschreiben, dass es der andere nicht versteht..
Bei Programmen wo Reliability höchstes Gebot ist lohnt es sich auf jeden Fall.
Pair-Programming ist Sinnvoll bei Programmier-Rookies. Erfahrene Programmierer machen weniger Fehler und kosten mehr.
