3. Vorgehen beim Programmieren

Vorgehen beim Programmieren

  • S

    Govedar schrieb:

    1. Problem verstehen
    2. PAP / Struktogramm
    3. Coden
    4. Ausführen / Fehler beheben
    5. DOku dazu schreiben

    Kommt darauf an, nach welchem Entwicklungsmodell und welchen Anforderungen du / ihr arbeitet. Das haengt sehr vom Einsatz der Techniken bzw. des Modelles ab.

    Rapid Prototyping, Wasserfall, Extreme Programming usw. unterscheiden sich teilweise sehr voneinander.

    Ich empfehle dir mal Rapid Development als Buch, als Referenz / Uebersicht.

    PAP / Struktogram habe ich allerdings noch nie wirklich in einer Firma gesehen.
    PAP auf Basis von UML wird meist erstellt, wenn man in einem schlecht Dokumentierten Teil von einem Programm Bugs sucht, um sich eine Uebersicht zu verschaffen.
    Ansonsten kommt UML inzwischen immer oefter zum Einsatz, und das ist auch gut so. Leider stellt sich meist in der Implementationsphase heraus, dass nicht alle Teile richtig bedacht wurden, und man wieder etwas aendern muss.

    0
  • N

    SnorreDev schrieb:

    Ansonsten kommt UML inzwischen immer oefter zum Einsatz, und das ist auch gut so.

    nee, uml ist voll übertrieben. ausser statecharts kann man das kaum gebrauchen.

    0
  • X

    net schrieb:

    SnorreDev schrieb:

    Ansonsten kommt UML inzwischen immer oefter zum Einsatz, und das ist auch gut so.

    nee, uml ist voll übertrieben. ausser statecharts kann man das kaum gebrauchen.

    du meinst, außer statecharts kannst _du_ es kaum gebrauchen 👎

    0
  • N

    xroads42 schrieb:

    du meinst, außer statecharts kannst _du_ es kaum gebrauchen 👎

    äääh... ja 😉

    0
  • M

    Sgt. Nukem schrieb:

    3.b) abartige seltsame Diagramme und Zeichnungen auf DIN A4 Seiten und PostITs kritzeln, die man am nächsten Tag selbst nicht mehr versteht 👍

    DIN A2 👍 🤡

    0
  • J

    1. Problem mit ner netten Geschichte versehen und als WPC posten
    2. 1 Woche warten
    3. Schnellste Lösung benutzen

    🤡

    0
  • G

    Kenn das ganze eigentlich auch so wie Walli (woran erinnert mich nur dieser Name 😕 ) bereits geschrieben hat. Allerdings verlaufen bei mir Grobentwurf und Feinentwurf eher ineinander.

    0
  • S

    maximAL schrieb:

    Sgt. Nukem schrieb:

    3.b) abartige seltsame Diagramme und Zeichnungen auf DIN A4 Seiten und PostITs kritzeln, die man am nächsten Tag selbst nicht mehr versteht 👍

    DIN A2 👍 🤡

    Würd' ich wenn ich könnte... 😃

    0
  • J

    Ich lese hier kurz rein und bin schockiert... praktisch keiner hat das Thema Dokumentation erwähnt ausser dem Fragenden selber.

    Mein üblicher Entwicklungsablauf:

    1. Problemanalyse
2. Modul/Objektmodell
2.1 Identifikation der Funktionsgruppen
2.2 Definition der Schnittstellen
3. Bestimmen der Core-Module
4. Codierung des Cores mit paralleler Dokumentation (bin viel zu vergesslich)
5. Debuggen des Cores
6. for (int n = 0;n < ANZAHL_REST_MODULE;n++)
   {
       ProcessStep1and2OnModule(n);
       CreateTask(CodeModule(n));
       CreateTask(DocumentModule(n));
       CreateTask(TestModule(n));

       WaitForAllTasks();
   }
7. Manual schreiben.
    0
  • W

    junix schrieb:

    Ich lese hier kurz rein und bin schockiert... praktisch keiner hat das Thema Dokumentation erwähnt...

    Lies mein Posting doch noch etwas genauer. Das war keinesfalls als Abfolge zu verstehen. Natürlich wird die Modulspezifikation angepasst, wenn es während der Codierung notwendig wird.

    0
Anmelden zum Antworten