Knigge für Software-Architekten

Antimuster: Der Codeheld

Peter Hruschka und Gernot Starke

Willkommen in der zehnten Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.

In der Nacht vor Übergabe des Systems an den Auftraggeber: Einsam hockt er mit gekrümmtem Rücken und verbissenem Blick vor dem Bildschirm. Er, mit Quellcode und Compiler allein in der Finsternis. Noch schnell ein Feature programmiert, ein paar coole Optimierungen und zwei, drei Bugs gefixt, es ist ja erst zwei Uhr, noch Zeit genug bis Sonnenaufgang.

Gegen fünf Uhr am Morgen erfolgt dann mit letzter Kraft der finale Commit – und dann ab nach Hause. Getestet haben wir ja gestern schon.

Code ist wichtig

Zuerst einmal die Vorbemerkung, dass Quellcode das ultimativ wichtige Ergebnis jeglicher Softwareentwicklung darstellt -dessen Verhalten letztlich die Qualität des Gesamtsystems ausmacht. Sie ahnen schon, dass nun ein „aber“ folgt: Quellcode beschreibt Tatsachen, aber keine Begründungen. Im Source finden Sie keine Informationen über verworfene Alternativen, keine Zusammenhänge im Großen, keine Übersicht über das Gesamtsystem. Sie sehen sehr viele Bäume, aber keinen Wald.

In kleinen bis mittleren Systemen, die von kleinen Teams über lange Zeit gebaut und weiterentwickelt werden, kann Quellcode als einziges Artefakt ausreichen. Jedoch sind unsere persönlichen Laufbahnen in vielen Unternehmen und Branchen mit drastischen Gegenbeispielen gepflastert. Nicht überzeugt? Dann schauen Sie auf [1], [2], [3], [4] oder Perl, APL oder zeilenlange reguläre Ausdrücke.

Code löst nicht alle Probleme

Kommen wir zu unserem Codehelden zurück. Bitte entschuldigen Sie die eindeutig maskuline Form – wir haben niemals weibliche Vertreter dieser Spezies getroffen. Er versucht, jegliches Problem durch neuen oder umgebauten Code zu lösen. Leider gibt es einige Klassen von Problemen, die sich einer rein codebasierten Lösung heftig widersetzen: Nehmen wir die Vertraulichkeit gespeicherter Daten als Beispiel. Codehelden können Daten verschlüsseln, aber zur Vertraulichkeit gehören (unter anderem) Benutzer- und Rollenkonzepte, organisatorische Verfahren zur Verwaltung von Krypto-Schlüsseln, sinnvolle Vertreter- oder Backup-Regelungen.

Ein weiteres Beispiel für ein nicht nur mit Code lösbares Problem ist die (sinnvolle) Forderung nach Verständlichkeit von Systemen. Code ist manchmal schlichtweg zu umfangreich, sodass nicht alle interessierten und relevanten Stakeholder ihn überhaupt lesen können. Wie viel Zeilen fremden Quellcode verstehen Sie denn pro Tag? Das hängt sicher vom Quellcode ab – aber Sie werden garantiert MEHR davon verstehen, wenn Ihnen jemand eine sinnvolle begleitende Dokumentation bereitstellt (beispielsweise Baustein-, Laufzeit- oder Verteilungssichten Ihres Systems [5]).

Insgesamt kann der Codeheld gerade übergreifende und konzeptionelle Themen teilweise nur unzureichend adressieren.

Code entsteht im Team

Code entsteht üblicherweise in Teams. Dazu müssen Teammitglieder miteinander kommunizieren – und das nicht nur über Skype, Jabber oder Bugzilla. Der Codeheld ignoriert diese Tatsache und versucht, möglichst viel der wertvollen (Code-)Substanz alleine zu produzieren. Er verzichtet weitgehend auf verbale Kommunikation. Selbst Commit-Kommentare scheinen ihm redundant, weil ein ordentliches „diff“ angeblich ähnliche Aussagekraft besitzt.

Wir sind der Meinung, nur mit angemessener Kommunikation der Stakeholder untereinander kann der dem Problem angemessene Quellcode entstehen. Ohne Abstimmung mit anderen löst der Codeheld höchstens den (möglicherweise kleinen) Teil des Problems, den er zum aktuellen Zeitpunkt verstanden zu haben glaubt.

Wichtige Entscheidungen

Viele Systeme gewinnen erst durch einige zentrale Entwurfsentscheidungen ihre eigentliche Gestalt. Ob das Produkte betrifft oder technische Konzepte, ob Frameworks oder den Einsatz von Standardsoftware: Solche zentralen Entscheidungen besitzen vielfältige Konsequenzen für statische und dynamische Strukturen eines Systems. Wollen Sie den zugehörigen Quellcode verstehen, müssen Sie diese zentralen Entscheidungen und deren Begründungen kennen. Leider stehen solche Entscheidungen praktisch niemals im Quellcode. Eine hervorragende Einführung in die Bedeutung und den Aufbau von Entwurfsentscheidungen hat Stefan Zörner in [6] geschrieben – unbedingt nachlesen!

Aber: Konzepte ohne Code laufen nicht

Sie brauchen als Softwarearchitekt fundiertes Verständnis für Quellcode, Ihr Team muss guten Code schreiben und ändern können. Wenn Sie einen Codehelden haben, dann stellen Sie ihm einen „über-den-Tellerrand-Denker-und-Macher“ an die Seite – zusammen werden diese beiden gute Arbeit leisten. Konzepte alleine genügen nie als Input für Compiler, aber Quellcode genügt halt nicht als Input für Menschen!

Damit Systeme langfristig erfolgreich für alle Beteiligten sind, benötigen Sie neben dem Quellcode meist noch weitere Arbeitsergebnisse (Prozesse, organisatorische Regelungen oder sogar neue Rollen für die beteiligten Menschen). Als Softwarearchitekt verantworten Sie die angemessene Mischung aus Konzept und Code!

Peter Hruschka und Gernot Starke haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse. Mehr finden Sie unter www.systemsguild.com (Peter) und www.gernotstarke.de (Gernot). Seit Jahresanfang ist Gernot auch innoQ-Fellow.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

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