Hi Slawa,
Anwenden dagegen ist komplizierter und es kommt immer auf den konkreten Fall an.
Das ist denke ich der wichtigste Satz, den Du hören wirst (zumindest der Richtigste). Deine eigentliche Frage kann man nicht genauer beantworten, denn es gibt zig Ansätze und Architekturen, die für ganz bestimmte Projekte/Probleme besser oder schlechter geeignet sind. Hier wirst Du auch kein Buch finden, dass Dir sagen kann wann was am Besten funktioniert. Das liegt nicht nur an der schieren Menge die Du hier unterbringen müsstest, ein Projekt verwendet i.d.R. auch gleich mehrere Architekturen für unterschiedliche Elemente. So kannst die Anwendung zwischen einem Client und einem Server unterscheiden, wobei beide Subsysteme wiederum einen eigenen, inneren Aufbau haben (das gilt dann auch für die Komponenten oder Module, aus denen sich jedes Subsystem zusammensetzt usw.).
Man muss sich eben überlegen wo man die Linie zieht, dabei kann man zB. beachten, wie etwas erstellt/geändert/released/versioniert/genutzt wird.
Auch hier stimme ich maki vollkommen zu. Allerdings würde ich hier noch einen wichtigen Aspekt ergänzen, man sollte die Größe im Auge behalten.
Ich denke einen wichtigen Punkt hast Du noch offen gelassen, so sagst Du, dass die Wartbarkeit deutlich leidet, aber schön wäre wenn Du auch erläuterst wie sich dies äußert.
Die wichtige Aufgabe des Projektmanagement besteht darin, dass man die Probleme von den Entwicklern fernhält. Und hierfür ist es unabdingbar, dass man stets einen guten Überblick und ein ausreichendes Verständnis hat. Die beiden Rollen (Entwickler und Projektleiter) haben dabei einen gegenläufigen Fokus. Der Entwickler muss ein Detailverständnis für die Komponente haben, an der er gerade arbeitet, braucht diesen aber nicht auf jede Komponente im Projekt. Die Leitung wiederum muss den Gesamtblick haben und schauen, dass alle Teile zusammenpassen, braucht aber keine Detailkenntnis was in welcher Klasse steht.
Die Projektorganisation ist ganz klar Aufgabe der Leitung. Die muss so aufgebaut sein, dass die Entwickler vernünftig arbeiten können (weil sie alles sehen, was sie benötigen), sie muss aber auch so sein, dass der Gesamtüberblick erhalten bleibt. Das Problem an Deiner Frage ist nun, dass die Granularität der Zerlegung (mehrere Workspaces, mehrere Projekte, mehrere (Sub-)Packages, mehrere Klassen) davon abhängt wie groß das Projekt an welcher Stelle ist.
Entwickelst Du z.B. eine Office Suite, so kann es sinnvoll sein, dass Du mehrere Projekte erstellst, die jeweils einem eigenen Projektleiter unterstehen und auch nicht zusammen in einem Workspace bearbeitet werden. Natürlich gibt es auch Gemeinsamkeiten (z.B. für den Austausch von Daten zwischen den Komponenten), die gehören natürlich auch in eingenes Projekt. Hier möchte ich nochmal klar sagen, ein Eclipse-Project im Workspace ist bitte nicht mit einem Projekt (im Sinne einer zu erstellende Software) zu verwechseln.
Auch für ein Projekt bietet es sich an, dass man prüft welche Elemente eine geeignete Größe haben um die noch sinnvoll überblicken zu können. Hast Du etwas in einer Größe, die Du für nicht mehr überschaubar hältst (z.B. ein Projekt mit mehreren hundert packages), dann sollte man hier klar eine Trennung vorsehen. Hier hilft erneut der Tipp von maki:
Man muss sich eben überlegen wo man die Linie zieht, dabei kann man zB. beachten, wie etwas erstellt/geändert/released/versioniert/genutzt wird.
Die Lebenszeit/Änderungsrate ist ganz entscheidend. Hast Du Komponenten/Subprojekte, die relativ unabhängig sind, dann sollten die auch entsprechend getrennt entwickelt werden. Hier ist es halt wichtig, dass man sich im Vorfeld Gedanken über sinnvolle Schnittstellen gemacht hat, die nun verbindlich sind. Durch die Verwendung von Mocks ist man hier auch unabhängig vom Entwicklungszyklus dieser getrennten Projekte. Das Vorgehen ist somit ganz analog zu einer fertigen Komponente/Bibliothek, die Du verwenden würdest, auch hier unterliegt die Entwicklung einem eigenen Team und zu jeder Version gibt es ein spezifisches API, gegen das Du programmierst.
Für kleinere Projekte kann es auch schon ausreichen, dass Du ein Eclipse Project für jede Schicht (Presentation, Service, Dao, Modell) erzeugst. Die Unterteilung ist hier einerseits möglich, da Du unterschiedliches Know how für die einzelnen Schichten benötigst (GUI Designer sind nicht immer die besten DB Experten und vice versa), noch wichtiger ist aber, dass die Änderungen in den Schichten ganz unterschiedlichen Zyklen unterliegen.
Was die Probleme angeht, die mit einer Änderung einher gehen, so gilt altbekannt: "Einen Tod muss man sterben". Um es mal klar zu sagen, nur bei einem Projekt, dass demnächst aufgelöst wird lohnt es sich mit schlechter Wartbarkeit zu leben. In jedem anderen Fall geht schlechte Wartbarkeit mit einer Minderung in Qualität und Effizienz einher und da relativiert sich schnell die Frage, ob man es sich leisten kann das Produkt umzustrukturieren und man muss sich frage, ob man es sich leisten kann es nicht zu tun.
Tatsächlich kann es sogar dazu kommen, dass die Refactorings so umfangreich ausfallen, dass man das Projekt neu schreibt. Das heißt aber nicht, dass man dies als Ziel haben sollte oder gelassen hinnehmen muss. Es ist normal, dass sich Änderungen in einem Projekt ergeben, die Auswahl der Architektur bestimmt jedoch dabei, wie weit sie sich auswirken. Deshalb ist eben auch die Planung wichtig, die hier getroffenen Entscheidungen bestimmen den Erfolg des Projekts.
