Thema: Designphase

[osDeveloper93]

Hallo, da bin ich wieder

ich fand das dieses Thema allumfassend ist und damit steckte ich ihn in den Offtopic Bereich. Ich hoffe niemand ist böse.
Also hier geht es um die Frage der Designphase, nicht wie ich mein OS designe, dafür gibt es viele Threads. Ich will nur wissen ob ihr eine Designphase habt, wie bei den großen Profis (Natürlich gibt es auch hier Profis, ahh ihr versteht was ich meine), die die Designphase gerne länger halten als die Programmierphase.

Bei mir geht die Designphase leider nur ein paar Tage und dann geht die Implementierung des Code los.
Dazwischen designe ich immer ein bisschen. Dies ist meiner Meinung nach nicht gut, aber ich kann nicht anders.
Wie macht ihr es?

Mit freundlichen Grüßen
osDeveloper93

[kevin]

Wovon du keine Ahnung hast, das kannst du nicht designen. Ich gehe davon aus, dass du noch keine große OS-Dev-Erfahrung hast, insofern wirst du einfach mal machen müssen. Du kannst aber gleich einplanen, ein paar Kernel wegzuwerfen, bevor du was hast, womit du zufrieden bist.

[Svenska]

Ähnlich.

Ich überlege mir gewisse Ansätze und programmiere solange drauflos, wie ich glaube, den vollständigen Überblick im Kopf zu behalten.
Stelle ich fest, dass ich genau das nicht habe, dann fange ich an, auf Papier die wichtigen Datenstrukturen zu skizzieren und notiere mir Blockdiagramme mit den Zusammenhängen und Abhängigkeiten der Einzelteile.

Dieses Verfahren wende ich dann rekursiv auf alle Blöcke an.

Wenn ich einen Teilabschnitt fertig habe, dokumentiere ich den gleich mit, weil ich die Gründe dafür dann noch im Kopf habe. Zwischendurch, wenn mir grad nicht nach Coden ist oder mir grad der geniale Einfall fehlt, dokumentiere ich dann die Zettelwirtschaft auch digital in Textform.

Denke, das gibt so meine Programmierweise einigermaßen wieder. Die so entstandenen Designs variieren in ihrer Qualität allerdings sehr stark, je nachdem, wieviel Gülle schon produziert ist, ehe ich überhaupt anfange zu planen.

Gruß,
Svenska

[osDeveloper93]

Wovon du keine Ahnung hast, das kannst du nicht designen. Ich gehe davon aus, dass du noch keine große OS-Dev-Erfahrung hast, insofern wirst du einfach mal machen müssen. Du kannst aber gleich einplanen, ein paar Kernel wegzuwerfen, bevor du was hast, womit du zufrieden bist.

Naja, ich würde nicht sagen das ich ein Anfänger bin, im Programmieren bin ich schon seit langem ein Fortgeschrittener (Aus meiner Sicht) und im OS-Dev bin ich auch schon seit 2 Jahren. Aber das man Sachen nicht designen kann, wovon man keine Ahnung hat ist richtig. Aber man kann sich sein Framework (Ein OS ist auch teilweise ein Framework) in Module und mehr einteilen, was eigentlich nichts anderes ist als designen.
Aber sonst stimme ich dir zu, ich selber habe schon 2, 3 Kernel weggeschmissen bzw. eingefroren (Ich schmeiße nichts weg - ist mir zu schade).

Bei mir wird am Anfang alles per Bleistift gezeichnet und die Dependies werden relativ känntlich gemacht.
Danach, wenn ich Zeit hab, digitalisiere ich es und fange mit einem anderen Bereich von vorne an.
Das alles passiert meistens parrallel zum Implementieren des Codes.
Aber eigentlich sollte sowas vorher gemacht werden (Nicht alles, die Details ändern sich so oder so), sonst hat man später meistens Probleme was das designen und strukturieren des Codes anbelangt.
Bei mir sind schon viele Projekte zu Boden gegangen, aber naja ich bin auch kein Profi, aber ein Anfänger genauso wenig.
Ahh ja, man bekommt nicht immer Probleme, Ausnahmen bestätigen bekanntlich die Regel.

