Größeres Projekt, wie vorgehen?



  • Nicht zu viel planen, einfach mehr programmieren. Dann wird man auch besser. Nur Theorie Bücher lesen bringt es nicht und langweilig ist es obendrein. Die ersten Projekte die man macht sind eben nicht gleich perfekt, ist ja nicht so schlimm.



  • [*]überlege dir genau was das programm können soll -> aufschreiben
    später wirste dann zwar eh beliebig davon abweichen, aber hattest erstmal beim aufschreiben ein gutes gefühl.

    [*]überlege dir genau, wie du was implementieren willst -> aufschreiben
    dito.

    [*]benutze ein versionsverwaltungssystem
    es ist aber auch ausreichend, ein tägliches backup zu machen.

    [*]schreib evtl. die files für dein build system selbst, damit du nicht a.d. IDE gebunden bist
    oder besser verschieb das, bis du wirklich ne andere IDE benuten willst.

    [*]benutze ein ordentliches in-source dokumentationssystem (doxygen?, keine ahnung ob das C# kann) und schreibe viele kommentare
    oder lass es, und schreibe verständlichen code.

    [*]dokumentiere benutzung und die groben zusammenhänge der implementation separat
    oder mach keine undurchsichtigen zusammenhänge.

    [*]Schief gehen kanns immernoch, aber so verringerst du die wahrscheinlichkeit stark
    schief gehen wird es, aber das gehört dazu. beim zweiten mal biste doppelt so schnell und alles wird auch viel viel besser. das zweite mal sei einfach mit eingeplant.



  • Verfechter des Extreme Programming würden dir hier noch zu durchgehenden Unit Tests raten.
    Ich würde dir empfehlen, alles aufzuschreiben. Bugs, Bugfixes, Änderungen, Ideen usw.. Ich kann mir nicht mehr als fünf Bugs im Detail merken, bei mehr Informationen vergesse ich immer die Erste (siehe FILO Queue 😉



  • Extreme Programming macht eigentlich nur bei kleinen Projekten Sinn, wenn man es bei größeren macht fallen einem später doch noch tausend Sachen ein die man hätte anders machen sollen weil das Konzept nicht aufgeht, das Browserspiel nicht balanced ist, man Spiel x grad gespielt hat und das noch drinhaben will usw.
    Programmierst du dann noch mit mehr als zwei Leuten ist Chaos vorprogrammiert.
    Das zeigen auch sehr sehr viele(fast alle) komplexeren Hobbyspieleprojekte, die werden nämlich genau deswegen nie fertig.
    Also lieber 100 Stunden planen und 100 Stunden programmieren als 150 Stunden programmieren, dann feststellen das xx ganz anders sein muss, 20 Stunden das komplette Programm umschreiben, dadurch wieder drei Fehler produzieren, die wieder 20 Stunden raushauen, dann fällt nochwas ein, man versucht es zu implementieren, geht nicht "muss der Kunde eben ohne Leben" usw.
    Ganz zu schweigen vom immer wieder unter Zeitdruck und/oder schlaflosigkeit durchgeflickten meist hässlichen Code und der vermutlich uneinheitlichen Benutzeroberfläche.

    Kann natürlich alles bei Planung ebenso passieren, aber es gibt da sehr überzeugende Statistiken... sehr sehr sehr überzeugende.

    In fast allen Fällen dauert es wesentlich länger draufloszucoden, hauptsächlich weil es wesentlich länger dauert kurz vorm Ende etwas umzuschreiben als im Konzept etwas durchzustreichen, aber wenn es dir in den Fingern juckt endlich Code zu schreiben etc fang ruhig ein großes Projekt einfach so an, habs im Endeffekt auch nur so lernen können und dachte genauso ^^
    Besonders weil man halt an seinem Hobbyprojekt rumbasteln will und nicht seine Freizeit mit planen verbringen will.

    Wie man das im Endeffekt macht, dazu gibt es tonnenweise Bücher die alle was verschiedenes sagen usw.

    Ich würd das aber davon ausgehend das du unter einem großen Projekt etwas woran du länger= ein paar Monate oder Jahre allein programmierst und nicht mehr in drei Phasen aufteilen:

    1 Nachdenken/Analysieren was will ich und was brauche ich und das dann aufschreiben, das wird meist nicht gemacht, rächt sich aber später dann weil es halt spätere Korrekturen reduziert.
    Wenn du Kunden und Auftraggeber hast: so viel und so ausführlich wie möglich rausquetschen.
    Wenn du nur so etwas programmierst: denke gut nach und frag viele potentielle Nutzer nach ihrer Meinung zu dem ausgedachten.

    2. aufschreiben wie du es realisieren willst
    Wenn du nur alleine programmierst kannst du dir da vermutlich selbst ausdenken in welcher Form, hauptsache du durchdenkst alles relevante bevor du Code tippst und zeichnest es in einer geeigneten Form auf.
    Falls du nicht weisst wie oder dich an "Normen" halten willst, es gibt da diverse Möglichkeiten die sich ständig ändern.
    Früher wars Sa/Se, heute ist wohl Uml recht aktuell und sollte verwendet werden. Wissen darin schadet auch nie im Beruf wenn du etwas in der Richtung machen willst.
    Hierzu hat unser Prof. auch mal ein Buch empfohlen, "Uml glasklar" hiess es glaube ich.
    In dieser Phase lohnt es sich wiederum möglichst oft möglichst vielen verschiedenen potentiellen Anwendern zu zeigen was sie davon halten, das garantiert das du nichts nur für dich verständliches einbaust usw.
    Dabei aber halt auch nicht mit Kanonen auf Spatzen schießen und das alles ein wenig der Programmgröße anpassen.
    Hier empfehlen sich natürlich dann wieder genormte und möglichst einfache Darstellungsformen, sonst muss man erst soviel erklären ^^

    3. Erst jetzt nachdem du weisst was du drin haben willst, es mit Auftraggebern/Endanwendern abgesprochen hast und stolz auf den Papierberg bist, tippst du Code.
    Dies wird dir jetzt schnell gelingen und du wirst das, vorausgesetzt du kannst gut programmieren, alles so runterrattern.
    Du hast innerhalb kürzester Zeit eine fertige Anwendung die dem entspricht was alle wollen... zumindest in der schönen Theorie.
    Praktisch wird es zu Problemen kommen wenn der Auftraggeber(was auch du selbst sein kannst) plötzlich auf die Idee kommt das Feature x ja noch ganz toll wäre, deine tolle Doku hat irgendwas nicht bedacht oder du bist doch von ihr abgewichen weil es nicht ging oder du es dir anders überlegt hast usw.

    Deswegen empfielt es sich auch hier möglichst viel und besonders oft testen zu lassen, aber sich jetzt nicht mehr allzu leicht von Änderungen überzeugen zu lassen, sondern nur machen wenn sie wirklich sehr sinnvoll und vertretbar sind, ansonsten auf "mach ich wenn alles andere fertig ist als Update" schieben 😉 .
    Generell kann man aber sagen, die Probleme sind nichts im Vergleich zu dem was dir ohne Planung begegnen würde.
    Du bist dann fast fertig und stellst fest "das ist nicht erweiterbar auf xyz und genau das will ich aber, also nochmal das Ganze" usw und ständiges Bugfixen unter Zeitdruck tut dem Quellcode auch nicht gut und produziert sehr schöne Fehler.



  • erstmal aufschreiben, was das programm alles können soll, ist pflichtsache. sonst verrennt man sich irgendwann.

    was ich bei projekten, die man gänzlich allein entwickelt, festgestellt habe ist, dass man schneller ans ziel kommt und robusteren code produziert, wenn man sich immer jeweils auf eine komponente konzentriert.

    ne zeitlang haben viele ihr gesamtes projekt in nem uml-tool zusammengeklickt, die klassen exportiert und dann an diesem riesen framework gearbeitet.

    ich halte es für sinnvoller, wenn man mit irgendeinem kern-modul anfängt und dann stückweise code anfügt.

    will man beispielsweise ein kleines spiel entwickeln, so kann man zunächst ein modul schreiben, welches sich um die "spielfeld" darstellung kümmert.
    da kann man dann kleine testroutinen schreiben, die das feld mit zufallswerten füllen und rumtesten, bis es anständig funktioniert.

    dann kümmert man sich eventuell um die steuerung, erstellt ein interface (internes, nicht grafisch) für das spielchen und kann das ganze testen.

    dann geht man vielleicht über zur KI entwicklung, die das interface benutzt, um das spiel zu steuern. usw.

    das mag nicht optimal sein, aber ich habe zu oft festgestellt, dass man sehr schnell an die grenzen seines codes gerät, wenn man das framework gleich zu beginn in form giesst und dann während der entwicklung feststellt, dass irgendwas doch nicht so funktioniert, wie man es sich ausgedacht hatte.

    das funktioniert nur dann gut, wenn man sehr sehr viel überlegungen in die vorarbeit steckt.
    und für eigene projekte macht einem das möglicherweise keinen spass 😉





  • Interessanter Artikel, vielen Dank. 🙂



  • volkard schrieb:

    [*]überlege dir genau was das programm können soll -> aufschreiben
    später wirste dann zwar eh beliebig davon abweichen, aber hattest erstmal beim aufschreiben ein gutes gefühl.

    warum? ich denke zumindest die erstimplementation sollte genau das tun.

    volkard schrieb:

    [*]überlege dir genau, wie du was implementieren willst -> aufschreiben
    dito.

    dito

    volkard schrieb:

    [*]benutze ein versionsverwaltungssystem
    es ist aber auch ausreichend, ein tägliches backup zu machen.

    eventuell. Aber ein rcs übernimmt noch changelog verwaltung und ist feingranularer.

    volkard schrieb:

    [*]schreib evtl. die files für dein build system selbst, damit du nicht a.d. IDE gebunden bist
    oder besser verschieb das, bis du wirklich ne andere IDE benuten willst.

    möglich

    volkard schrieb:

    [*]benutze ein ordentliches in-source dokumentationssystem (doxygen?, keine ahnung ob das C# kann) und schreibe viele kommentare
    oder lass es, und schreibe verständlichen code.

    sehr schlechte idee für bibliotheken, IMHO. auch für programme hat in-source doku mitunter sinn, IMHO. verständlich solls natürlich sein.

    volkard schrieb:

    [*]dokumentiere benutzung und die groben zusammenhänge der implementation separat
    oder mach keine undurchsichtigen zusammenhänge.

    blödsinn. für ein großes Projekt soll es separate dokus geben. sowohl von implementation als auch benutzung. Wenn ich das verändern will und mich erst durch 20 dateien arbeiten muss ist das schlecht. sehr schlecht.

    volkard schrieb:

    [*]Schief gehen kanns immernoch, aber so verringerst du die wahrscheinlichkeit stark
    schief gehen wird es, aber das gehört dazu. beim zweiten mal biste doppelt so schnell und alles wird auch viel viel besser. das zweite mal sei einfach mit eingeplant.

    🙂



  • Hallo,
    das ist ein ein sehr interessantes Thema. Auch ich programmiere schon seit Jahren hier und da mal mehr oder weniger mit kleinen Dingen vor mir her (meist C++), möchte jetzt aber auch mal ein etwas größeres Projekt starten.

    Bei so kleinen Programmen ist es (für mich)ja meist egal wie man es wie man es macht... am besten so schnell und eifnach wie möglich solange es gut funktioniert... Fehlerbehandlung und Design sind da ja eher Nebensache.

    Wenn ich jetzt ein größeres Projekt anfange fehlen mir wahrscheinlich viele Kenntnisse wie ich manche Dinge viel besser machen könnte, besonders in Hinblick auf OOP (alles was nach Veerbung kommt.. Templates etc. habe ich nie verwendet/beachtet). Deswegen wäre es nicht schlecht, wenn ich mich diesbezüglich etwas einlesen könne (aufs Design bezogen)... kann hier denn jemand etwas empfehlen?

    EDIT:Ihh lese mich diesbezüglich mal in der Tutorial Sektion OOP ein... vieleicht hilft es ja.



  • Hat vielleicht noch wer einen Buchtipp zum Projekt-Management? Am Besten zu-
    nächst ein Buch, dass einen Überblick gibt, über die verschiedenen Methoden
    und welche sich für welchen Projekttyp eignen. Ich habe bislang nur an Projekten
    im kleineren Team gearbeitet, wobei wir vieles aus dem Extreme Programming
    verwendet haben - recht erfolgreich. Da aber demnächst größere Projekte auf
    mich zukommen, hätte ich mir da gerne noch etwas Wissen angesammelt.


Anmelden zum Antworten