Suche
Komplexität beherrschen

Relax: Jede Codebasis verrottet mit der Zeit

Dominik Mohilo, Hartmut Schlosser

© Shuttertsock/EggHeadPhoto

Es ist schwer, sauberen, klar strukturierten und schlanken Code zu schreiben, der sich problemlos erweitern lässt und auch in 5 Jahren noch gut performt. Doch keine Angst: Wem das nicht gelingt, gehört keineswegs zu einer Minderheit. Nahezu jedes Projekt verfällt mit der Zeit – und das ist nicht unbedingt ein Zeichen mangelnden Könnens…

… sondern hat durchaus auch mathematische Gründe, die uns Software-Architekt Erik Dietrich in seinem Blog Post „Relax, Everyone’s Code Rots“ vor Augen führt. Doch immer schön der Reihe nach!

Die Komplexität von Kommunikation steigt nicht linear

Erik Dietrich beginnt mit einem kleinen Gedankenspiel: Stellen wir uns vor, wir arbeiten alleine an einem Projekt. Die Kommunikation, die benötigt wird, um einzelne Arbeitsschritte abzuklären, ist gleich null. Doch es kommt der Zeitpunkt, wo ein Projekt für eine Person zu groß ist, es wird Zeit, mehrere Leute einzubinden. Wächst die Anzahl der Arbeiter auf drei, so gibt es schon drei Kommunikationslinien: zwischen A und B, B und C sowie A und C. Eine vierte Person erweitert das Ganze auf sechs Kommunikationslinien, denn plötzlich muss A mit B, C und D kommunizieren, B ebenfalls mit C und D und schließlich C mit D, um eine flächendeckende Kommunikation zu gewährleisten – kurz: jeder mit jedem.

Bild: connecting people von Shutterstock / Urheberrecht: tonefotografia

Bild: connecting people von Shutterstock / Urheberrecht: tonefotografia

Der Clou: Die Komplexität wächst dabei nicht linear, sondern exponentiell. Da jede Person, die zusätzlich am designierten Projekt mitarbeitet, eine Kommunikationslinie zu jeder bereits teilnehmenden Person benötigt, ist man mit 20 Leuten schon bei 190 benötigten Kommunikationslinien. Irgendwann fängt das Team an, weniger zu arbeiten und immer mehr Zeit für eine stimmige Kommunikation aufzuwenden.

Doch was hat dies nun mit Code zu tun?

Komplexer Code

Erik Dietrich sieht genau diese Analogie zwischen Team-Kommunikation und Software-Architekturen: Auch die Komplexität einer Codebasis steigt nicht linear, sondern exponentiell mit der Anzahl der logischen Einheiten/Module, die eine Anwendung aufweist. Reine Mathematik. Der Kommunikationsaufwand zwischen diesen Einheiten wächst genauso exponentiell wie in zunehmenden Teamstrukturen – und wird ohne geeignete Gegenmaßnahmen nahezu unbeherrschbar.

Die Gretchenfrage lautet nun: Was sind geeigneten Gegenmaßnahmen? Auch hier hilft die Metapher der Teamarbeit weiter: Jeder Manager mit gesundem Menschenverstand würde Teams, die aus 20, 30, 40 Personen bestehen, sofort aufsplitten. Noch mehr Leute ins selbe Team zu holen, würde mehr Probleme schaffen, als zu lösen.

Es gilt also, kleinere Einheiten zu schaffen, die weniger Kommunikationsoverhead benötigen, um zu funktionieren. Die Kommunikation zwischen diesen Untereinheiten würde man auf das strategisch Notwendige reduzieren.

Lesen Sie auch: Einstürzende Neubauten: Was passieren würde, wenn Sie in Ihrem Code wohnen müssten

In Bezug auf eine Codebasis bedeutet das: Minimiere die Größe und Komplexität der Code-Komponenten. Beseitige unnötige Abhängigkeiten zugunsten von zusammenhängenden logischen Einheiten. Versuche, risikobehaftete Kommunikationsflaschenhälse zu beseitigen – und wenn nicht möglich, zumindest eine Backup-Strategie zu etablieren. Zuletzt gilt es, die gesamte Struktur konstant zu überwachen und zu bewerten, um sicherzustellen, dass die Architektur sich verbessert oder zumindest nicht konstant degradiert.

Was daraus lernen?

Aus der obigen Metapher können wir zwei Dinge lernen: Erstens ist es nicht ungewöhnlich, dass Codebasen aufgrund der schwer beherrschbaren Komplexität verfallen. Fast jedem Programmierer ist das schon einmal untergekommen, und es ist nicht trivial, das zu verhindern. Niemand muss sich also in seiner Entwickler-Ehre verletzt fühlen, wenn ein Analyse-Tool oder ein externer Fachmann Schwachstellen in „seinem“ Code entdeckt: „Relax!“

Zweitens sollte es aber der Anspruch eines jeden Entwicklers sein, zu lernen, die Komplexität besser zu managen. Denn während Manager dazu tendieren, große, undurchsichtige Teams schneller aufzulösen, als einem lieb ist, werden sie bei großen, undurchsichtigen Anwendungen erst reagieren, wenn es zu spät ist. Die Komplexität einer Anwendung ist oftmals nicht auf den ersten Blick erkenntlich. Code Reviews, Analyse-Tools oder Clean-Code-Schulungen helfen, die Auswirkungen einer neuen Code-Komponente auf das Gesamtsystem einschätzen zu können und die Komplexität einer Anwendung besser zu verstehen.

Aufmacherbild: Five apples in a row in various states of decay against white background von Shutterstock / Urheberrecht: EggHeadPhoto

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Harald Wellmann2015-12-09 15:50:58

    Die Komplexität wächst nicht linear und auch nicht exponentiell, sondern polynomiell. Genauer gesagt, quadratisch mit der Anzahl der Teilnehmer. Die Formel dafür, n*(n-1)/2, wurde ja sogar richtig verwendet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.