Zurück   Flashforum > Flash > ActionScript > Softwarearchitektur und Entwurfsmuster

Antwort
 
LinkBack Themen-Optionen Ansicht
Alt 05-05-2009, 17:53   #1 (permalink)
Neuer User
 
Benutzerbild von JohnJohnson
 
Registriert seit: Oct 2004
Beiträge: 84
Architektur von sehr umfangreichen Projekten

Hello Gemeinde,

möchte die Frage hier grundsätzlich sehr allgemein halten:
Wie meint ihr sollte die Architektur eines sehr umfangreichen Projekts aufgebaut sein?
Das Augenmerk liegt dabei in erster Linie auf:
- Integration und Verwendung diverser open source Bibliotheken (3D- und Tweening-Engines, diverser Helferlein und Component-Sets etc.)
- Aufbau der Kernanwendung ist pureMVC konform
- Entwicklung durch ein Team von 6 und zu Spitzenzeiten mehr Flex-Entwicklern

Als ich das Projekt übernommen habe, hab ich grundsätzlich nicht schlecht gestaunt, was die Qualität des Codes betrifft - die Architektur hat mich aber, trotz durchaus jahrelanger Erfahrung, ziemlich vom Hocker gehauen. Ein Monolith aus gemerged'ten openSource-Bibs, openSource-Swc's, der pureMVC-Grundarchitektur und dann eben noch der umfangreichste Teil, die Eigenentwicklungen.

Nun gehts los mit der Planung von Refactoring und architectural re-design..
Mein Ansatz wäre nun:
- Grundsätzliche Teilung in eine interne Bibliothek (die mehrfach wiederverwendete UI-Komponenten und deren Basislogiken beinhaltet, quasi ne Interface-Sammlung mit grafischen Bausteinen)
- externe Bibliotheken, welche auch als autonome Library-Projekte in Flex angelegt werden - und in die Haupt-Applikation lediglich die generierten SWCs integrieren (habsch schon mal gemacht, ist ne ganz praktikable Sache bei Versionssprüngen..)
- Und schließlich die Applikation selbst, die letztlich code- und architektur-technisch zu angenommenen 90% brav in BestPractice-Manier aufgebaut ist

Recht viel mehr will ich hier auch gar nicht ausbreiten - das wäre jedenfalls meine grundsätzliche Überlegung. Vor dem Problem "Architektur umfangreicher Projekte" bin ich nun schon des Öfteren gestanden - kann aber über Google nix in Richtung BestPractice zu der Thematik finden. Vielleicht weil ich die falschen Suchbegriffe verwende? Koi Ohnung..

Würd mich jedenfalls freuen, wenns hier ein bisschen food for thought und Link- und/oder Literatur-Tips zu dem Thema hageln würde. Gibt doch sicher die einen oder anderen Flash- u. Flex-Gurus respektive -Evangelists auf dieser Welt, denen man (fast) bedingungslos glaubt, was das Thema betrifft - nicht?

Schönen Gruß,
JJ
JohnJohnson ist offline   Mit Zitat antworten
Alt 06-05-2009, 11:21   #2 (permalink)
thinkin aBout tha lib.
 
Benutzerbild von kaneda
 
Registriert seit: Nov 2001
Ort: Kölle
Beiträge: 1.379
Huff

Okay: ich hatte letztes Jahr eine Erfahrung der ähnlichen Art: Viel Code auf einem Haufen und im konkreten Fall keiner der noch wusste was wirklich wie zusammenarbeitet. Mal sehen ob ich was daraus gelernt habe:

Schritt 1: Alle Unklarheiten loswerden.

Du wirst in den nächsten Wochen von den Entwicklern über viele kleine Details informiert werden die nicht in Dokumentation( ASDoc oder sonstwo ) zu finden sein. Das meiste wird sich schätzungsweise im Deploy Prozess verstecken. Versuch diese Unklarheiten in automatisierte Prozesse(ANT, etc.) bzw. Dokumentation umzuwandeln sobald sie dir erzählt werden, dann hat die zukünfige Generation was davon und ihr könnt gemeinsam sicherstellen das du das auch verstanden hast.

Schritt 2: Konfiguration und Module trennen.

Wenn die Applikation gross ist empfiehlt es sich herauszukristallieren was denn jetzt Konfiguration (also Setup) und was ein Modul (manche setzen das gleich mit Klasse, ist aber selten nur eine) ist. Oft ist der Code sehr verworren weil es dependecies nach links rechts oben und unten gibt. Wenn die Module aber input parameter und output parameter haben die befüllt werden ist recht klar wer was wo braucht.

Schritt 3: Zusammenpacken von Modulen in eigene Deployprozesse.

Wenn du jetzt eine Applikation hast die nach Modulen aufgeteilt ist dann kann man darüber nachdenken kritische/statische Module auszugliedern in eigene Packages. Sehr empfehlen würde kann ich dabei .swc's zu verwenden. Auf die Art und Weise hat man pro sinnvollem deploy ein neues .swc - das muss irgendjemand mit einem build prozess anstarten und man weiss wo die dependencies sind.

Schritt 4: Tests

Manche hätten Tests jetzt ganz nach vorne geschoben, aber ich denke mir: Bis hierher solltest du noch keinen neuen Code geschrieben haben, einfach nur schrittweises auslagern - ein bischen refactoring hier ein bischen da ... Wenn du/irgendwer jetzt was neues einfügt dann muss das ja irgendwie passen und vor man sichs versieht geht wieder nix. Deswegen: Einen Test ausarbeiten: Mal zuerst ein geschriebenes .xml in dem steht welche Dinge denn alle getestet werden sollten bei einem deploy (liste mit punkten: das hier sollte man nicht vergessen zu prüfen). Man kann jetzt auch über unit tests nachdenken - aber das macht bei kleinen Modulen oft mehr sinn als bei der ganzen Applikation.

