Programmplanung Design Auwand vs. Extremeprogramming

Planner schrieb:

Bin ein kleiner Perfektionist.. wo andere aufhöhren uns ein schluss strich ziehen und sagen "so die anforderungen sind erfüllt, erweiterbarkeit reicht aus fertig" hör ich nicht auf^^ Ich Programmier oft zu optimiert... zu kryptisch.. leider deswegen zuwenig dokumentiert;)

Hört sich mehr nach Anfänger als Perfektionist an. Optimier, wenn es zu langsam ist, nicht schon vorher, wenn du noch garnicht weißt ob das was du da gerade "optimierst" jemals viel Zeit braucht.

loks schrieb:

Wenn Du nicht wenigstens vier Fachbücher pro Jahr liest machst Du etwas falsch. Wer sein Wissen nur aus (zumeist veralteten) Tutorials und try'n'error bezieht darf sich nicht wundern wenn das irgendwann zu Problemen führt

Außer man ist so gut wie ich, aber das ist fast keiner.

Das ist BorisDieKlinge;)

Wer?

going down? schrieb:

Wer?

Ersteller

BorisDieKlinge???

naja das ist das problem, es geht um Prozessplanung... quaise die Planung von verschieden Prozessen entlang der zeit welche sich gegenseitig beinflussen. Die Planung muss sehr schnell gehen und dynamisch von statten gehen. Das Problem ist genau das, das die Anforderungen nicht komplett gegeben sind.. Es soll so Umgesetzt werden, das alles Möglichkeiten von Ablaufprozessen ineinander verplant werden können.. naja schwer zu erklären..

thordk

hab die erfahrung gemacht, dass man sich sehr schnell festfährt, wenn man zu lange plant. es passiert nich bloss, dass man während der planung einige fälle vergisst, sondern in der praxis viel häufiger, dass die anforderungen einer ständigen entwicklung unterliegen. schon morgen könnte irgendein kunde einen wunsch äussern, der in das bestehende system integriert werden muss. deshalb halte ich es für sinnvoll, wenn man den entwicklungsprozess von vornherein darauf auslegt, dynamisch zu sein.

schnelle prototypen, reviews und brutales refactoring, sobald die ersten unstimmigkeiten auftreten.

ich entwickel software schon recht lange auf diese art und hab immer wieder die erfahrung gemacht, dass solche systeme in frühen phasen durchaus instabil sind und an einigen ecken unnötig komplex werden. aber solange man mit den reviews und dem refactoring nicht aufhört, entwickelt sich das system in erstaunlich schneller zeit zu einem stabilen stück software, das völlig problemlos allen anforderungen gewachsen ist.

Jester

Ich habe mit XP auch gute Erfahrungen gemacht. Allerdings sollte man ein bißchen aufpassen. Man kann nicht einfach sagen, wir lassen jetzt die Planung weg und machen XP. XP ersetzt den Planungsteil größtenteils durch andere Methoden, die müssen dann aber auch umgesetzt werden!

Grundvoraussetzung um XP anwenden zu können ist die Möglichkeit Refactoring zu betreiben, da man sonst in frühen Fehlentscheidungen festhängt. Um aber sinnvoll umfangreichere Refactorings durchführen zu können sind umfangreiche Unit-Tests nötig, weil man sonst viel zu leicht was zerschießt. Und um sicherzustellen, dass die Unit-Tests auch eine ausreichend große Abdeckung haben, schreibt XP Test-First-Programmierung vor: Es wird kein Stück Code geschrieben, das nicht zuvor durch einen Testfall nötig geworden ist.

Verzichtet man auf Planung und setzt die XP-Schritte nicht um, dann wird das ganze nicht zu XP sondern zu einem Stochern im Nebel.

Ja, leider kombinieren "Entwickler" gerne das Beste aus beiden Welten: Sie sparen sich die Planung _und_ die Unit-Tests....

Mußte mir letztens noch von einem unserer Entwickler anhören: Lass uns doch erst unsere Software fertig machen, danach kannst Du mit deinem Test-Unsinn anfangen.

Ich teste nie und plane nie, denn meine Software hat keine Bugs

Ewig langes planen ist doch Käse, genau das was du beschreibst sollte man nicht machen. Ein Programm sollte die gestellten Anforderungen erfüllen und nicht so flexibel sein, dass du am Ende Java und die JVM neu erfindest.
Wenn sich was größeres ändert muss sowieso ein Programmierer sich hinsetzen und das anpassen, egal ob du dir deine eigene Skriptsprache für die Business-Logik geschrieben hast, oder es in der eigentlichen Programmiersprache verfasst hast.
Ein Anwender wird das nie hinbekommen.

Und die Software muss auch nicht flexibler sein wie vom Anwender gefordert, wenn das erweitern später länger dauert, dann ist das nicht deine Schuld, sondern seine (diese Aussage bitte nicht kommentieren - ihr interpretiert das jetzt eh schwarz-weiß nur um rumtrollen zu können).

thordk

loks schrieb:

Mußte mir letztens noch von einem unserer Entwickler anhören: Lass uns doch erst unsere Software fertig machen, danach kannst Du mit deinem Test-Unsinn anfangen.

gibt leider immer noch viel zuviele entwickler, die einfach "blind" drauf loscoden und sich im nachhinein dann wundern, warum das testcenter von so komisch abstrusem verhalten berichtet. und selbst wenn tests geschrieben werden, müssen die meisten davon als ausgeschmücktes "it compiles" ausgelegt werden.

wäre schön, wenn es in mehr kopfen ankömmen würde, dass man tests nicht schreibt, weil das irgendwer einfordert, sondern das tests integraler bestandteil der planung sind, die schnittstellen festlegen und nicht zuletzt dem entwickler ungeheuer dabei helfen zu verstehen, was sein stück code da eigentlich grad machen soll.

glaub aus dem journeyman buch stammt das sinngemäße zitat "tests sind anwender". und automatisierte anwendertests sind das beste, was einem passieren kann.