# Softwareentwicklung im Team



## Voltax (23. Aug 2011)

ich bin seit vielen Jahren als Java-Entwickler tätig, und frage mich immer mehr, ob wirklich alles so richtig ist, wie es ist. Mich würde interessieren, ob meine Vorstellungen von einer guten Vorgehensweise bezüglich Teamarbeit irgendwo da draußen tatsächlich so umgesetzt werden, wie ich mir das wünschen würde, oder ob ich völlig daneben liege: 

- ein großes Projekt lässt sich typischerweise in zahlreiche autonome Module aufteilen, die über vordefinierte Schnittstellen miteinander verbunden sind. Die Schnittstellen sind Teil der Projektarchitektur. Die Projektarchitktur sollte gut geplant sein, aber sich keinesfalls mit Implementierungs-Detail befassen, sondern ein stabiles Gerüst für das Zusammenspiel der zu implementierenden Module darstellen, und ein gesundes Maß an Erweiterbarkeit mitbringen.

- Architektur und Schnittstellen sollten von allen Projektbeteiligten wie selbstverständlich respektiert werden. Änderungen oder Erweiterungen an Architektur und Schnittstellen sollten nur vom Projektleiter bzw. Systemarchitekten unter Abstimmung mit allen beteiligten Modul-Entwickler vorgenommen werden. Wenn sich während der Projektentwicklung neue Ziele ergeben, oder die Kommunikation der Module untereinander erweitert werden muß, dann sollte das immer erst in die Gesamtarchitektur einfließen, und von dort dann in die Module. 

- Bei der Implementieung der Module haben die beauftragten Softwareentwickler Gestaltungsfreiheit. Wichtig ist nur die strikte Einhaltung der vorgegebenen Schnittstellen, termingerechte Fertigstellung, und möglichst fehlerfreie Funktion des Moduls. Auf diese Weise hat jeder Entwickler mit seiner Arbeit ein Stück von sich selbst in das Gesamtprojekt mit eingebracht. Man kann hunterher sagen: "diesen Teil habe ich gemacht", und stolz darauf sein. Zumindest für mich ist das eine sehr motivierende und erfüllende Vorstellung.

- wenn ein Programm-Modul eines bestimmten Entwicklers geändert oder erweitert werden soll, und dieser Entwickler im Team verfügbar ist, dann sollte eben dieser Entwickler auch die Änderungen implementieren dürfen. Falls aus zwingendem Grund doch ein anderer Entwickler die Arbeiten ausführen soll, dann sollte ein begleitender Dialog zwischen beiden Entwicklen stattfinden. Der ursprüngliche Entwickler sollte in jedem Fall eine "Patenschaft" für sein Stück Code behalten. 

In meiner augenblicklichen Realität ist wenig von meinen oben beschriebenen Wünschen zu finden. Enterprise-Projekte werden hier mithilfe eines kommerziellen Frameworks, zahlreicher OpenSource Frameworks, einem Ticketsystem sowie mündlichen Absprachen, auf Basis einer Versionsverwaltung realisiert. Insbesondere die Versionsverwaltung führt dazu, dass sich jedermann berufen fühlt, in jedermanns Code zu jeder Zeit herumzumatschen. Es werden bereits funktionierende Programmteile kommentarlos gelöscht und durch Code anderer ersetzt. Es werden Seiteneingänge und Querverbindungen ohne Nachfragen eingebaut, und bereits implementierte Konzepte umgangen. Ehemals sorgfältig gekapselter Programmgode wird aufgebrochen, bestehende Konzepte werden ignoriert, und in so etwas wie "Spaghetticode auf hohem Niveau" verwandelt, wo sich mitunter eine ganze Schar von Entwicklern mit jeweils ganz unterschiedlichen Philosophien haben durchsetzen wollen.

Fazit: Mein jetziger Arbeitgeber ist ausgesprochen erfolgreich! Folglich muß das unten beschriebene Vorgehen wohl das Richtige sein, und meine oben beschriebenen Vorstellungen sind wohl falsch.

Ist das überall so, wie wird bei Euch in der Firma Software im Team entwickelt?


----------



## maki (23. Aug 2011)

Würde das Problem ehrlich gesagt auf deiner Seite sehen.

Sowas wie "mein Code" bzw. "dein Code" hat eigentlich keinen Platz in einem echten Team, jeder muss auch Architekt, Programmierer und Tester sein, architetken die nicht programmieren sind imho fehl am platz.

Code, der zwar funktioniert aber ersatzlos gelöscht werden kann, muss auch gelöscht werden, ist dead code.

