Empfehlenswerte Softwarearchitektur Schulung

[Diablokiller999]

Hi Leute!
Ich suche schon länger nach einer guten Schulung für Softwarepatterns/Architektur um alle Entwickler in der Firma mal auf ein Level zu hieven. Gibt da ja Anbieter wie Sand am Meer, leider weiß man vorher nie wie gut die sind und da kommt ihr ins Spiel
Könnt ihr Unternehmen/Personen für sowas empfehlen? Mit wem habt ihr gute Erfahrungen gemacht?

 

[usbstick]

Mit Softwarepatterns meinst Du Entwurfsmuster (Design Patterns) und mit Softwarearchitektur meinst Du Systemdesign nehme ich an?

Falls ja: Das braucht mindestens zwei Schulungen, weil es komplett unterschiedliche Themen sind.

Davon abgesehen sind das Dinger, die man jeweils kaum in 1-3 Tagen lernt, wenn es über die absoluten Minimalgrundlagen hinausgehen soll. Da ist die Frage dann was Du erreichen willst, da Schulungen recht schnell extrem teuer werden, und gleichzeitig die Qualität wie auch der Nutzen massiv variieren. Gerade bei einem Thema wie Design Patterns, was manche ihr Leben lang nicht richtig lernen. (Weil es im "Industrieeinsatz" eben häufig auch ohne geht, da die Devise vieler Unternehmen leider ist: "Hauptsache es läuft, egal wie. Hauptsache es wird schnell fertig.")

 

[Toms]

Ich kann empfehlen den Zertifizierungspfad der CPSA ISAQB zu gehen. Der besteht aus zwei Leveln (Foundation und Advanced) und gerade das Advanced Zertifikat ist richtig anspruchsvoll mit großen Curriculum und besteht auch nicht jeder

 

[Diablokiller999]

Mit Softwarepatterns meinst Du Entwurfsmuster (Design Patterns) und mit Softwarearchitektur meinst Du Systemdesign nehme ich an?

Tatsächlich eher Design Patterns, da wir ein bunter Haufen Programmierer mit unterschiedlichen Ausbildungen sind (Ausbildung, Studium, Seiteneinsteiger) und ich hier alle erstmal auf einen Wissensstand bringen will, was es für Patterns gibt, wie man Anwendungsfälle entdeckt etc.

Systemarchitektur muss bei uns nicht jeder können, reicht wenn ich das als Systems Engineer mache

 

[DoNG]

Falls ihr Visual Studio einsetzt und eine MSDN Subscription habt, da sind Pluralsight Kurse inkludiert. Da kann man schon Mal reinschauen.

 

[usbstick]

Tatsächlich eher Design Patterns, da wir ein bunter Haufen Programmierer mit unterschiedlichen Ausbildungen sind (Ausbildung, Studium, Seiteneinsteiger) und ich hier alle erstmal auf einen Wissensstand bringen will, was es für Patterns gibt, wie man Anwendungsfälle entdeckt etc.

Also … ich bin sicher nicht die letztgültige Instanz für diese Frage, allerdings wäre da mein Ansatz, es mit regelmäßigen internen Seminaren anzugehen. Die von @Toms geposteten Zertifikate sind sicherlich in Summe schonmal besser als so typische Weiterbildungen von 1-2 Tagen, aber sie kosten Dich in Summe dann für ein mittelgroßes Team auch schnell >10k/Entwickler plus die Arbeits- und Vorbereitungszeit.

Was in meinem Team recht gut funktioniert hat, weil es (leider nur zeitweise) aus ausschließlich motivierten Leute bestand, war ein regelmäßiges Seminar (1x pro Sprint) in dem die eigene Arbeit jenseits des Sprint-Review mit einem Fokus auf die genutzte Technik sowie die Architektur vorgestellt wurde. Die Pflicht zu präsentieren wurde durchrotiert und es gab keine Bewertung sowie die Möglichkeit zum Schieben wenn es mal nicht passte.

Die Präsentation war dann zwischen 20 und 60 Minuten mit detailliertem Blick in den Code inklusive Erläuterungen warum wieso und weshalb plus ständige Diskussionen, die das ganze dann auf bis 3h+ gezogen haben inkl. gemeinsam Essen bestellen und weitermachen. Genau an der Stelle wurde dann eben auch die Theorie im Hintergrung erklärt, welche Design Patterns genutzt wurden, welche interessanten Tricks, warum … usw. (je nachdem wie sehr der Inhalt von den Vorkenntnissen der anderen abwich) … während gleichzeitig alle anderen ihre Verbesserungsvorschläge und Ideen eingeworfen haben.

Für das Teamgefühl eine super Sache wenn man das richtige Team hat. Für die Weiterentwicklung auch, und deutlich günstiger. Es hängt nur sehr daran, dass man die richtige Mischung von Leuten im Team hat, die auch Bock darauf haben sich gegenseitig Dinge beizubringen und das auch auf einem theoretischen Level.

 

[Ack der III]

Von einer Schulung zu Design Patterns würde ich auch abraten, da diese im Grunde nur eine Sammlung von Fallbeispielen sind. Hier würde ich empfehlen, dass ihr euch eine Liste der häufigsten Design Patterns raussucht und jeder dann jeweils ein Pattern bearbeitet und vorstellt. Idealerweise sogar praxisbezogen an eurer Anwendung mit anschließender Diskussion.

