Programmplanung Design Auwand vs. Extremeprogramming

Hey ihr checker,

ich hab schon einige Projekte gemacht, und bin nicht der Typ der gleich los programmiert, sondern Plane sorgfältig den Aufbau....

Nun der Teufel steckt im Detail... wenn man sich das Design und Use -Cases einer Anwendung überlegt, kommt man oft an Punkte, wo man die Planung umschmeisen muss , weil ein Use-Case nicht rein passt. Man versucht alles so Abstrakt zu halten um möglichst alles Use- Cases und evtl. noch kommen Use Cases unterzubringen...

Oft Verzerifelt man, und denkt drüber nach wie man noch gehen soll... Noch keine Zeile geschrieben .. und immer tiefer ins detail planen..

Dann ist es soweit man ist sich rel. sicher jetzt stimmt alles.. man hat sich Aufau, Algorithmen und Vorgänge überlegt. Klassendiagramme, UML, etc.

Und schon nach 1 Stunde Programmieren, paar klassen gemacht, fällt einem erst auf das dies so und so nicht gehen kann...

Nun stellt sich die Frage wie weit man Plannen sollte, oft fällt einem erst während der Programmierung ein was man verbesser eleganter lösen könnte..

Man tendiert dann dennoch richtugn Extremprogramming und hat die Planung nur noch Groß im konzept..

wie ist es bei euch? mach ich was falsch, oder ist es bei euch auch so -> egal wie tief detailiert man plan, erst beim umsetzen erkennt man das es nicht nach Plan geht...

3:2 Deutschand- Portugal ^^ :schland:

Planner schrieb:

Hey ihr checker,

Hey du unego. Warum sprichst Du eigendlich von dir selber immer nur in der Dritten Person (man)? Bischen mehr Selbstvertrauen... Akzeptanz ist der erste Schritt... Nicht "man" hat diese Problem, "Du" hast sie

Planner schrieb:

ich hab schon einige Projekte gemacht, und bin nicht der Typ der gleich los programmiert, sondern Plane sorgfältig den Aufbau....

Das ist im XP Programming im Prinzip nicht anders. Nur das dort die Planung flexibler ist und den Kunden mit einbezieht.

Planner schrieb:

Und schon nach 1 Stunde Programmieren, paar klassen gemacht, fällt einem erst auf das dies so und so nicht gehen kann...

Dafür gibt es ein Fachwort: Mangelnde(s) Erfahrung/Wissen. Mit genug Hintergrundwissen (z.B. Design Patterns) sollte einem sowas nicht allzu oft passieren.

Planner schrieb:

Nun stellt sich die Frage wie weit man Plannen sollte, oft fällt einem erst während der Programmierung ein was man verbesser eleganter lösen könnte..

Verfahrensfehler. Es geht nicht darum gleich beim ersten Durchlauf die eleganteste, beste Lösung zu bauen, sondern _eine_ funktionierende Lösung. Wenn Du dann später feststellst das die gewählte Lösung den Anforderungen nicht genügt (z.B. nicht schnell genug) dann gezielt Refaktoren/Optimieren. Hier gilt: Das Bessere ist der Feind des Guten. (okok, 90% verstehen den Spruch nicht...)

Planner schrieb:

Man tendiert dann dennoch richtugn Extremprogramming und hat die Planung nur noch Groß im konzept..

Jein. Auch im XP wird viel geplant, nur anders. Dabei dürfte der entscheidende Vorteil noch immer darin liegen, daß der eigendliche Kunde (spätere User) von Anfang an in den Entwicklungsprozess einbezogen wird und man so viel früher merkt wenn das Produkt sich anders verhält als der User es erwartet... Ansonsten halte ich XP auch für eines dieser Buzzwords... Jeder kennt es, aber keiern macht es wirklich.

Planner schrieb:

wie ist es bei euch? mach ich was falsch, oder ist es bei euch auch so -> egal wie tief detailiert man plan, erst beim umsetzen erkennt man das es nicht nach Plan geht...

Es gibt da ein einfaches Gesetz: Planung ersetzt den Zufall durch Irrtum

ANsonsten, Wissen ist das mächtigste Werkzeug das Dir zur Verfügung steht. Es gibt einige Bücher die sollte man einfach gelesen haben und darüber hinaus gilt: 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

Hallo loks,

es ist ja nicht so, das die umsetzung total von der Planung abweicht. Aber wie ich schon sagt der Teufel liegt im Detail. Zudem kommt es drauf an wie komplex die anwendung ist bzw. wird. Bei einfachen tools wo die detail tiefe nicht so extrem ist.. liegt meine planung schon bei 90%

Ich wollte damit nich sagen das jedes Programm das ich schreibe komplett anders aussieht wie ich es geplant habe;)

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;)

Ich bin an einem Projekt dran, von dem ich anfang an alle sorgfälltig plane.. aber es ist halt nich "immer" gesagt das die optimale lösung gefunden wurde... alle paar tage wochen kommt mir ein neue gedankengang, vision.. wie ich etwas noch perfekter optimaler machen können.. und dann fang ich von vorne an...

Welche Fachbücher schlägst du denn vor (C++ und anhängsel)

byto

Ich denke es kommt sehr aufs Projekt an:
Kennt man wirklich schon alle Anforderungen im Vorhinein, dann ist eine ausgedehnte Designphase sicherlich sinnvoll. Voraussetzung ist natürlich, dass man genug Erfahrung in der Planung solcher Projekte hat.
Weiss man im Vorhinein aber schon, dass sich Anforderungen eh jederzeit ändern können, weil der Kunde selbst nicht weiss, was er will, dann reicht imo eine grobe Planung der Architektur und des Designs.
Im Zeitalter leistungsstarker IDEs und Refactoring kann man das Design der Anwendung ja auch nachträglich gut anpassen und umgestalten.

Planner schrieb:

Ich bin an einem Projekt dran, von dem ich anfang an alle sorgfälltig plane.. aber es ist halt nich "immer" gesagt das die optimale lösung gefunden wurde... alle paar tage wochen kommt mir ein neue gedankengang, vision.. wie ich etwas noch perfekter optimaler machen können.. und dann fang ich von vorne an...

Halte ich für einen großen Fehler. Entscheide Dich für eine Lösung, setz sie um. Fertig. Änderungen (Optimierung, refaktoring etc) sollten nur bei Notwendigkeit gemacht werden, nicht "nur" weil man gerade noch ne andere Idee hat.
Andernfalls wird das Projekt nie fertig, denn es gibt (fast immer) noch eine alternative, "bessere" Lösung.

Btw, die optimale Lösung ist nicht gleichzeitig die best mögliche. OPtimal ist eine Lösung die mit einem minimalen (Zeit)Aufwand genau das Ergebnis liefert, daß man braucht.

Planner schrieb:

Welche Fachbücher schlägst du denn vor (C++ und anhängsel)

Für Dich wäre ein guter Anfang:

http://www.amazon.de/Pragmatic-Programmer-Journeyman-Master/dp/020161622X

Gerade bei dem was Du über deine Arbeitsweise beschriebst sollte das Buch für Dich echt hilfreich sein.

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.