[Programm Noob]

kann man von deinem OS was sehen?

[erik.vikinger]

Hallo,


ich bin eher der Typ der vorher alles recht gründlich durch plant. Ich erstelle mir ein schriftliches Konzept und auch eine ToDo/Ideen-Liste (damit keine meiner genialen Ideen abhanden kommt). Dazu kommt eine hierarchische modul-orientierte Dokumentation die als erstes natürlich nur den Sollzustand definiert aber während der Implementierung auch an sich ändernde Gegebenheiten angepasst wird um dann dem Istzustand zu entsprechen. Wenn das Ist noch nicht ganz dem entspricht was ich mir als Soll vorstelle dann wird das auch mit notiert. Diese Dokumentation ist eher Modul-Bezogen und beschreibt vor allem Dinge wie Zusammenhänge und andere grobe Infos, dazu kommt dann noch die Quell-Code-Dokumentation die dann die ganzen Feinheiten erklärt. Gerade in den Headerdateien sind aber oft auch längere Erklärungen drin die die einzelnen Funktionen ausreichend erläutern. Während der Planung eines Moduls kann es sein das ich schon mal ne Reihe an Headerdateien anlege und mit Text (und Funktionsdeklarationen) fülle bevor auch nur eine Quell-Code-Zeile in die Code-Dateien kommt.
Eine gründliche Design-Phase nimmt natürlich eine Menge Zeit in Anspruch, das rechnet sich aber oft indem dann die Implementierung reibungsarm durchläuft, gerade in Teams ist das von Vorteil. Um eine Planung aber bereits vor der ersten Zeile Code so gut hinzubekommen das die auch wirklich was taugt und nicht schon nach 10% vom Code wieder komplett umgeworfen werden muss benötigt man aber tatsächlich einiges an Erfahrung und die kommt nun mal nur durch viel Übung. Auch das Zerteilen eines Projekts in sinnvolle Module (nicht zu kleine aber auch nicht zu große) ist eine kleine Kunst für sich.

Mit schlechter Planung kann man aber auch viel unnötige Arbeit und ein sehr schlechtes Ergebnis produzieren, als "passendes" Beispiel sei mal dies genannt: http://www.scheissprojekt.de/hausbau.html

Wer mit dem Planen noch nicht so die Übung hat sollte das wirklich erst mal nur nebenbei mitlaufen lassen und seine Zeit doch lieber im Editor verbringen. Mit einem iterativen Design-Ansatz, man coded so lange bis man sich sicher ist das alles nur Müll ist und fängt dann noch mal bei 0 an und versucht die vorherigen Fehler (falls man diese überhaupt erkennt) zu vermeiden, kommt man sicher auch nicht sehr schnell zu einem vorzeigbarem Ergebnis aber man sammelt einiges an Erfahrung (man lernt auf jeden Fall eine Menge Wege kennen die nicht zum Ziel führen). Auch ich hab viele Jahre gebraucht bis ich diese Methode zuverlässig überwunden hab.

Ein anderer Weg (IMHO ein sehr guter) an die nötige Erfahrung zu kommen ist sich einem bestehenden Projekt, in dem einige Profis die Design-Arbeit machen, anzuschließen. Lernen durch zuschauen und mitmachen ist recht effektiv.


Grüße
Erik

[osDeveloper93]

kann man von deinem OS was sehen?

Jop, aber ich arbeite gerade nicht daran,
wie gesagt weit bin ich nicht, nach den mehreren wegwerfen bzw. einfrieren.

Ich kann euch leider auch keine Bilder zeigen, weil ich gerade keinen Linux zur Hand hab, um das OS-Dev fortzusetzen bzw. zu emulieren und euch die Bilder zu zeigen. (Natürlich ist es auch auf diesem Computer möglich, jedoch möchte ich das OS-Dev nicht mit diesem Betriebssystem (Ihr wisst wen ich meine ) fortsetzen.)

