Herangehensweise/Planung/Umsetzung eines Projektes
-
uups, quote statt edit gedrückt hab.
-
Das muss man ja alles vorher wissen bevor man loslegt zu programmieren.
Ja, das wäre enorm praktisch. Wie man bei diversen Großprojekten immer wieder sieht, klappt es nicht jedes mal.
Ganz konkret, diesen Fall hab ich noch nie erlebt, es ändert sich immer was.
-
oop-greenhorn schrieb:
Das muss man ja alles vorher wissen bevor man loslegt zu programmieren.
So funktioniert es nicht. Dieses Wissen mußt du dir Schritt für Schritt aneignen, so wie du eine Fremdsprache lernst: nicht ein Wörterbuch auf einmal auswendig lernen sondern anfangen mit reden. Wenn du wartest bist du perfekt bist wirst du niemals anfangen. Ich mache das jetzt seit 15 Jahren, stemme teilweise Projekte mit 500000 loc alleine und ich schaue zurück was ich schon alles erreicht habe, ich schaue nach vorn und sehe was ich noch alles lernen muß!
Fang an vllt ein Buch zu lesen über Design und verstehe warum und wie die einzelnen Elemente einer Software abstrahiert und getrennt werden. Dann versuche die Teile zu verwenden, die du verstanden hast und für richtig befindest. Danach frage dich ob der Aufwand überhaupt was gebracht hat, ob er bei nachträglichen Änderungen wirklich sich amortisiert hat.
Das wird mit jedem Projekt besser.
-
witte schrieb:
stemme teilweise Projekte mit 500000 loc alleine
Du bist schnell.
Für 500000 loc würde ich 30 Jahre brauchen.
-
Ich mach ein neues Projekt nach diesen Schritten (mehr oder weniger
).* Ein Dokument erstellen was die Aufgaben/Anforderungen an das System sind.
* Grobe Aufteilung der Sub-Systeme (Datenbank, GUI, Input, Output, usw.)
* Grobe Skitze der GUI/der Sub-Systeme machen
* User Case Diagramme mahlen
* Ein Conceptual Design machen
* Geruest der Sub-Systeme programmieren (Klassen, die grob das machen was sie sollen, mit eine menge Dummy-Methoden)
* Schauen ob alles passt und flexibel genug ist, ggf. das Conceptual Design anpassen
* Zur Dokumentation ein Klassendiagram mahlen
* Die einzelnen Sub-Systeme implementieren und testen
* Die Sub-Systeme zusammenfuehren, ggf. das Design anpassen* Solange das System nicht das macht was es soll:
** Solange testen und Bugs ausmaerzen, bis alles glatt laeuft
** ggf. das Klassendiagram aktuallieren
** Neue Features einbauenFuer mich ganz wichtig am Anfang: Papier und Bleistift. Egal ob fuer OOA/OOD-Diagramme oder fuer Skitzen. Was immer beim Design Wichtig ist: Immer in Sub-Systeme denken. Ein Sub-System hat genau eine Aufgabe. Dadurch kannst du die Bugs schneller entdecken und besser optimieren, ausserdem kannst du ein Sub-System dann unaebhaenig von den anderen implementieren/veraendern. Am Ende werden die ganzen Sub-Systeme zu einem Programm zusammengefuehrt.
-
witte schrieb:
Ich mache das jetzt seit 15 Jahren, stemme teilweise Projekte mit 500000 loc alleine
Viel Copy und Paste oder wann hast du das alles programmiert.
-
Copy and Paste ist jetzt allerdings eher ein Antipattern.
-
User Case Diagramme mahlen
Wofür brauchst du Papiermehl?
-
hmmmmm? schrieb:
witte schrieb:
Ich mache das jetzt seit 15 Jahren, stemme teilweise Projekte mit 500000 loc alleine
Viel Copy und Paste oder wann hast du das alles programmiert.
Schätze mal er meint mit 'stemmen' nicht, die Anwendung von der grünen Wiese selbst zu programmieren, sondern vielmehr Wartung, Pflege und Weiterentwicklung eines ansonsten fertigen Projekts mit 500k LOCs.
-
byto schrieb:
Schätze mal er meint mit 'stemmen' nicht, die Anwendung von der grünen Wiese selbst zu programmieren, sondern vielmehr Wartung, Pflege und Weiterentwicklung eines ansonsten fertigen Projekts mit 500k LOCs.
Da wäre ich mir nicht. Ein Projekt selber zu schreiben ist oft viel einfacher, als ein fremdes zu pflegen. Außerdem kenne ich das wort "stemmen" bereits in der Softwareentwicklung, wenn der Chef den Programmierern Honig um den Bart schmiert, um sie zu überzeugen, ein großes Projekt total unterbesetzt anzugehen.
-
oop-greenhorn schrieb:
Wie macht man sowas?
grob gesehen gibts zwei extreme herangehensweisen, einen ingenieursmässigen und einen künstlerischen. vertreter der ersten sorte planen, validieren, messen, untersuchen teilprobleme mit hilfe wissenschaftlicher methoden, usw. die andere gruppe setzt sich vor'n computer und entwickelt intuitiv drauf los, wie kunstmaler bilder entstehen lassen. in der realität gibts aber eher mischformen aus beiden welten.
