Softwarearchitektur in der Praxis

Das falsche Berufsbild

In meiner täglichen Tätigkeit als Softwarearchitekt und Technologieberater und der damit verbundenen Zusammenarbeit mit verschiedenen Softwareentwicklern gibt es eine Menge interessanter Aspekte, die mich ständig dazu bewegen, über Softwareentwicklungsprozesse, Codequalität und Implementierungsmethoden nachzudenken.
Oft werde ich gerade in der Tätigkeit als Berater gefragt, wie es möglich ist, Entwickler zum Schreiben qualitativ hochwertigen und lesbaren Codes zu motivieren.
In den folgenden Ausgaben meiner Kolumne soll es unter anderem um diese Frage gehen. Neben der Analyse der Problematik und dem Aufzeigen von praktischen Lösungsansätzen, möchte ich das Thema mit jeder Menge an praktischen Beispielen aus dem wahren Leben anreichern.

Die oben gestellte Frage lässt sich leider nicht einem Satz beantworten. In der Analyse der Frage werden wir schnell feststellen, dass hier verschiedene Ausgangspositionen betrachtet werden müssen.
Beginnen wir in unserer Betrachtung mit dem Berufsbild des Softwareentwicklers. Branchenunabhängig ist es nun einmal so, dass Menschen unterschiedliche Methodiken zur Lösung von Problemen, sei es im Alltag oder auch im Beruf nutzen. Wir haben es mit Menschen zu tun, die jeweils eine individuelle Sicht auf die entsprechende Problemstellung haben.
In vielen Ingenieursdisziplinen oder auch Handwerksberufen ist es durchaus üblich, dass einzelne Schritte in einer vorher fest definierten Reihenfolge bis hin zur Fertigstellung der Aufgabe durchgeführt werden. Dort gibt es meist kaum Zweifel an den Vorgehensweisen.
In der Softwareentwicklung setzen sich erst in den letzten Jahren der Einsatz von „Best Practise“ Patterns und Vorgehensmodelle durch. Mit Martin Fowlers Standardwerk „Patterns of Enterprise Application Architecture“ wurde ein wichtiger Grundstein für die strukturierte Erstellung qualitativ hochwertiger Software und die Notwendigkeit der Nutzung von wieder verwendbaren Patterns gelegt.
Jedoch sehe ich oft in kleinen Unternehmen, dass diese ingenieurmäßigen Vorgehensweisen aus verschiedenen Gründen nicht zum Einsatz kommen. Zum einen kann es sein, dass diese nicht bekannt sind und schon seit vielen Jahren auf Zuruf Software entwickelt wird. Bei anderen herrscht das Vorurteil, man müsse schneller zum Ziel kommen und möglichst schnell dem ungeduldigen Kunden schon etwas Klickbares zeigen können. Zudem sei es auch zu teuer und würde zu lange dauern, sich über die Softwarearchitektur, Design Patterns und Implementierungsmethodiken Gedanken zu machen. Das größte Problem dieser Vorgehensweise und der damit verbundenen prozeduralen Entwicklung der Software liegt meist darin, dass es neben den später auftretenden Problemen fehlender Wartbarkeit, gerade mit steigender Komplexität immer schwieriger wird, den Code zu überschauen. Der Aufwand eine Anwendung zu Warten steigt bei prozeduralen Programmiermodellen und Unstrukturiertheit expotential zur Komplexität der Anwendung. Setzt man jedoch auf Designpattern wie beispielsweise Domain Driven Design (DDD) verläuft die Linie linear. Oft wird dieses Problem unterschätzt. Typische Kommentare dazu sind beispielsweise Sätze wie: „Unsere Entwickler haben das im Griff, sie wissen genau, wo was steht.“ Was aber nun, wenn das Team später in anderen Projekten steckt und der Kunde zeitnah, Erweiterungen wünscht? Wie schnell versteht ein Neuer in der Firma diese Art der Implementierung? Der Mechaniker in einer Autowerkstatt weiß, egal in welcher Werkstatt er arbeitet, immer, dass er vor dem Wechseln der Räder erst die Schrauben entfernen muss. Er weiß außerdem genau, welches Werkzeug er verwenden muss.