ich bin eher der Typ der vorher alles recht gründlich durch plant. Ich erstelle mir ein schriftliches Konzept und auch eine ToDo/Ideen-Liste (damit keine meiner genialen Ideen abhanden kommt). Dazu kommt eine hierarchische modul-orientierte Dokumentation die als erstes natürlich nur den Sollzustand definiert aber während der Implementierung auch an sich ändernde Gegebenheiten angepasst wird um dann dem Istzustand zu entsprechen. Wenn das Ist noch nicht ganz dem entspricht was ich mir als Soll vorstelle dann wird das auch mit notiert. Diese Dokumentation ist eher Modul-Bezogen und beschreibt vor allem Dinge wie Zusammenhänge und andere grobe Infos, dazu kommt dann noch die Quell-Code-Dokumentation die dann die ganzen Feinheiten erklärt. Gerade in den Headerdateien sind aber oft auch längere Erklärungen drin die die einzelnen Funktionen ausreichend erläutern. Während der Planung eines Moduls kann es sein das ich schon mal ne Reihe an Headerdateien anlege und mit Text (und Funktionsdeklarationen) fülle bevor auch nur eine Quell-Code-Zeile in die Code-Dateien kommt.
Eine gründliche Design-Phase nimmt natürlich eine Menge Zeit in Anspruch, das rechnet sich aber oft indem dann die Implementierung reibungsarm durchläuft, gerade in Teams ist das von Vorteil. Um eine Planung aber bereits vor der ersten Zeile Code so gut hinzubekommen das die auch wirklich was taugt und nicht schon nach 10% vom Code wieder komplett umgeworfen werden muss benötigt man aber tatsächlich einiges an Erfahrung und die kommt nun mal nur durch viel Übung. Auch das Zerteilen eines Projekts in sinnvolle Module (nicht zu kleine aber auch nicht zu große) ist eine kleine Kunst für sich.

Sehr schön, leider kann ich sowas noch nicht, naja du hast sicherlich auch mehr Erfahrung als ich.
Tja was soll man da machen...

[Svenska]

Tja was soll man da machen...

Üben?

[osDeveloper93]

Tja was soll man da machen...

Üben?

Stimmt.

[erik.vikinger]

Hallo,


ich hoffe es ist nicht so arg schlimm das ich diesen Thread noch mal aufwärme aber ich finde es wurde ein wichtiger Punkt vergessen:


Wenn man sein Projekt in mehrere Module unterteilt und Modul B von Modul A abhängig ist dann sollte man erst mal Modul A fertig stellen (wenigstens so weit wie von B benötigt) bevor man mit Modul B anfängt. Nichts kann so frustrierend sein wie eine unzuverlässige Basis, so das man bei merkwürdigem/unerklärlichem Verhalten quasi den gesamten Code unter Verdacht stellen muss (weil eigentlich alles nur mal schnell mit heißer Nadel gestrickt wurde). Wenn Du mit Modul A heute nicht mehr weiter kommst (weil die nötigen Ideen fehlen oder noch unausgereift sind) dann verfalle bloß nicht der Verlockung schon mal mit Modul B anzufangen. Mach lieber ne Pause, geh Spazieren, schlafe ne Nacht (oder auch mehrere) drüber, leg ne DVD ein oder mach mit Deiner Freundin einen romantischen Abend (so richtig mit gutem Essen und allem was danach noch so kommt). Gerade bei einem Hobbyprojekt, wo man keinen wartenden Chef mit ner Deadline hat, sollte man nicht in Übereifer verfallen. Das entwickeln von Software ist eine künstlerische kreative Tätigkeit, das kann man nicht erzwingen! Ein Bildhauer braucht sich auch nicht mit Hammer und Meißel in der Hand vor einen rohen Stein zu stellen wenn er nicht eine genaue Vorstellung davon hat was aus diesen Stein mal werden soll.


Erfahrung entsteht nur durch die wiederholte Tat, egal bei was. Wenn Du noch keine Erfahrung mit einer richtigen Designphase hast dann mach erst mal nur ein ganz simples Design, wichtig ist das Du überhaupt mal anfängst aber auch hinterher versuchst Deine Fehler zu analysieren damit Du diese nicht zu oft wiederholst. Fehler machen wir alle das ist keine Schande, aber nichts daraus zu lernen das ist eine Schande!


Grüße
Erik


edit: YEAH, Hero Member!