Die Zielgruppen von Code

Wer versucht, Dienstleistungen oder Produkte zu verkaufen, muss noch vor dem ersten Gespräch mit potentiellen Kunden wissen, an wen überhaupt geliefert werden soll. Mit der Erforschung geeigneter Zielgruppen beschäftigen sich ganze Abteilungen in Unternehmen, um ihre Werbekampagnen, die Produktaufmachung u.v.m. möglichst optimal auszurichten. Sie versuchen die Frage zu beantworten: „Was sind das für Menschen, mit denen ich geschäftliche Beziehungen haben will?“.

Das einfachste Ergebnis der Arbeit eines Programmierers ist der produzierte Code, welcher die gewünschten Anforderungen möglichst genau umsetzt. Dieser Code wird im Regelfall auch an den Auftraggeber ausgeliefert. Üblicherweise erfolgt dieses in Form von Textdateien, die man auf jedem Computer, sogar auf Smartphones, ohne spezielle Software lesen kann. Jedoch ist das keine „Gutenacht-Lektüre“ – nicht einmal für einen Entwickler.
Ein Sprichwort lautet: „Code soll ausgeführt werden, nicht gelesen, sonst ist er nutzlos!“. Das ist schnell gesagt. Aber stimmt das auch?

Daher stellt sich die nächste Frage: „Welche Zielgruppen existieren eigentlich für Code?“.

Die Zielgruppen

Wir können mit aufsteigender Priorität drei Zielgruppen identifizieren:

  1. Der Compiler
  2. Andere Entwickler
  3. Der Auftraggeber

Es lohnt sich, diese jeweils etwas genauer zu betrachten. Denn so unterschiedlich sie sein mögen, ergeben sich teils interessante Wechselwirkungen oder gar keinerlei Gemeinsamkeiten.

Der Compiler

Beginnen wir mit dem Compiler. Dieses Stück Programm sorgt, ganz simpel ausgedrückt, dafür, dass der vom Entwickler produzierte Code in Maschinensprache umgewandelt wird und ultimativ vom Computer in Handlungen umgesetzt werden kann. Dieser Prozess stellt gleichzeitig sicher, dass die Syntax des Programmcodes korrekt ist. In der Hierarchie „syntaktisch korrekter Code -> technisch korrekter Code -> fachlich korrekter Code“ sichert er somit die unterste Schicht ab.


(Der Compiler ist mit meiner Konfiguration nicht sehr zufrieden, kann aber trotzdem weiterarbeiten.)

Dabei kann aufgrund des kurz skizzierten Schichtenmodells vom Compiler nicht sichergestellt werden, dass ausschließlich technisch korrekter Code produziert wurde. Als Beispiel dient die Kommunikation mit der Applikationsdatenbank: wird eine Verbindung zur Datenbank aufgebaut, muss der Entwickler in manchen Fällen dafür Sorge tragen, dass diese möglichst schnell wieder geschlossen wird, auch im Fehlerfall. Dass dies auch wirklich geschieht, kann kaum ein Compiler einwandfrei sicherstellen. Gut ausgestattete Entwickler werden dabei von ihren Werkzeugen unterstützt („the best tools money can buy“). Aber auch hoch entwickelte IDEs können lange nicht alle Fehlerfälle während der Entwicklung erkennen. Partnerschaftliche Reviews zwischen Kollegen und Erfahrung sind hier die Mittel der Wahl, um frühzeitig Korrekturmaßnahmen einzuleiten.

Auch die Fachlichkeit der Applikation liegt weit außerhalb der Reichweite des Compilers. Somit sind ihm fehlerhaft umgesetzte Use Cases egal und werden pflichtbewusst in Maschinencode umgesetzt. Einige Programmiersprachen unterstützen es, fachliche Logik bis zu einem gewissen Grad dermaßen einzubetten, dass Verstöße zu Fehlern bei der Kompilierung führen. Diese sind jedoch nur wenig verbreitet und der Grad dieser Unterstützung ist zumeist so gering, dass es sich nicht lohnt, auf eine wenig unterstütze Plattform zu setzen.
Zusammenfassend kümmert es den Compiler also ausschließlich, ob die Syntax, also die Grammatik des Codes, korrekt ist.

Andere Entwickler

