Moin allerseits

Ich arbeite zur Zeit an der Planung eines (Python-)Projekts. Ich weiss schon heute, dass ich später nicht wissen werde, welche Funktionen die Applikation (Multiplayer Web-Onlinegame) haben wird - auch soll das ganze so Programmiert werden, dass beliebige Funktionen geändert und ersetzt werden können (so z.B. die Spiellogik oder das Frontend) und trotzdem viel beibehalten werden kann (Error-Abhandlung, Datenbankanbindung u.s.w).
Es handelt sich also um ein wachsendes Projekt, welches zu beginn einen kleinen Kern haben wird und mit der Zeit mehr und mehr wächst. Da ich schon einige solche Projekte geführt habe, weiss ich, wie verdammt schnell die ganze Sache unübersichtlich wird und der Code vom Prinzip her nicht dafür gebaut wurde um eine bestimmte Funktion zu implementieren.
Gibt es für diese Art von Projekten irgendwelche allgemeinen Regeln, Modelle, Richtlinien, Prinzipien, damit mir das nicht passiert? Ich mein jetzt weniger von der Softwareentwicklung (also Projekt Phasen u.s.w) als vielmehr auf der Code Ebene. Also wie ordne ich verschiedene Module umeinander an, damit eine möglichst grosse Unabhängigkeit besteht. Welche Module sollten auf welchen basieren und welche einbinden? Soll das Frontend sich die Informationen holen, oder ein Programm-Kern dem Frontend die Informationen stellen?
Ich weiss, dass ist jetzt ne ziemlich blöde Frage und wahrscheinlich gibt es keine klare Antwort darauf. Aber vielleicht hat mir irgendwer ein paar Links zu guten Guides wie ich an eine solche Sache rangehen muss, damit ich in einem halben Jahr nicht dastehe und alles nochmal schreibe.

Das Projekt ist übrigens:
www.sf.net/projects/ilprincipe
aber das nur so nebenbei....

Ich mache es so (oder versuche es zumindest), dass ich Module so schreibe, dass sie absolut unabhängig sind und auch in anderen Projekten eingesetzt werden könnten. Bei meinem UML-Editor kommen so auch Module für CPAN zustande. Dann brauch ich nur noch die Module "zusammenschustern".
Auch teile des Frontends arbeiten "autonom" und werden nur noch im Hauptprogramm "aktiviert". Das ist recht praktisch, da ich dann bei einem Umbau nur das einzelne Modul austauschen muss.

Links zu Guides habe ich nicht, aber wenn Du schon mehrere solcher Projekte geführt hast, solltest Du mittlerweile ein ganz gutes Gefühl dafür haben, wie man es machen kann.

[quote=renee,27.09.2006, 08:19]aber wenn Du schon mehrere solcher Projekte geführt hast, solltest Du mittlerweile ein ganz gutes Gefühl dafür haben, wie man es machen kann.[/quote]
Ich habe eher ein gutes Gefühl, wie man es nicht machen sollte...

Mir ist einfach noch keine gescheite Modul-Hierarchie untergekommen. Es sollte z.B. möglich sein, ohne weiteres mehrere verschiedene Frontends an das System zu binden. Dass jedes Modul total unabhängig von den anderen sein muss, ist klar. Aber welches Modul ist nun das Federführende und ruft welche anderen auf? Ich habe gestern mal angedacht, dass das Frontend-Modul das Hauptmodul ist und sich bei einem Session Modul anmelden muss, bevor es irgendwelche Befehle ausführen kann. Vielleicht wär aber auch eine API sinvoll, so dass das Frontend eine gleichbleibende Schnittstelle hat. Dann wäre das Frontend das Modul, welches selbstständig Daten anfordert, Daten sendet und die Fehlerauswertung (oder Ausgabe) machen muss.

stichwort [google]MVC[/google]

[quote=esskar,27.09.2006, 10:49]stichwort [google]MVC[/google][/quote]
Super, danke!

wobei MVC kein allheilmittel ist. da ich beim editor genau gleiches problem habe, kann ich ja mal aus nähkästchen plaudern: versuch nicht alles auf einmal umzustürzen und nur das was wirklich notwendig ist oder was für sicher geplantes wachstum notwendig ist. abstraktion wie MVC ist zwar wichtig grad weil man in anfangsphasen dazu neigt mit so wenig code wie möglich auszukommen und dann später abstrahiert.

spätestens dann einene moment mehr zeit nehmen zum nachdenken und dann auch ASAP alle codeteile die neue schnittstelle benutzen lassen(deswegen nicht zu vieler dieser umbauten auf einmal) damit man keine wartungsfallen fuer später baut.

auch abstraktionsschichten nie unabhängig vom tagesgeschäft aufbauen, willst ja eine app bauen kein framework. das heisst saubere grundstrukturen anfangen aber nicht bis ins letzte implementieren solang du es nicht brauchst.

hoffe das hilft und war nicht zu abstrakt.

wär auch dafür den thread aus spass und sinnloses zu bewegen denn dieses thema ist weder spass noch sinnlos :)\n\n

<!--EDIT|lichtkind|1159355026-->

Vielleicht noch ein anderer - zusätzlicher - Aspekt:
- Überleg mal welche Daten durch das Programm "fließen", vom Input zur DB zum Output und definiere dafür eine Datenstruktur/Objekt.
- Und auf welche "globaleren" Daten müssen die Programmmodule zugreifen und gibt es auch dafür eine geeignete Datenstruktur/Objekt.