Management der Architekturerosion während der Entwicklung

Zusammenfassung

Zusammenfassend kann gesagt werden, dass verschiedene Diskussionsräume hilfreich sein können. Vor Beginn einer Story sollte mit mindestens einer weiteren Person ein möglicher Lösungsweg erarbeitet werden. Das Daily Meeting kann frühzeitig genutzt werden um Proble-men anzusprechen. Das Problem selbst sollte nicht bei diesem Treffen diskutiert werden. Dieses würde dadurch unnötig in die Länge gezogen werden. Außerdem sind viele Personen anwesend, die nicht zur Lösung beitragen können und stattdessen nur von der Arbeit abgehalten werden.

Um über den aktuellen Zustand der Architektur zu reden ist ein dediziertes Meeting sehr wertvoll. Hier können geplante Änderungen, die nicht in Zusammenhang mit einer Story stehen, besprochen werden. Außerdem kann dieses Meeting für eine Art von Retrospektive, bzw. Review für die Architektur eingesetzt werden.

Der teamübergreifende Austausch zu Schnittstellen sollte nicht genauer geregelt werden.

Hierzu sind die Teams und Projekte meist zu individuell. Individuell angesetzte Absprachen könnten hier die passendere Lösung sein. Ein weiterer teamübergreifender Austausch, im Rahmen einer festen Vortragssituation, ist wichtig für eine Wissensverbreitung. Die Themen sind meist allgemein und helfen dadurch nicht zwingend bei einem konkreten Problem. Sie können aber den Einstieg in eine neue Technologie vereinfachen und neue Ideen schaffen.

Unternehmen Tests CI-P

lattform statische

Co deanalysen

Conformence Che

cks

Pair Pr

ogramming

Co de

Re vie

w

Weiter es

A X X X X - Zwei-Stufiges Code Review

- Approaches und Proposals - Technical-Debt Tickets

B X X X X X

C X X X X X

D X X X X

E X X X X

F X X X X X - Story Verantwortlicher

G X X

H X X X X - Todo-Board

Ø 8/8 4/8 5/8 2/8 8/8 7/8

Tabelle 5.3: Maßnahmen während der Entwicklung

nur, wenn du alles automatisiert testen kannst.“ [E, 34:55min]. Bei einigen Unternehmen werden Features ohne Umweg direkt auf das Produktivsystem (G) übertragen. Deswegen geht bei ihnen„kein Feature rein, was nicht getestet ist“ [F, 25:05min]. Bei Unternehmen G geht dies soweit, dass diese sogar nach dem Test-First Prinzip arbeiten. Unternehmen H stimmt ebenfalls mit dieser Einstellung überein:„Testabdeckung ist eines unserer wichtigsten Sicherheitsnetze die wir haben“ [H, 31:51min]. Dies ist wichtig, weil„ein System wird viel leichter refaktorierbar.

Die Leute haben viel mehr Mut zum refaktorieren.“ [H, 32:31min]. Die Entwickler sollen sicher sein, dass sich durch ihre Änderungen die Funktionalität der Anwendung nicht geändert hat.

Der Interviewpartner aus Unternehmen B ist etwas kritischer. Er habe„im Arbeitsalltag noch keine Projekte gesehen, wo der Code so gut strukturiert war, dass [er] etwas refaktoriere und den Test als Beweis hernehmen kann, dass alles funktioniert“ [B, 41:55min]. Hiermit ist gemeint, dass bei vielen Änderungen die Tests so nah am Code sind und deshalb ebenfalls angepasst werden müssen. Dadurch können diese nicht immer eine vollständige Sicherheit darstellen.

Auch wenn die Tests angepasst werden müssen ist es aber möglich unerwünscht Seiteneffekte durch andere Tests festzustellen.

Viele Unternehmen führen die Tests und weitere Überprüfungen automatisch mithilfe von Continuous Integration Plattformen(CI, z.B. Jenkins¹) durch. Diese Tools werden häufig zur Berechnung weiterer Metriken eingesetzt. In den meisten Fällen sind Richtlinien vorhanden die bei einer Unterschreitung verhindern, dass eine Story abgeschlossen werden kann. In Unternehmen B werden diese bewusst nicht eingesetzt. Der Interviewpartner ist der Meinung,

„dass die Entwicklungsgeschwindigkeit und die Mentalität der Entwickler“ [B, 36:21] dadurch negativ beeinflusst wird. Die Entwickler würden die Tools irgendwann so gut kennen, dass nur für diese entwickelt würde. Das Ziel guten Code zu erzeugen würde in den Hintergrund geraten.

