Womöglich fragst du dich hin und wieder, warum du eigentlich in einem “Team” arbeitest?! Es arbeiten zwar alle an einer Software, aber doch irgendwie jeder für sich. Jeder baut seinen Teil des Systems, hin und wieder mal mit Unterstützung oder vielleicht auch mal im Pair. Strukturen wachsen organisch mit jedem eingebauten Feature. Du kennst deinen Teil vom System, im Rest musst du hoffentlich nicht arbeiten. Ich vermute diese Arbeitsweise ist jedem Entwickler bekannt. Mehr noch, sie ist das gewohnte Bild.
Ich plädiere für eine andere Vorgehensweise im Team, in der Abteilung, in der Softwareentwicklung allgemein. Ich plädiere für den Entwurf einer Lösung vor der Implementation. Und das im Team. Das Team ist der ideale Ausgangspunkt für Flow Design Entwürfe. Die gemeinsame Entwurfsphase wirkt sich nicht nur auf die Qualität der Lösung, sondern auf die gesamte Arbeitsweise aus.
Vorteile für den Quelltext
Ich beginne mit den offensichtlichen Vorteilen.
Verantwortlichkeit! Ein Zauberwort unter den Prinzipien. SRP und IOSP befassen sich beispielsweise damit, und sind das Fundament guter Codestruktur. Ich höre häufig und teile die Erfahrung: “Ich schreibe erst die Lösung, egal wie. Wenn es läuft wird aufgeräumt”. Dabei passiert es schnell, dass vermischte Verantwortungen übersehen werden. Im gemeinsamen Entwurf können wir die Prinzipien schon vor der eigentlichen Programmierung anwenden. Unterschiedliche Aspekte werden schnell erkannt und bereits vor der Umsetzung voneinander getrennt.
Struktur! Entwerfen wir eine Lösung bevor wir sie implementieren, haben wir bereits eine Struktur. Wir müssen bei der Implementierung keinen Gedanken daran verschwenden, welche Klassen wir brauchen, ob sie beim aktuellen Stand vollständig sind oder ein anderer Name sinnvoll ist, ob sie statisch sind oder Zustand halten,… all das wurde bereits geplant. Im Team. Klassen, Methoden, Zustandsvariablen, Parameter, alles was wir brauchen ist bekannt. Die Struktur steht, wir müssen nur noch abschreiben und können uns auf die technischen Details konzentrieren. Fast schon langweilig.
Tests! Wenn wir schon abschreiben, können wir es gleich richtig machen. Test-First? Kein Problem. Der Entwurf liefert uns die Signaturen der benötigten Methoden, Datenstrukturen und Klassen. Die perfekte Vorlage für eine Testsuite. Wir können sämtliche Klassen und Methoden schon unter Test stellen, bevor wir sie selbst schreiben. Um Tests müssen wir uns also viel weniger Gedanken machen.
Lesbarkeit! Ist Teamarbeit. Befassen wir uns gemeinsam mit der Ausprägung von Methoden und Klassen, entwickelt sich üblicherweise eine angemessene Benennung. Einem Entwickler allein fehlt gelegentlich die Inspiration für einen Methodennamen. Im Team kann und soll diskutiert werden, bis alle zufrieden sind. Der Flow Design Entwurf fördert lesbare Signaturen. Der Lösungsweg wird von den Details der Implementierung getrennt. Das Augenmerk liegt darauf, was eine Methode tut, nicht wie.
Konsens! Hast du dich schon mal mit Code von anderen Entwicklern befasst und mindestens innerlich geflucht? Über die Art der Lösung, die Lesbarkeit, die Struktur, die Interfaces oder die Tests? Viele Wege führen nach Rom, doch einige sind steinig. Entwürfe helfen, Lösungen gemeinsam zu finden. Jede Diskussion trägt zur letztendlichen Lösung bei. Auf dem Weg dahin können alle entstehenden Uneinigkeiten ausgehandelt werden. Die Qualität der Lösung steigt auf der einen Seite, auf der anderen Seite steigt die Akzeptanz.
Vorteile für die Arbeit im Team
Nehmen wir einmal an, wir befinden uns als Team am Anfang eines Sprints. Wir haben unseren Katalog von Anforderungen, die bis Ende der Iteration im Bestfall fertiggestellt werden sollen. Was sind unsere Optionen? Jeder könnte allein oder im Pair an einer Anforderung arbeiten. Die Alternative ist, dass alle gemeinsam an einer Anforderung arbeiten und den Katalog Stück für Stück abarbeiten. Und ja, man kann zu viert sinnvoll an einer Anforderung arbeiten. Entwürfe bilden dafür die Grundlage.
Kontrakte! Haben wir eine Anforderung entworfen, können wir zu den daraus entstandenen Daten- und Klassenstrukturen Kontrakte bilden. Wir können ein Paket bereitstellen, welches die Datenstrukturen enthält. Dazu Interfaces, die wir aus den entworfenen Klassenstrukturen und Methoden extrahieren.
Arbeitsorganisation! Mit Entwurf und zugehörigen Kontrakten lässt sich die Arbeit für eine Anforderung spielend auf mehrere Entwickler verteilen. Jeder kann unter Einsatz der bereitgestellten Kontrakte seinen Teil der Anforderungen unabhängig von den anderen umsetzen. Verteilte Implementation, natürlich inkusive Tests. Anschliessend werden alle Teile – und hier der Clou – problemlos(!) zusammengeführt und integriert.
Skalierbarkeit! Ergibt sich aus den beiden vorgenannten Punkte. Stellt euch vor, ihr habt eine Anforderung, die einen sehr hohen Wert für den Product Owner hat. Sie soll so schnell wie möglich produktiv gehen. Auf Qualität zu verzichten ist keine Option und üblicherweise auch keine Beschleunigung des Prozesses. Also muss der Prozess verteilt werden. Ein geschultes Pair ist schneller als einer allein. Warum dann nicht gleich vier Personen oder mehr daran setzen? Sicher hat auch die Parallelisierung ihre sinnhafte Grenze, je nach Größe der Anforderung. Doch es lohnt sich, diese Grenze auszureizen.
Clean Code Trainings
Geschlossene Firmenkurse
Wir führen alle Seminare als geschlossene Firmenkurse für Sie durch.
Bei Interesse oder Fragen kontaktieren Sie uns gerne.
Vorteile für die Wissensverteilung
Domänenkenntnis! Alle, die am Entwurf einer Lösung teil haben, kennen im Anschluss die Lösung und die Anforderungen. Unabhängig davon, ob sie an der tatsächlichen Implementation beteiligt sind. Unbekannte Flecken in der Software werden minimiert, das Wissen um die Domäne steigt. Was dabei herauskommt, ist eine größere Bekanntheit des Ganzen bei gleichem Arbeitsaufwand für jeden einzelnen. Sollte im Team mal ein Personalwechsel stattfinden, geht nicht gleich Wissen um die Dömäne verloren. Wir erhalten eine höhere Ausfallsicherheit.
Domänensprache! Gemeinsame Kommunikation über die Domäne fördert die Entwicklung einer Domänensprache. Das Vokabular bildet sich aus und wird genutzt. Das schlägt sich auf den Quelltext nieder und im Austausch untereinander. Ein gemeinsames Verständnis wächst und verteilt sich. Das Domain Driven Design benutzt dafür den Begriff Allgegenwärtige Sprache oder Ubiquitous Language. Und eben diese wird in Entwurfsphasen ausgeprägt und in Quelltext übersetzt.
Codekenntnis! Die Implementation spiegelt den Entwurf. Dieses Prinzip ist unbedingt einzuhalten. Es garantiert, dass das erarbeitete Wissen im Code wiederzufinden ist. Es gibt zahlreiche Situationen, in denen ein Entwickler im Quelltext eines anderen arbeitet. War er am Entwurf für diese Implementation beteiligt, wird er sich im Quelltext zurechtfinden und wohl fühlen. Die Codebasis ist ein offenes Buch. Daraus resultiert weniger: “Oh, den Kram hier kenn’ ich gar nicht und jetzt soll ich hier einspringen?” und mehr: ”Stimmt, so hatten wir das gelöst. Na dann weiß ich ja wo ich weitermachen kann.” Im Code Review sollte daher explizit darauf geachtet werden, ob das Prinzip eingehalten wurde.
Kommunikation! Gemeinsame Arbeit fördert die Kommunikation. Meiner Erfahrung nach gibt es Entwickler, die eine ausgeprägte Tendenz haben, Kommunikation zu meiden. Vor allem, wenn sie an einer Lösung basteln. Ich zähle mich selbst dazu. Das Knobeln und Puzzeln an einer Lösung hat mich schon das ein oder andere Mal zögern lassen, frühzeitig mit jemand anderem die Problematik zu teilen. Selbst in ratlosen Situation schien es mir naheliegender zu forschen, bis ich einen Weg gefunden habe, als meine Teamkollegen zu informieren. Das Ergebnis war häufig ein Erfolg, der mehr Zeit gekostet hat als nötig. Manchmal ein Misserfolg, den ich deutlich später öffentlich gemacht habe als gut gewesen wäre. Solche, wirklich unangenehmen, Situationen entstehen deutlich seltener, wenn der Lösungsweg gemeinsam bestritten wird. Die Knobeleien in der Implementation eines Entwurfs sind übersichtlich. Und sollte bei der Umsetzung doch noch eine Hürde auftauchen, kann man das Team zusammenrufen und diesen Teil noch einmal im Entwurf verfeinern.
Kontinuierliche Verbesserung! Entwürfe tragen zur kontinuierlichen Verbesserung bei. Entwickler mit wenig Erfahrung profitieren enorm von der Beteiligung am Lösungsprozess. Ob in Ausbildung, mit zwei oder zehn Jahren Erfahrung, alle lernen in Entwurfsphasen. Das macht sich bemerkbar. Mit der Zeit gehen Entwürfe schneller und leichter von der Hand. Ein geschultes Team entwickelt Standards oder Patterns, bestimmte Vorgehensweisen für bestimmte Herausforderungen. Diese Patterns prägen sich ein. Gemeinsam eine Lösung für eine komplexe Anforderung zu erarbeiten, prägt sich ebenso ein.
Erhalte einen Auszug aus dem Buch „Mit Flow Design zu Clean Code“.
Fazit
Ein Flow Design Entwurf hilft, eine gute Lösung für eine Anforderung zu schaffen. Die Entwurfsphase als fester Bestandteil des Entwicklungsprozesses, gerade im Team, bietet so viel mehr. Die Arbeit im Team verändert sich deutlich. Der Entwurf bringt Struktur und Qualität in den Quelltext. Die Entwurfsphase bringt Struktur und Qualität in das Team. Hört sich gut an? Finden wir auch. Daher beschäftigt sich unser offenenes Training Clean Code Developer Advanced genau mit dieser Thematik.
German 
English