Kommen wir zur Zielgruppe der Entwickler. Ihre Aufgabe ist es, Kundenanforderungen so umzusetzen, dass die Use Cases des Auftraggebers erfüllt werden. Entwickler haben also eine Art Übersetzeraufgabe: Anforderungen, von Anforderungsmanagern aufbereitet und in menschlicher Sprache formuliert, in die Syntax der gewählten Programmiersprache umzuwandeln und dabei sowohl die fachlichen als auch die technischen Anforderungen an das gewünschte Werk zu erfüllen. Daraus resultiert, dass Entwickler zwei große Themenfelder zu bearbeiten haben: Fachlichkeit und Technik.

Entwickler stellen eine Reihe an Anforderungen an Code, die für den Auftraggeber nach der Auslieferung üblicherweise unsichtbar sind. Dazu zählt vor allem die Wartbarkeit. Dies bedeutet, im Allgemeinen gesagt, dass sichergestellt wird, dass die Codebasis über mehrere Versionen und oftmals Jahre hinweg weiterentwickelt werden kann. Eine gute Wartbarkeit kann mit Hilfe verschiedenster Mittel erreicht werden:


(Werkzeuge wie SonarQube können mittels Codeanalyse abschätzen, wie wartbar eine Codebasis ist.)

Zuvorderst sind automatisierte Tests zu nennen. Hierbei wird spezieller Testcode produziert, der den produktiven Code auf fachliche oder technische Korrektheit überprüft. Im Optimalfall erhält man eine Codebasis, die beweisen kann, dass sie den Anforderungen, fachlicher oder technischer Natur, genügt. Dem Prinzip „jede Zeile Code ist schuldig, außer anderweitig bewiesen“ folgend, gerät man jedoch in ein Dilemma: Wer beweist, dass der Testcode korrekt ist? Ist Testcode nicht auch Code und ist weniger Code nicht gleichbedeutend mit weniger Fehlern?

Realistisch gesehen ist jedoch jede Zeile Testcode als unbedingt wertvoll anzusehen. Dies kann an einem simplen Beispiel gut demonstriert werden: Soll ein Entwickler eine Anforderung umsetzen, ist nicht zweifelsfrei bewiesen, dass die bestehende Codebasis einwandfrei funktioniert. Mittels automatisierter Tests kann er sich jedoch davon überzeugen, dass die Testfälle, die in Tests beschrieben wurden, fehlerfrei sind. So kann er seine Änderungen vornehmen und mittels der Tests feststellen, ob es unerwünschte Nebenwirkungen gab. Abschließend werden neue Tests produziert, die die Änderungen auf Korrektheit überprüfen und somit einen dokumentarischen Charakter besitzen. Dieser Workflow beschreibt nur einer von vielen Mehrwerten, die automatisierte Tests liefern können.

Ein weiteres Werkzeug, mit dem wartbarer Code produziert werden kann, ist eine einheitliche Architektur. Wie der Name schon suggeriert, liegt der Vergleich mit dem Baugewerbe nahe und ist auch überaus angebracht. Nicht zuletzt aus dem Grund, dass ein Haus ohne solide Architektur die kommenden Jahre nicht überstehen wird, werden die meisten Entwickler auch bei einer Codebasis eine solide Architektur als Pflicht ansehen.

Allein, den Begriff Architektur in Bezug auf Code zu definieren, ist genauso oft gescheitert, wie es versucht wurde. Dies liegt daran, dass er einen fast beliebigen Umfang besitzen und auf die verschiedensten Domänen angewandt werden kann. So können verschiedene Architekturstile auf verschiedene Bereiche einer Codebasis angewandt und dort besonders effizient sein und gleichzeitig auf unterschiedlichen Detailstufen dafür sorgen, dass Code in gleichbleibenden Mustern strukturiert wurde. Allgemein akzeptiert ist daher die Definition, dass die Architektur einer Software der Summe aller strategischen Entscheidungen hinsichtlich der Codestruktur entspricht. Am besten ist es, wenn diese Entscheidungen vom Entwicklerteam gemeinsam getroffen oder mindestens vom Team mitentwickelt und akzeptiert wurden.

Der Auftraggeber

Sollte es sich beim Softwareprojekt um eine maßgeschneiderte Lösung handeln, tritt schnell die dritte Zielgruppe auf den Plan: der Auftraggeber.
Eine der wichtigsten Anforderungen für den Auftraggeber an das Projekt ist, dass die Vision umgesetzt wurde. Visionen können unterschiedlicher nicht sein.