Wie gelingt es uns nun in der Softwareentwicklung für einfache Prozesse allgemeingültige und sprachunabhängige Arbeitsschritte festzulegen? Ist es der Komplexität geschuldet, dass dies in unserer Branche vielleicht gar nicht geht? Ich glaube nicht. Der Grund ist vielmehr darin zu sehen, dass sich dass Berufsbild des Softwareentwicklers erst in den letzten Jahren klarer abzeichnet. Ich kann mich noch recht gut an die Situation in den 90ziger Jahren erinnern, als so mancher Bürobedarfshändler anfing, nebenher auch Computer zu verkaufen. Meist glaubte man, wenn der Verkauf von Hardware und Softwarelizenzen funktioniere, dann könnte man auch Softwareentwicklungsprojekte umsetzen. Oft begannen solche Projekte mit der Frage eines befreundeten Unternehmens: „Ihr könnt uns doch sicherlich eine Kundendatenbank, die auch noch diesen und jenen speziellen Prozess unseres Unternehmens mit abbilden kann, erstellen!?“ - Klar, kein Problem. Man nehme Microsoft Access und baue schnell etwas Funktionierendes zusammen. Gut, soweit hat das schon mal geklappt. „Also könnt ihr doch bestimmt auch noch die Faktura hinzufügen!?“ Natürlich ist dies auch kein Problem. Mit Microsoft Access kann man doch von Haus aus schöne Reports erzeugen. Also wird auch diese Kundenanforderung erfüllt. Die Anwendung wächst und wächst über die Jahre.
Architektur? Fehlanzeige! Keiner wusste, dass die Anwendung jeweils solche Ausmaße annehmen würde. Die Anwendung wurde zwischenzeitlich nach Access 2003 geupgradet und spricht nun VBA. Die Programmierer, die das Projekt einst begonnen haben, sind lange nicht mehr im Unternehmen. Für den Kunden ist die Anwendung allerdings nicht so leicht wegzudenken, da sie zentrale Unternehmensprozesse steuert. Der Büroausstatter selbst, hat sich natürlich nicht weiter auf den Nebenschauplatz der Softwareentwicklung konzentriert und leistet nur noch spartanisch Support, in dem er einen Werkstudenten mit der Pflege der Anwendung betraut hat.
Auf der Seite des Kunden sieht es inzwischen so aus, dass die Performance der Anwendung als sehr kritisch einzustufen ist. Dies ist zwischenzeitlich auch bei der Geschäftsleitung angekommen. Eine Krisensitzung wird einberufen, um sich ein näheres Bild von der Situation zu machen, denn immerhin kann man sich einen Ausfall des Systems nicht leisten.
Die Lösung des Problems könnte darin liegen, einen Technologieberater zu engagieren, der die Problematik analysiert und ein Lastenheft der Anforderungen an ein neues System nebst Übernahme des Altdatenbestandes erarbeitet.

Oftmals glaubt man aber leider, der Austausch der Backend Access Datenbank durch eine „bessere und schnellere“ SQL Server Datenbank könnte einen schnellen Erfolg bringen. Leider ist dies nicht so, da es kein Datenmodell gibt, sondern Tabellen immer noch nach Bedarf und Gutdünken ohne das nötige Fachwissen über relationale Datenmodelle erweitert wurden und die Nicht- Wartbarkeit des Programmcodes ja ohnehin weiterhin bestehen bleiben würde.
In den letzten Jahren wurden wir des Öfteren mit ähnlichen Szenarien konfrontiert. Neben der technischen Analyse und der Erstellung von Anforderungen sowie der Auswahl passender, zeitgemäßer Technologien, musste zeitgleich auch mit falschen Vorstellungen des Berufsbildes Softwareentwickler aufgeräumt werden.

Oft bestand die Vorstellung der Kunden darin, man könne ja in Stichpunkten die Anforderungen, die man an die neue Software stelle, auf einer A4 Seite niederschreiben und schon kann die Entwicklung der Anwendung beginnen.
Es bedarf einiger Überzeugungsarbeit den Kunden aufzuklären, dass ernsthafte Entwicklung qualitativ hochwertiger Software so nicht funktionieren kann.
Unsere Branche ist erwachsener geworden. Es geht nun nicht mehr einfach nur darum, schnell einen Erfolg in Form eines funktionierenden Programms zu erlangen. Gerade in Anbetracht des Lebenszyklus der Software, den Möglichkeiten die Software schnell an neue Anforderungen anpassen zu können, Interoperabilität, Sicherheit, Einhaltung offener Standards, ist es wichtig und unerlässlich, sich über das Design der Software und Methoden der Implementierung ausgiebig Gedanken zu machen. Architekturentscheidungen sind so essentiell, dass diese, wenn die Implementierung einmal begonnen wurde, nicht mehr rückgängig zu machen sind.
Das zentrale Ziel gerade für langlebige Softwaresysteme muss die Wartbarkeit sein, nur so sind auch alle anderen Anforderungen, die an ein System gestellt werden, erfüllbar. Technologische Lösungen existieren, jedoch besteht die größte Herausforderung darin, dies in der täglichen Arbeit zu organisieren, Arbeitsweisen darauf abzustimmen und Mitarbeiter dazu zu motivieren.

