Wie geht ihr größere Projekte an: Welche Funktionalität gehört in welche Klasse?

Hallo,

konnte dazu leider nichts in der Suche finden und da mir zu meinem Projekt gerade wieder tausende Dinge einfallen, die ich gerne umgesetzt haben möchte, stellt sich mir die Frage, wie geht ihr große Projekte an?

Immer wieder bemerke ich, dass sobald ich die Klassenerstellungen mit Konstruktoren und Properties größtenteils abgeschlossen habe und ich mich um die Logik und die Kommunikation von den Klassen untereinander kümmern muss mir das doch sehr schwer fällt.
Welche Logik muss in welche Klasse, muss diese Logik vielleicht sogar in eine andere Klasse ausgelagert werden, weil sie weder in die eine Klasse noch in die andere Klasse so richtig reinpasst? Der Verwaltungsaufwand wäre dann aber wieder um einiges größer.

Sollte man sich stur erstmal auf eine Klasse konzentrieren und alle Funktionalitäten außerhalb außer acht lassen? Ich habe mich dabei bemerkt, dass ich doch recht viel zwischen den Klassen hin und her switche.

Gibt es da vielleicht irgendeine allgemein gültige Herangehensweise?

Hallo,

Im vorhinein planen wäre ne Idee 😉 Was du beschreibst ist genau das, was nen Programmierer vom Softwareentwickler unterscheidet. Zur Softwareentwicklung gibts unzählige Bücher und dutzend unterschiedliche Herangehensweisen. Der Wiki Eintrag Softwareentwicklung gibt da ne grobe Übersicht zum weiter einlesen ins Thema.

Im klassischen Idealfall hat man das Programm komplett durchgeplant und die eigentliche Programmierung ist dann in kürzester Zeit erledigt, weils nur noch in Code herunterschreiben des geplanten ist. Den Idealfall gibts so natürlich nie und einige Entwicklungsmodelle unterscheiden sich auch komplett von dem Ansatz. Da muss man sich bissle durchwühlen, welchen Entwicklungsmodell einem am meisten passt. Wenn man aber immer wieder beim programmieren merkt, dass man umstrukturieren muss, weil man was vergessen hat, dann macht man definitiv was falsch.

Ich scheue mich nicht, Strukturen während der Entwicklung umzuschmeißen, wenn das nötig sein sollte. Heißt, wenn eine neue und bisher nicht geplante Klasse sinnvoll ist, kommt sie rein und fertig. Wenn eine Klasse mit der Zeit nicht mehr gebraucht wird, fliegt sie raus. Eine Klasse ist bei mir auch immer veränderbar, ohne schlechtes Gewissen.
Alles komplett im Voraus planen und bereits in der theoretischen Phase auf die letzten Details zu kommen, halte ich schlicht für unmöglich.
Da finde ich, die Zeit für die Theorie der kleinsten Details ist teilweise besser für erste praktische Schritte investiert. In denen finde ich mich besser zurecht als in reinen Überlegungen und dabei entsteht dann wenigstens schon ein ansatzweise brauchbares Grundgerüst.

Ich hatte bisher übrigens noch kein Projekt, bei dem nicht während der Entwicklung, Tests und Vorführung von Programmteilen irgendwelche Änderungen oder neue Ideen ect. aufgekommen sind. Sowas macht die beste Planung kaputt und dann ist nur Zeit drauf gegangen.

Ich finde vor allem Requirement Engineering wichtig. Das ganze System bis ins letzte Detail durchzuplanen funktioniert in der Praxis selten und mir wär das ehrlich gesagt auch zu langweilig. Aber ganz schlecht ist es, wenn einem nach der Hälfte der Entwicklung plötzlich einfällt, dass man ein paar wichtige Anforderungen vergessen hat und die überhaupt nicht ins bisherige Konzept passen. Das ist natürlich ein schwieriger Punkt, vor allem bei Kundenprojekten, wo man nicht selber die Anforderungen definieren kann. Da ist es wichtig, etwas vorauszuplanen, was dem Kunden noch für Anforderungen einfallen könnten. Wenn man schon ähnliche Projekte gemacht hat, geht das einfacher.

Hallo Bunnychecker,

Welche Logik muss in welche Klasse, muss diese Logik vielleicht sogar in eine andere Klasse ausgelagert werden, weil sie weder in die eine Klasse noch in die andere Klasse so richtig reinpasst? Separation of Concerns (von Clean Code Developer)
Separation of concerns (bei Wikipedia)

Und wenn es deshalb zu Umstrukturierungen kommt: Refactoring.

Und hier noch ein Vorschlag von Ralf Westphal, bei dem gar kein (Vorab-)Design des Gesamtsystems nötig ist: Spinning – Vorschlag für den Kern jedes Vorgehensmodells. Dann ist allerdings ständiges Refactoring vorprogrammiert.

Ansonsten, auch wenn schon älter, gilt Tipp zur Herangehensweise an neue Projekte nach wie vor.

herbivore