Daher lassen sich nur Kategorien nennen. Beispielsweise können Prozesse von Mitarbeitern im Unternehmen des Kunden vereinfacht werden. Dazu gehört das Automatisieren von Arbeitsschritten oder das erstmalige Erlauben von systemischer Hilfe in Prozessen, die vorher komplett händisch durchzuführen waren. Andere Unternehmen hingegen besitzen bereits gesammelte Datenmengen, die noch nicht ausgewertet werden können. Hier helfen maßgeschneiderte Berichtslösungen, die Einblicke in Betriebsabläufe liefern und Potentiale aufdecken können. Bei diesen beiden Kategorien ist gemeint, dass sie nicht technischer Natur sind und auf einer höheren Ebene arbeiten, als eine einzelne Funktion aus fachlicher Sicht abbilden kann. Es handelt sich um das langfristige Ziel, das mit der Lösung erreicht werden soll, um die Vision.

Doch nicht nur bei maßgeschneiderter Software existiert der Auftraggeber als Zielgruppe, sondern auch bei der Produktentwicklung, bei der es einen ganzen Markt an Kunden gibt. Hier ist es ungleich schwieriger, die konkrete Vision des Projektes zu definieren. Vielmehr muss die Vision der Produktentwickler auf die Bedürfnisse einer eher unbekannten Menge an Kunden passen, welche mit dem Produkt ihre eigenen Bedürfnisse zu erfüllen versuchen.

Neben der Vision existiert eine Reihe impliziter Anforderungen an die entstehende Software. So soll sie in angemessener Zeit mit den ihr gestellten Aufgaben fertig werden, benutzerfreundlich zu bedienen sein, unter Umständen auch auf mobilen Endgeräten laufen. Die Sicherheit ist allerspätestens bei Anwendungen, die mit dem offenen Internet kommunizieren, zu berücksichtigen. Diese Anforderungen, sollten sie implizit im Raum stehen, quantifizierbar und explizit zu machen, ist eine wichtige Aufgabe und sollte nie unter den Tisch fallen.

Nicht zuletzt hat ein Auftraggeber eine implizite Anforderung an die Software, die so wahrscheinlich nie in Lastenheften steht: Eine Funktion, deren Umsetzung heute Summe X kostet, soll in einem Jahr immer noch X kosten, oder ihre Kosten sollen nicht stark von dieser Summe abweichen. Diese Anforderung schafft einen direkten Schulterschluss zur Anforderung anderer Entwickler an wartbaren Code. Ganze Bücher, Workshops und Konferenzvorträge befassen sich mit dem Thema, dass Software, die über einen nennenswerten Zeitraum existiert, mit der Zeit aufwendiger zu warten und erweitern ist. Das geschieht, wenn die Architektur, welche für eine Codebasis gewählt wurde, ihren Anforderungen nicht mehr gewachsen ist oder durch mangelhafte Pflege erodiert. Auch wenn sich Software nicht wie ein Fahrzeug bei Gebrauch abnutzt, muss sie auf Dauer, speziell wenn viele Änderungen vorgenommen werden, gewartet werden. Dies bedeutet, dass Arbeit vorgenommen wird, ohne der Vision näher zu kommen. Diese Arbeit stellt aber sicher, dass auch zukünftig der Funktionsumfang in angemessener Geschwindigkeit erweitert werden kann.

Ist das alles?

Natürlich nicht! So unterschiedlich wie Menschen, Unternehmen, Kunden und Use Cases sind, so viele Anforderungen und auch Zielgruppen von Code gibt es. Jeder hat seine eigenen Vorstellungen davon, wie Software zu funktionieren hat. Schlussendlich können jedoch alle diese Vorstellungen auf Code heruntergebrochen werden, den Menschen formulieren müssen. Und dass dieser Prozess reibungslos funktioniert, ist nicht die Aufgabe eines einzelnen Programmierers, Dienstleisters oder Auftraggebers.

Projekterfolg ist nur dadurch zu erreichen, indem dieses Dreigestirn #mITeinander arbeitet.

Diesen Beitrag teilen.

Josha von Gizycki
Software Development
Ständiges Dazulernen und der Austausch mit Gleichgesinnten sind seiner Meinung nach zwei der wichtigsten Bausteine zur stetigen Verbesserung.