Schritt 5: Modulkonformität

Wenn du jetzt die Module ausgelagert hast und an ihnen arbeiten kannst: Schau das sie alle gleich aufgesetzt sind (pureMVC oder wie auch immer). Dann kannst du das Setup das du vorher erstellt hast deutlich reduzieren und du kommst zu einfacherem Setup besseren überschaubarkeit. Du kannst auch Module "wrappen" Sprich: Ein Modul referenziert auf Papervision und du hast einen Wrapper wo du intern nur auf den Wrapper verweist und niemals direkt mit papervision klassen arbeitest....


Das sind für mich jetzt mal so basisregeln sollt ich nochmal in die Situatio kommen - alles natürlich ein Lernprozess - nächstes mal bin ich sicher noch ein bischen klüger.
__________________
Back to community with http://leichtgewicht.at
kaneda ist offline   Mit Zitat antworten
Alt 08-05-2010, 15:37   #3 (permalink)
Neuer User
 
Registriert seit: May 2010
Beiträge: 87
ich weiß der Thread ist schon etwas älter.

Mich würde mal interessieren wie ihr das mit dem Refactoring, oder generell solche großen Projekten handhabt?
Bisher habe ich mit Flashbuilder gearbeitet. Das Refactoring ist mittlerweile zwar etwas besser geworden, aber FDT unterlegen (auch in anderen Bereichen weswegen ich jetzt erst mal bei FDT bleibe )

Bei FDT habe ich aber einerseits das Problem das ich gar nicht richtig weiß wie ich sinnvoll Library Projekte anlege, andrerseits das die Performance bei großen Flex-Projekten extrem in die Knie geht, so dass die Arbeit damit dann manchmal echt kein spaß macht.


Zu den Library Projekten:

Ich habe ganz normale AS3-Projekte die ich dann zu SWCs kompiliere. Jedes mal wenn ich eine Änderung an den Projekten mache kompiliere ich diese neu. Die anderen Projekte verwenden die SWCs als Linked Libraries. Damit hab ich dann schonmal Projekt-Übergreifendes Refactoring ziemlich zunichte gemacht. Letztendlich kommt es bei Refactorings an öffentlichen Methoden/Klassen zu sehr viel manueller Arbeit:

1. ich muss die SWC bauen.
2. ich muss es irgendwie schaffen das die Projekte die das SWC verwenden irgendwie ihren Index neu aufbauen. Ich habe da immer noch keine sinvolle Lösung gefunden ( siehe hier )
3. ich muss diese Änderungen nun mühevoll manuell anpassen.

Gibt es da vielleicht etwas sinnvollere Ansätze?


Zur Performance von Flex-Projekten:

Eines dieser Projekte hat recht viele MXML-Klassen die teilweise extrem aufgebläht sind. FDT kommt damit einfach nicht klar. Wenn ich da auch nur eine Zeile drin ändere warte ich oft Minuten auf Reaktion von Eclipse. Gibts da irgendwelche Tricks? Hilft es hier evtl. das Projekt in viele kleinere aufzuteilen?

Geändert von NilsK (08-05-2010 um 15:39 Uhr)
NilsK ist offline   Mit Zitat antworten
Alt 08-05-2010, 16:20   #4 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.357
Mein Workflow sieht so aus: das Projekt wird über Maven verwaltet. Der Maven Build ist Referenz und muss von allen Entwicklern vorm einchecken in das VCS einmal erfolgreich kompilieren. Maven erlaubt es zudem mit Modulen zu arbeiten. Das bedeutet ich habe schon Unterprojekte, die Library Projekten in Flash Builder entsprechen. Ausserdem kann ich bei konsequenter Arbeit mit Maven auch auf andere Projekt zugreifen, da die Artefakte (Kompilate in der Regel) in einem lokalen Repository abgelegt werden. Der Vorteil über die Kompilierung via Maven als Referenz Build hat ausserdem zu Folge, dass es nicht so leicht es, etwas kaputt zu machen und man schneller identifizieren kann, wer was verbockt hat.

Zudem ich arbeite ich mit IntelliJ IDEA. Ich kann so, eine Projekt das aus verschiedenen Modulen besteht (Maven Modulen) so konfigurieren, dass ich eine flache Sicht auf das Projekt habe. So kann ich sehr effizient mit den Sourcen umgehen und Projektweite Refactorings sind nicht erwähnenswert. Da ist der Support von IDEA glaube momentan der beste, den es gibt. Es ist quasi the best of both worlds.
Omega Psi ist offline   Mit Zitat antworten
Alt 08-05-2010, 16:39   #5 (permalink)
Neuer User
 
Registriert seit: May 2010
Beiträge: 87
Von Maven hab ich schon öfters gehört. Bisher habe ich immer gedacht das ich mit ANT auskomme, vielleicht ist es ja doch mal einen Blick wert :-)

Dieses IntelliJ IDEA werd ich mir auf jeden Fall mal anschauen.

Vielen Dank für die Anregungen.
NilsK ist offline   Mit Zitat antworten
Antwort

Lesezeichen

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks sind an
Pingbacks sind an
Refbacks sind an



Alle Zeitangaben in WEZ +1. Es ist jetzt 12:46 Uhr.

Domains, Webhosting & Vserver von Host Europe
Unterstützt das Flashforum!
Adobe User Group


Copyright ©1999 – 2014 Marc Thiele