• info@noobygames.de

MonatsarchivMärz 2019

sonarqube_gopher

IOSP

Jeder von uns hat es schon erlebt, dass er in ein bestehendes Projekt kommt und eine neue Funktionalität implementieren will und dann einen Moloch vorfand. Einen solchen Moloch, dass wir gar nicht mehr wussten, wie man diesen Bändigen soll. Nun habe ich in solchen Fällen viele Stunden, oder gar Tage damit verbracht den Moloch zu verstehen und manchmal habe ich dem Moloch dann noch einen Arm, oder ein Bein angeheftet, was ihn nur noch größer, furchteinflößender und vor allem komplizierter gemacht hat.

Ein solcher Moloch kann in vielen Formen auftreten. Manchmal ist es eine Klasse mit tausenden LOC (Lines of Code), manchmal ist es eine Funktion mit einer unglaublich großen CC (Cyclomatic Komplexity), die durch viele IF-Else- und große Switch-Strukturen erzeugt wurde. Viele von uns haben sich bereits die Frage gestellt, wie man diese angsteinflößenden Monstrositäten bändigen kann. Ich möchte euch nun ein Mittel an die Hand geben, dass jeder Entwickler leicht verstehen und Umsetzen kann. Dies funktioniert sowohl bei alten, wie auch bei neuem Code. Das Wundermittel nennt sich Integration Operation Segregation Principle kurz IOSP.

Wie Erkenne ich einen solchen Moloch?

Glücklicherweise sind Verstöße gegen IOSP leicht an folgenden Verstößen zu erkennen:

  • Wenn man ein schlechtes Bauchgefühl hat.
  • Die Methode hat mehr als 10 – 30 Zeilen
  • Die Zyklomatische Komplexität ist sehr hoch
  • Die Methode hat viele Abhängigkeiten

Um diese Verstöße gegen IOSP und damit meist auch Verstöße gegen weitere Prinzipien. Ausfindig zu machen kann man Beispielsweise Statische Code Analyse Tools verwenden. Wie das geht zeige ich hier.

Wie funktioniert IOSP?

Wenn Code nur Bausteine aus dem eigenen Projekt, des eigenen Codes zusammensteckt, dann nennt man ihn Integration.

Wenn der Code domänen Logik und Kontrollstrukturen enthält, handelt es sich um eine Operation

In folgendem Beispiel sieht man eine Kette von Funktionsaufrufen. Möchte man nun Funktion 1 testen, so muss man mit großer Wahrscheinlichkeit auf Mocking/Faking der Abhängigkeiten zurück greifen, da hier Operation und Integration vermischt wurde.

Hier sollte man nun im ersten Schritt versuchen diese Verkettung zu vereinfachen. Eine mögliche Vereinfachung wird im nächsten Bild dargestellt.
Hier sind nun Funktion 3, 5 und 6 als Operation erkennbar. Diese können ohne weiteres einfach getestet werden. Funktion 1 Integriert hierbei Funktion 2, 4 und 6

In unserem Beispiel haben stellen wir allerdings fest, dass wir die Bausteine noch weiter voneinander entkoppeln können, indem wir die Funktion 2 bis 6 in Funktion 1 integrieren.

Im letzten Schaubild sehen wir nun, wie die „perfekte“ Umsetzung von IOSP aussehen kann. Funktion 2 bis 6 sind komplett von den anderen Funktionen entkoppelt. Sie haben keine Kenntnis voneinander und stellen reine Operationen dar. Funktion 1 hingegen integriert die anderen 5.

Somit sind Funktion 2 bis 6 nun einfach über UnitTests testbar und Funktion 1 über einen Integrationstest.

Ich habe diese Entkopplung bewusst in 2 Schritten dargestellt, um klar zu machen, dass es einfacher ist sich einzelnen Teilen der Logik zu widmen, anstatt das komplette Paket in einem rutsch zu refactoren.

Welche Vorteile haben wir durch IOSP?

Setzt man IOSP Konsequent um, so ergeben sich folgende Vorteile:

  • Kurze einfach zu verstehende Methoden
  • Leicht testbarer Code
  • Evolvierbarer Code
  • Die Methodennamen werden wieder aussagekräftig

%d Bloggern gefällt das:

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklären Sie sich damit einverstanden.

Schließen