Das Unternehmen setzt solche eine Prüfung zwar ein, hat aber keine Richtlinien für Minimal-bewertungen festgelegt. Da der Einsatz einer CI-Plattform sehr unterschiedliche Prüfungen und Richtlinien einführen kann, ist es sehr schwierig diese Aussagen direkt zu vergleichen. Der Interviewpartner aus Unternehmen G empfindet eineCheckstyle-Prüfung z.B. als sinnlos, eine Erkennung von potentiellen Bugs teilweise aber hilfreich. Eine CI-Plattform kann statische Codeanalysen durchführen. In einigen Fällen werden hierzu zusätzliche Werkzeuge verwendet.

H nutzt so etwas sporadisch in andern Projekten. Die Interviewpartnerin würde sich dies häufi-ger wünschen. Trotzdem ist sie der Meinung:„Wenn man die Leute auf Qualität trainiert, dann sehen die auch was komisch ist.“ [H, 30:47min]. Dadurch sind sie„mit ihren Augen die besten Bug-Detektoren“ [H, 30:44min]. Unternehmen B setzt etwas ein, dass„über diverse Metriken mitteilen [kann], ob ein Stück Code überarbeitungsbedürftig ist“ [B, 35:02min]. Zum Teil werden die Ergebnisse nicht als relevant genug betrachtet, weil gesagt wird, dass es Bugs gibt,„wo man weiß, den gibt es seit drei Jahren, [es] stört keinen wenn der noch weitere drei Jahre existiert“ [B, 41:08min]. Zur statischen Analyse haben einige Teams selbstständig Sonarqube eingeführt. Bei Unternehmen E wird dies zur regelmäßigen Prüfung des aktuellen Stands genutzt. Als während der Entwicklung von der fachlichen Seite weniger zu tun war, konnte„30% [der] Zeit im Sprint auf das Abarbeiten von Sonar-Tickets“[E, 31,23min] konzentriert werden. Unternehmen C plant für diese Art von Refaktorisierungen durchgehend 20% der Zeit ein. Die anderen Unternehmen haben hierzu keine Regelungen. Wenn größere Änderungen notwendig sind, werden diese aber in der Regel von einem Teil des Teams neben der Entwicklung von Features durchgeführt.

Conformance Checks werden nur selten eingesetzt. Unternehmen C hat Versuche hierzu durchgeführt, war aber mit den starren Regeln nicht zufrieden. Der Interviewpartner testete zum Zeitpunkt des Interviews ein weiteres Werkzeug (Moose). Unternehmen H führt mit Sonargraph regelmäßig ausführliche Architekturanalysen durch. Die Interviewpartnerin nennt dies„Mob-Architecting“ [H, 35:52min]. Hier nimmt das gesamte Team teil. Sie sagt:„Das ist so ein Boost im Teamverständnis und im Architekturverständnis, dass kriegt man kaum anders

1https://jenkins.io/, Abgerufen: 2.11.2016

hin“ [H, 36:08]. Der Effekt beschränkt sich nicht nur auf die Architektur, sondern hilft auch beim Zusammenhalt des Teams. Die Analysen führt sie ebenfalls in andern Teams und in anderen Unternehmen durch. Unternehmen D sieht diese Art von Analyse eher kritisch und bezeichnet es als ein„Sterben in Schönheit nach irgendwelchen Prinzipien“[D, 26:13min]. Die Reaktionen nach einem Versuch in diesem Unternehmen waren„totaler Widerstand oder es war nett, dass wir drüber geredet haben. Ja ein paar Punkte nehmen wir mit.“ [D, 25:38min]. Ein festgestelltes Problem dabei ist, dass nicht sicher gegangen werden kann, dass die verglichene Ist-Architektur noch das richtige Ziel darstellt. Diese Art von Analyse bewirke laut H oftmals, dass viele Leute das erste Mal den wirklichen Aufbau der Anwendung zu sehen bekommen.

Die anderen Unternehmen konnten von keinen Versuchen in dieser Richtung berichten.

Unternehmen G setzt die meisten Werkzeuge nur temporär ein:„Wir setzten Tools ein wenn wir ein Problem haben und wenn das Problem weg ist, setzten wir auch das Tool wieder ab.“ [G, 44:35min]. Der Interviewpartner sagt zu solchen Prüfungen:„Das ist nichts was uns vor irgend-einem Schaden [...] retten würde.“ [G, 44.25min]. Dies passt zu der Aussage, dass dem Kunden beigebracht werden muss, „dass es normal ist, dass man immer mal ein bisschen reparieren muss“ [H, 31:29min]. Bei Unternehmen G wird dies zusätzlich damit begründet, dass jedes Werkzeug den Buildprozess verlängern würde.

Die zuvor angesprochenen Vorgehen behandeln Analysen die meist unabhängig oder nach Beendigung einer Story durchgeführt werden. Im Folgenden wird untersucht, was zum Zeit-punkt der Entwicklung eingesetzt wird.