Motivation für besseren Code

Entwickler haben sehr unterschiedliche Sichtweisen auf ihre Arbeit. Einige Entwickler vertreten die Auffassung, es sei nicht wichtig, ob Code lesbar und verständlich ist oder gar wieder verwendbar (Wiederverwendbarkeit ist ja auch mit Copy and Paste zu erreichen) ist. Für diesen Typ Entwickler liegt der Fokus auf dem Aspekt, dass die Aufgabe zunächst erstmal erledigt ist. Das Handlungsmuster ist meist sehr pragmatisch und lösungsorientiert, hat aber nicht den Weitblick und das Interesse, über Folgen schlecht wartbaren Codes nachzudenken. Andere Entwickler wiederum versuchen, den Code immer weiter zu optimieren und verlieren in ihrem persönlichen Anspruch an Kapselung, schnell das eigentliche Ziel aus den Augen. Oftmals wird dabei immer wieder von vorne begonnen, bis dem eigenen Anspruch genüge getan wurde oder der Projektleiter die Notbremse zieht. Dieser Perfektionismus wird häufig noch mit der Auffassung: „Man könnte es noch besser machen, wenn doch noch Zeit wäre“, unterstrichen.
An beiden Extremen ist erkennbar, wie kompliziert es schon auf Grund dieser Tatsachen ist, den richtigen Weg für Implementierungen zu finden.
Der Ausgangspunkt gute, qualitativ hochwertige Software zu produzieren, beginnt meiner Auffassung nach, immer im Kopf aller Beteiligten. Das heißt, nicht nur Entwickler als die Ausführenden sind dafür verantwortlich, sondern auch der Kunde, der einsehen muss, dass die Erstellung eines Softwareproduktes nicht in wenigen Tagen zu erledigen ist, auch wenn es aus seiner Sicht doch recht einfache Anforderungen sind, als auch der Projektleiter und der Softwarearchitekt.

Wichtig ist es doch, ein gemeinsames Ziel und auch den gemeinsamen Weg zum Ziel zu definieren. Gerade in jungen Teams oder in Teams, die noch nicht zusammengearbeitet haben, ist es schwierig mit verschiedenen Wissensständen umzugehen.
Der Architekt sollte sich neben den Aufgaben wie Klassendesign und dem Schichtenmodell auch über die Art der Implementierung Gedanken machen und diesen Weg auch dem Entwicklerteam gegenüber kundtun und vertreten. Hier sind Kommunikation und eine intensive, gemeinsame Auseinandersetzung mit der Thematik gefragt. Genau das ist der Punkt an dem gute Vorsätze häufig scheitern, da Aufgaben verteilt werden, aber ein zumindest unternehmensweit standardisierten Weg der Implementierung nicht festegelegt wurde. So implementiert jeder nach seinem Wissenstand.

Sicherlich hat man zu Beginn eines Projektes eine Vision und Ideen, wie die Implementierung stattfinden soll. Ist der Zeitrahmen eng gesteckt, muss man auf bewährte schon erfolgreich beendete Strategien und Modelle zurückgreifen. Es setzt natürlich jede Menge Erfahrungen voraus, für die jeweilige Anforderung auch die richtige Architektur, Patterns sowie Implementierungsstrategien zu finden.
Sind diese Erfahrungen nicht vorhanden, ist es zu empfehlen einen erfahrenen Architekten ins Boot zu nehmen, um dieses Defizit zu beseitigen.

