Zwischen Integration und Operation trennen
Durch Aufteilung der Methoden in Integration und Operation entsteht verständlicherer Code. Dadurch steigt die Effizienz beim Entwickeln und es passieren auch deutlich weniger Fehler. Zwei Kriterien die wir bei der Umsetzung von Kundenprojekten sehr wichtig finden.

Geschäftsführer
26. Dezember 2020

Zuletzt habe ich über das Prinzip der gegenseitigen Nichtbeachtung gesprochen. Was in einer Gesellschaft problematisch ist, ist in der Softwareentwicklung hingegen von Vorteil. Deshalb möchte ich hier weitermachen und das darauf aufbauende Integration Operation Segregation Principle, auch IOSP genannt, vorstellen.
Bei diesem Prinzip geht es darum, die Funktionseinheiten, die wir letztes Mal definiert haben in zwei Kategorien einzuteilen. Entweder sie operieren und folgen damit dem Principle of Mutial Oblivion oder sie integrieren, d.h. sie stecken andere Funktionseinheiten zusammen. Integrationen sind damit quasi das Schmiermittel, damit die Zahnräder der Maschine auch richtig laufen. Da Integrationen sich um die Verkettung von Funktionseinheiten kümmern, sind diese Abhängig von diesen. Deshalb ist es wichtig sie so einfach wie möglich zu gestalten. Aus diesem Grund enthalten sie auch keine ‚Logik‘.
Unter ‚Logik‘ ist in diesem Fall folgendes zu verstehen:
- Unäre und binäre (Rechen-)Operationen (wie
+,*,%, …) - Kontrollstrukturen (
if,else,while,for,try/catch, …) - API-Aufrufe (Methoden von Bibliotheken wie Workflow Foundation, NHibernate etc.)
- Ressourcen-Zugriffe (Dateien, Datenbanken etc.)
Operationen hingegen, dürfen ‚Logik‘ enthalten. Sie machen damit quasi die harte Arbeit. Dadurch sind sie deutlich komplizierter als Integrationen. Aus diesem Grund sollten diese so unabhängig wie möglich sein. Womit es ihnen nicht erlaubt ist auf andere Funktionseinheiten, also Operatoren oder Integrationen, zuzugreifen. Durch diese Trennung in Integration und Operation entsteht ein deutlich leichtgewichtigere Umsetzung.
Anmerkung: Bei diesem Text handelt es sich um einen überarbeiteten Repost eines alten Blog-Artikels aus 2015 von mir.

Kevin Erath
Als Mitbegründer und Geschäftsführer von pep.digital verbringe ich zwar nicht mehr jeden Tag ausschließlich damit, coole Lösungen für unsere Kunden zu realisieren. Trotzdem finde ich immer wieder die Zeit, mich auch mal tiefer in die Technik einzutauchen und meine Erkenntnisse hier im Blog zu teilen. Und ehrlich gesagt, das Unternehmen und unsere tollen Mitarbeiter:innen weiterzuentwickeln, macht mir mindestens genauso viel Spaß.
Quellen
Weitere interessante Artikel
Wir möchten hier nicht nur über Neuigkeiten aus dem Unternehmen berichten, sondern auch das Wissen und die Erfahrung unserer Experten teilen.

In diesem Artikel zeigen wir, wie ein Proxy Product Owner die Arbeit in Softwareprojekten erleichtern kann. Ein Proxy PO unterstützt den Product Owner, indem er Aufgaben übernimmt, für die der Product Owner oft nicht die Zeit oder Erfahrung hat. Dazu gehört die Ermittlung von Kundenbedürfnissen, das Erstellen von User Stories, die Planung der nächsten Schritte und die Klärung fachlicher Fragen. So werden Engpässe vermieden und das Entwicklungsteam bleibt produktiv.

Karin Neubauer
Business Analystin

Wird Code nach dem Prinzip der gegenseitigen Nichtbeachtung erstellt, so ist er so unabhängig wie möglich. Dadurch lässt er sich leichter verstehen und auch verändern. Bei der Entwicklung der Softwarelösungen unserer Kunden achten wir besonders darauf, dass unsere auch Lösungen langfristig weiterentwicklungsfähig bleiben.

Kevin Erath
Geschäftsführer