Agil eben...


----------



## Noctarius (23. Aug 2011)

Punkt 1: Richtig
Punkt 2: Sollte so sein, leider wissen in der Softwarewelt immer genug Leute immer alles besser  - Thema "Alle Wege führen nach Rom"
Punkt 3: Jein, die Gestaltungsfreiheit sollte sich im Rahmen der verwendeten Frameworks und Architekturstruturen bewegen. Es bringt nichts, wenn jeder in seinem Modul irgendwas irgendwie macht. Du wirst ja nicht ewig in der Firma sein und dein Nachfolger muss dann deinen "Erfolg" weitertreiben.
Punkt 4: Richtig - Alternative generelles Code-Review

Normal sollten bestimmte Module bestimmten Teams / Deparments zugewiesen werden. Ab einer gewissen Systemgröße kann kaum einer alles überblicken und alle Einzelheiten und Abhängigkeiten kennen. So handelt man sich mit kleinsten Änderungen schnell mal hässliche Fehler in vollkommen anderen Modulen ein.

Ob ein Arbeitgeber mit seiner Methode erfolgreich ist oder nicht würde ich spontan nicht am Softwareentwicklungsprozess ausmachen. Auch mit abstrusen Methoden lässt sich irgendwie Software entwickeln - aber eben nur irgendwie. Ob das dann wirklich effektiv ist oder resourcenfressend sei dahin gestellt.


----------



## Landei (23. Aug 2011)

Das "Rummanschen" in fremden Code geht völlig in Ordnung, *wenn*
- es gemeinsame Standards wie Style-Guides u.s.w. gibt
- ein Code-Review stattfindet

Ich habe festgestellt, dass wirklich "guter Code" dadurch auffällt, dass man darin kaum "Macken" seiner Autoren wiederfindet, und er dadurch zwar elegant, aber auch irgendwie "anonym" wirkt.

Leider ist das in meiner Firma nicht der Fall, und die ist damit auch nicht besonders erfolgreich (muss sie auch nicht, wir verkaufen hauptsächlich Glas).


----------



## Gonzo17 (23. Aug 2011)

Ich kenne das ähnlich, wobei ich jetzt in dem Fall nicht von Anfang an dabei war und deshalb die "Planungsphase" nicht erlebt habe. Man siehts aber an allen anderen Projekten/Produkten, wie das so generell abläuft.

Welches Problem da aber mit einem SCM aufkommt, kann ich nicht nachvollziehen. Der Code ist zwar möglicherweise für andere Leute auch einsehbar, aber wenn man wirklich darauf besteht, dass man als einzige Person daran arbeitet, dann macht man eben einen "lock" drauf. Finde ich jetzt weniger sinnvoll, ist aber auch sicherlich situationsbedingt. Auf jeden Fall sind dann die Probleme eher in der Umsetzung der Architektur bzw. noch früher beim Planen der Architektur. Gibt es keine Schnittstellen oder werden die einfach übergangen, dann kommt natürlich sowas dabei raus. Dann fummelt mal hier, mal da jemand in deinem Code rum, damit sein Stückchen Code funktioniert. Leider viel zu oft gesehen. Das macht die Software nicht wartbar und auch sehr fehleranfällig.

Letztlich ist es aber so.. wenn die Software funktioniert, interessiert es Vertrieb, Marketing und Chefs relativ wenig, wie das passiert ist. Kommen die ersten Fehler, heißt es dann "Das hat doch mal funktioniert!" und "So schwer kann das doch nicht sein, einfach hier etwas ändern.", das entspricht aber nie den Tatsachen. Falls wirklich viel Druck von allen Seiten kommt und man "gezwungen" wird, schnell Lösungen zu präsentieren, dann kann sowas eben mal passieren, da überspringt man die Planungsphase und macht einfach das, was einem so am besten gefällt. Als Entwickler spielst du das Spiel entweder mit und wirst dich darauf einstellen können, dass das immer so sein wird, oder du stellst dich erstmal quer und stellst Bedingungen auf, denn GUTE und erweiterbare Software kann man eben auch nicht herzaubern, das Bedarf vieler Überlegungen.


----------



## Noctarius (23. Aug 2011)

Landei hat gesagt.:


> Ich habe festgestellt, dass wirklich "guter Code" dadurch auffällt, dass man darin kaum "Macken" seiner Autoren wiederfindet, und er dadurch zwar elegant, aber auch irgendwie "anonym" wirkt.



Das würde ich so unterstreichen. Ist schöner ausgedrückt als "im Rahmen der Architekturvorgaben"


----------