Alle besuchten Unternehmen setzten Pair Programming ein. Dies wird als Mittel der Wahl zur Einarbeitung von neuen Mitarbeitern angesehen. Dadurch wird ihnen schrittweise ein Einblick in das System gegeben. Bei allen wird Pair Programming auch„bei etwas schwierigeren Situa-tionen benutzt“ [B, 19:29min]. Hier werden Kollegen zur Lösung eines konkreten Problems um Hilfe gebeten. Bei Projekten mit mehreren Teams setzt Unternehmen B dies auch zwischen den Teams ein. Wenn z.B. eine Komponente des anderen Teams verwendet, bzw. angepasst werden muss. Die Unternehmen G und H setzen„auf täglicher Ebene Pair Programming“ [G, 16:52min] ein. Selbst bei der Entwicklung durch einen Architekten wird keine Ausnahme gemacht,„weil sonst ist er dort Know-How Träger und das alleine nur er“ [H, 22:47min]. Da aber dieses Vorgehen gerade„das Wissen verbreitern und andere Meinungen mit rein [zu] holen“ [G, 22:14] soll, ist dies nicht gewünscht. Wenn die Entwicklung einer Story länger als drei Tage dauert, wird in beiden Unternehmen eine Person ausgewechselt, um neues Wissen und einen anderen Blickwinkel in das Team zu bekommen.

Nach der Entwicklung setzten bis auf Unternehmen G und C, alle Unternehmen Code Reviews ein. Bei Unternehmen C kann dies durchaus innerhalb anderer Teams trotzdem geschehen.

Bei G ist dies nicht der Fall, weil jeder Push automatisch ein Deployment auf das Produk-tivsystem verursacht. Wenn Reviews eingesetzt werden, sind diese technisch häufig so in den Entwicklungsprozess integriert, dass eine Story nur dann abgeschlossen werden kann,„wenn im Feld Pair-Reviewer jemand drinnen steht“ [E, 36:51min]. Code Reviews bewirken, dass„im Vier Augen Prinzip, [noch einmal erklärt wird,] was passiert ist“ [E, 36:34min]. Hierdurch wird das Wissen zur Umsetzung nochmals auf eine weitere Person übertragen und Fehler können entdeckt werden. Unternehmen A führt eine besondere Form durch. Ihr Code Review findet in zwei Stufen statt. Im ersten Schritt wird ein Review durch eine Person des gleichen Teams durchgeführt. Anschließend wird ein zweites Review durch eine zufällige Person eines anderen Teams durchgeführt. Dies ist in diesem Unternehmen möglich und auch sinnvoll, da alle auf der gleichen Codebasis arbeiten. Die Gefahr, dass komplexe Code Reviews nur Oberfläch-lich bearbeitet werden ist allerdings groß.„Reviews haben wir nur die klassischen. 20 Zeilen Codeänderungen und 100 gefundene Fehler, 2000 Codeänderungen und alles gut“ [B, 18:55min].

Dieses Problem kann eventuell verringert werden, wenn die Code Reviews zusammen mit den Entwicklern der Story durchgeführt werden. Diese erklären dabei Schrittweise ihre Lösung. In Unternehmen B und H werden nur„bei irgendwelchen kritischen Sachen“ [H, 09:09min] Code Reviews durchgeführt. Dies bewirkt, dass nicht der vollständige Code durch andere Personen begutachtet wird. Hier hängt es davon ab, was der Entwickler als kritisch ansieht. Dadurch können sich schnell Fehler einschleichen. Unternehmen H würde dies gerne verbessern.

Bei Code Reviews ist es „allerdings immer relativ schwierig über Architektur zu reden“ [A, 26:04min]. Die Arbeit der Umsetzung ist zu diesem Zeitpunkt bereits geschehen. Änderungen in der Architektur würden bewirken, dass viel der investierten Arbeit weggeworfen werden müsste. Aus diesem Grund sollte gerade bei Problemen frühzeitig, noch während der Entwick-lung, um Feedback gebeten werden. Pair Programming oder ein vorheriges Besprechen der Lösungsstrategie könnte dieses Problem verringern.

Unternehmen F hat eingeführt, dass für jede Story ein Entwickler verantwortlich ist. Dieser muss nicht zwingend die Entwicklung durchführen. Er dient hauptsächlich als Ansprechpartner bei Fragen zu der Story.