Wichtig zu Design Patterns ist aber folgendes: Der häufigste Fehler ist, dass diese falsch herum angewendet werden. Sprich: Jemand lernt programmieren, stellt fest, dass er nur mühselig Code schreiben kann, sucht nach Hilfe, entdeckt Design Patterns, findet diese hilfreich und stopft dann seinen Code mit so vielen Patterns wie möglich voll. Das mag eine schöne Übung sein - vor allem zur Horizonterweiterung, was man für Konstrukte mit Programmiersprachen bauen kann - erzeugt aber einen hoffnungslos über-komplexen Code.

Die Idee hinter Design Patterns ist, den "Mental Load" zu reduzieren. Also jemand schreibt Code und stellt dann fest, dass dieser Code einem Pattern entspricht. Daher benennt er diesen Code nach dem Pattern. Dies erlaubt dann einem anderen Entwickler sofort zu erkennen, was dieser Code macht und muss diesen nicht erst auf seine Funktion hin analysieren.

Wenn ich eine Schulung empfehlen soll, dann zum Thema DDD und CQRS.

Der häufigste Fehler in der Softwareentwicklung ist, mit dem Datenbankmodell anzufangen - vielleicht sogar weil dieses schon vorhanden ist - und daraus sein Klassen/Objektmodell abzuleiten. Vielleicht sind sogenannte Objekt-Relationale-Mapper bekannt. Hier ist die Richtung das entscheidende: Objekt --> Relational. Es gibt aus guten Grund keine Relational-Objekt-Mapper. Daher sollte man es auch vermeiden mit dem Datenbankmodell anzufangen.

DDD oder Domain Driven Design verfolgt diesen Ansatz. Die Idee ist, dass man die Anwendungsdomäne (auch Fach- oder Geschäftslogik) in Isolation, also ohne technische Abhängigkeiten zu verwendeten Datenbanken, GUI, Web oder sonstigen Frameworks, entwickelt und diese dann erst im Anschluss andockt.
Das erlaubt den Entwicklern sich auf die optimale Abbildung der Geschäftsregeln zu konzentrieren.

DDD ist natürlich ein großes Feld, aber schon die Grundlagen erleichtern die Entwicklung massiv. Dafür reicht es zu wissen, was die vier grundlegenden Typen von Objekten in der Anwendungsdomäne sind: Entities, Object-Values, Services und Repositories.

CQRS steht für Command Query Responsibility Segregation und hilft bei der Persistenz des Datenmodells und ist im Grunde ein "fancy" Name für "Es gibt zwei Datenmodelle: Eins zum Lesen (Query) und eins zum Schreiben (Command)". CQRS beerbt das klassische CRUD (Create Read Update Delete), bei dem es vier Methoden gibt, jeweils eine um einen Datensatz zu erstellen, zu lesen, zu ändern und zu löschen. Problematisch bei CRUD ist die Update-Methode. Übergibt man ein Objekt an diese Methode, weiß der implementierende Code nicht, was sich an dem Objekt geändert hat. CQRS hilft hier aus, indem man die Gründe für eine Änderung an einem Objekt als separate Methoden realisiert. Soll zum Beispiel bei einer Bestellung etwas geändert werden, gibt es nach CRUD nur eine updateOrder(order)-Methode. Diese weiß aber nicht, was sich geändert hat und ist daher schwer zu implementieren. Nach CQRS gibt es für jeden Änderungsgrund eine eigene Methode: persistDeliveryAddressChanged(orderNumber, deliveryAddress), persistOrderLineChanged(orderNumber, orderLine) etc. Die Implementierung der einzelnen Methoden ist dann trivial.

Eine konkrete Schulung kann ich leider nicht empfehlen, aber ich denke mit einer Grundlangenschulung zu DDD kann man nichts falsch machen. War diese gut, kann man darauf aufbauend tiefer in DDD einsteigen.

 

[Raijin]

Die Problematik bei Design Patterns ist, dass man ihren Nutzen erst dann wirklich erkennt, wenn man einen realen Anwendungsfall hat. Die Schulungsbeispiele sind bei sowas meistens wenig hilfreich. Sie zeigen zwar das Prinzip in minimaler Form, aber let's face it, 90% der Kursteilnehmer denken sich dabei doch "Ja ok, kann ich aber auch anders machen, so wie ich es immer mache". Erst dann, wenn man in der Praxis vor einer Problematik steht, die sich mit Pattern X viel schlanker und eleganter lösen lässt als mit der bisherigen 08/15 Methode, erkennt man den wahren Sinn eben dieses Patterns.

Deswegen sind pauschale Schulungen oftmals nur wenig effektiv, weil man das Gelernte nicht selten schon wieder vergessen hat, wenn man dann irgendwann mal vor einem sinnvollen Anwendungsfall steht. Bevor ihr euch eine externe Schulung raussucht, solltet ihr vielleicht erstmal intern abgleichen welche Techniken ihr bisher einsetzt und welche unter den Kollegen noch so bekannt sind bzw. welche Verbesserungsvorschläge es dazu ggfs gibt. Ausgehend davon könnt ihr im Idealfall eine gezieltere Schulung organisieren, die ganz bestimmte Themenbereiche und Design Pattern abdeckt, welche für eure Zwecke besser geeignet sind als andere. Womöglich stellt sich sogar heraus, dass ihr eine interne Schulung anberaumen könnt, weil einer der Kollegen sich in diesem oder jenen Bereich bereits sehr gut auskennt, es bisher nur nicht wirklich anbringen konnte.