Codereviews gehören zu meiner täglichen Arbeit. Meist entdeckt man dieselben Probleme. Wie kommuniziert man nun diese im Team, so dass perspektivisch weniger Refactoring notwendig wird? In wie weit sollte nun schon optimierter Code durch den Entwickler geliefert werden? Ich denke, dafür gibt es verschiedene Ausgangssituationen. Zum einen ist dies von der Erfahrung des Entwicklers selbst abhängig. Ein erfahrener Entwickler wird sicherlich schneller den Optimierungsbedarf seines Codes erkennen als ein unerfahrener. Zum anderen spielt natürlich auch der Zeitfaktor eine entscheidende Rolle. Wartet der Kunde bereits auf sein neues Release oder drängt die Projektleitung, die neue Programmversion so schnell als möglich bereitzustellen, dann ist es natürlich sehr schwierig, Codeoptimierungen durchzuführen.

Wie bringe ich mein Team dazu, objektorientiert zu denken und zu handeln, anstelle lange, unübersichtliche Prozeduren zu schreiben bzw. den berühmten Blick über den Tellerrand zu wagen? Der Prozess setzt eine gewisse Kontinuität und eine Menge Feingefühl voraus. Zum einen ist zu beachten, dass Kritik am Code eines Entwicklers, die ich mit Codereviews zwangsläufig vornehmen muss, auch immer Kritik an der Arbeit anderer ist. Dies wird schnell persönlich genommen. Deshalb ist es entscheidend, nicht nur im Nachhinein mit dem erhobenen Ziegefinger dazustehen, sondern präventiv und offensiv von Projektbeginn an, die Auseinandersetzung mit der Thematik zu fördern.

Neben den üblich Utensilien wie Coding Standards und Style Guide sind gerade zu Projektbeginn Meetings, in denen man gemeinsam mit seinem Team exemplarisch Implementierungen vornimmt, um den gewünschten Ansatz aufzuzeigen und zu schulen, wichtig. Es ist notwendig diese Meetings in zeitnahen Abständen zu wiederholen, um damit auch Wildwuchs von Anfang zu vermeiden.
Codereviews dürfen nicht auf die lange Bank geschoben werden. Es ist zu empfehlen, diese mit Projektbeginn täglich durchzuführen. Notwendige Änderungen sollten mit dem betreffenden Entwickler persönlich besprochen und gegebenenfalls auch gemeinsam erarbeitet werden.
Damit erreicht man in jedem Fall eine ständige Auseinandersetzung mit der Thematik und fördert das Verständnis für die Notwendigkeit, dass Lesbarkeit, Wartbarkeit und Qualität des Codes wichtige Aspekte in der Softwareentwicklung sind.
Dieser Prozess scheint zunächst sehr aufwendig, ist aber gemessen an Folgeproblemen wie beispielsweise langwierige Fehlersuche, die durch schlechte Implementierung und ungenügendes Design der Software unter anderem entstehen, gering.
Eine Nachhaltigkeit ist zudem für Folgeprojekte zu erwarten.

Rico Fritzsche
Softwarearchitekt

Literatur:
1. Martin Fowler (2002) Patterns of Enterprise Application Architecture, Addison-Wesley Professional

Weitere Infos zu diesem Fachartikel:

Themen in diesem Fachartikel:


Unternehmensinformation / Kurzprofil:
Leseranfragen:
Kontakt / Agentur:
Bereitgestellt von Benutzer: Boerner
Datum: 05.02.2010 - 14:46 Uhr
Sprache: Deutsch
News-ID 418
Anzahl Zeichen:

Kontakt-Informationen:
Ansprechpartner: Lars Börner
Stadt:

Chemnitz

Telefon: 03715347615

Kategorie:

New Media & Software

Art der Fachartikel: bitte
Versandart: Veröffentlichung
Freigabedatum: 08.02.2010

Dieser Fachartikel wurde bisher 1045 mal aufgerufen.


Der Fachartikel mit dem Titel:
"Softwarearchitektur in der Praxis"
steht unter der journalistisch-redaktionellen Verantwortung von

VISUAL WORLD (Nachricht senden)

Beachten Sie bitte die weiteren Informationen zum Haftungsauschluß (gemäß TMG - TeleMedianGesetz) und dem Datenschutz (gemäß der DSGVO).

Microsoft-Technologien - was nützt dem Mittelstand? ...

Innovative, neue Technologien auf dem Markt Microsoft hat in den letzten Jahren eine Menge innovativer, neuer Technologien auf den Markt gebracht, die es uns als Dienstleister ermöglichen, die Anforderungen unserer Kunden in höchster Qualität kos ...

Alle Meldungen von VISUAL WORLD