Eine Besonderheit im Vorgehen von Unternehmen A sind dieApproachesundProposals. Diese werden benutzt, um Feedback zu Ideen oder um Hilfe bei Problemen zu erhalten. Bei Problemen kann es vorkommen, dass sie„ein Workaround machen“ [A, 27:25min]. Hierbei sei wichtig, dass zuvor feststellt wird ob dies etwas ist, dass länger in der Anwendung bleiben soll oder ob es nur ein zeitlich begrenzter Test ist. Je nachdem welchen Bereich die Änderung betrifft würde dies zuvor über den Chat abgesprochen werden. Zur Erinnerung und zur Lösung der Workarounds werdenTechnical-DebtTickets angelegt. Dies ist ähnlich wie dasTodo-Boardvon

Unternehmen H. In Unternehmen B kann bei Problemen der Lead Developer um Unterstützung gebeten werden.„Wenn ich helfen kann, mache ich Hilfe zur Selbshilfe“ [A, 16:15min]. Der Lern-effekt sei hierdurch viel höher. Häufig werden aber auch andere Kollegen direkt angesprochen.

Bei Unternehmen C und H dienen die Architekten als Ansprechpartner.„Dann sprechen sie schon meistens häufiger als erstes mit mir darüber und dann reden wir darüber, wie wir es anders machen wollen“ [C, 12:43min]. Das Problem und eine Lösung wird den anderen Teammitglie-dern im Daily Meeting vorgestellt. Kleinere Änderungen werden direkt im Rahmen der Story realisiert. Für größere Änderungen werden, wie in den anderen Unternehmen, technische Stories erstellt. Nachdem bei H die Architekten angesprochen wurden, wird das Problem in einer größeren Runde mit den Entwicklern diskutiert. Die Unternehmen D, E und F nutzen hauptsächlich die Daily Meetings zum Ansprechen von Problemen. Wenn dies im schlimmsten Fall das Sprint-Ziel gefährdet wird dies bei Unternehmen D angepasst. Bei Unternehmen F wird in vielen Fällen im Anschluss des Daily Meetings ein spontanes Treffen durchgeführt.

„Dann ziehen wir es raus und nach dem Standup setzten sich die Leute, die das interessiert und der der daran arbeitet [zusammen].“ [E, 25:52min]. Dies hat den Sinn, dass das Daily Meeting nicht in die Länge gezogen wird. Außerdem nehmen hier viele Personen Teil die zur Lösung nicht beitragen können und deshalb nur von der Arbeit abgehalten werden.

Zusammenfassung

Tests sind hilfreich um die Lauffähigkeit einer Anwendung auf Dauer sicherzustellen. Auch bei der Architekturentwicklung können sie helfen, um eine Sicherheit bei Refaktorisierungen zu gewährleisten. Eine Entwicklung nach dem Test-First Prinzip ist in den meisten Fällen praktisch nicht realistisch. Hierzu ist eine sehr genaue Kenntnis der Fachlichkeit und deswegen eine sehr enge Zusammenarbeit mit dem Kunden notwendig.

Weitere Prüfungen mithilfe von statischen Analysen können helfen automatisiert problema-tische Codestellen zu finden. Da diese Tools hauptsächlich nur einen einmaligen Einrich-tungsaufwand benötigen, ist es sinnvoll sie von Anfang an im Projekt zu integrieren und gemeinsam mit den Tests regelmäßig auszuführen. Eine Conformance Prüfung im Rahmen einer Architektur-Retrospektive kann das Verständnis für die Architektur stark erhöhen. In der Praxis wird dies sehr selten durchgeführt. Solch eine Analyse kann sehr komplex und zeitaufwendig sein und ist deshalb auch nicht unbedingt in jedem Projekt sinnvoll einsetzbar.

Bei langlebigen Anwendungen können solche Analysen allerdings eine wichtige Rolle für den Erfolg des Projekts darstellen.

Wenn während der Entwicklung im Paar gearbeitet wird, werden Lösungswege automatisch

miteinander diskutiert. Die Partner können gleichzeitig voneinander lernen. Einig sind sich alle, dass dies mindestens bei Problemen und zum Einarbeiten neuer Kollegen eingesetzt werden sollte.

Code Reviews sind empfehlenswert, um kleine Probleme zu finden. Architekturänderungen sind aber schwer zu diskutieren, da die Entwicklung zu diesem Zeitpunkt bereits abgeschlos-sen ist. Um Probleme nach der Entwicklung vorzubeugen, kann es helfen vor Beginn der Implementierung einen groben Lösungsansatz zu besprechen.

Wenn Teams Techniken einsetzten wollen, mit dem Ziel die Codequalität zu erhöhen, sollte ihnen dies ermöglicht werden. Auch bei Zeitmangel sollte auf Techniken wie Reviews nicht verzichtet werden. Ein vielfaches der gesparte Zeit wird anschließend häufig benötigt, um übersehene Probleme zu korrigieren.