Systematische Softwareentwicklung

6.5Design Patterns

"Kein Problem wird gelöst, wenn wir träge darauf warten, daß sich andere darum kümmern."
(M.L. King)

Es gibt eine "Gang of Four", das ist ein Team von vier Leuten, die ein mittlerweile sehr berühmtes Buch geschrieben haben [B20]. Darin geht es um Muster, die bei dem Entwurf von vielen objektorientierten Programmen ("Design Patterns" kann mit "Entwurfsmuster" übersetzt werden) und bei der Gestaltung von vielen Softwarearchitekturen immer wieder aufgetaucht sind. Wer ernsthaft häufiger objektorientierte Software entwickeln will, sollte sich damit beschäftigen und diese bewährten Muster anwenden, denn in Analogie zu oben genanntem Spruch hat sich die Gang of Four schon um dieses Problem gekümmert.

Beispielsweise gibt es immer wieder Systeme, die ein anderes System vertreten. Diese Stellvertreterrolle wird als "Proxy" bezeichnet. In IT-Netzwerken gibt es für den Webzugriff Proxyserver, die bereits benutzte statische Seiten für eine definierbare Zeit zwischenspeichern, um den Zugriff für alle Mitarbeiter der Firma zu beschleunigen, die Leitungen freier zu halten und die Kosten für das Unternehmen somit zu reduzieren. Ein anderes Beispiel sind "Observer", die etwas beobachten. So können beispielsweise Importprogramme ein Verzeichnis eines Servers beobachten und auf neue Dateien lauern: sobald eine neue Datei kommt, wird diese verarbeitet und in ein Archivverzeichnis verschoben. Als letztes Beispiel möchte ich den "Iterator" nennen, der viele Elemente von Irgendwas eines nach dem anderen bearbeitet. Wenn also ein bestimmter Projektleiter gesucht wird, so kann ein Stück Software über eine Liste von Projektleitern iterieren, um den richtigen zu finden.

Die Kenntnis dieser Muster mit ihren Namen und ihrer Bedeutung hat viele Vorteile: sie vereinfacht die Kommunikation zwischen den Teammitgliedern ("... wir haben dafür einen Observer implementiert ..."), trägt zu klaren Strukturen in der Software bei, vereinfacht die Dokumentation und verhindert obendrein, dass das warme Wasser immer wieder neu erfunden wird. Damit ist auch klar, dass dieses Thema nicht nur für den harten Kern des Teams gilt, sondern für alle Entwickler und auch für die Tester, Analytiker und viele andere Rollen im Team.

Natürlich gibt es mittlerweile auch weitere Bücher und selbstverständlich reichlich Infos zu Design Patterns im Web, z.B. unter [L5] und [L6].

6.6Software Ergonomie

"Die Menschen muss man nehmen wie sie sind, nicht wie sie sein sollten."
(Franz Schubert)

First principle: know the user

Meet the expectations
Look and feel of GUIs: Style guides
The Dos and Don'ts
Screen design
Join the senses
Keep it small and simple (Kiss)
Help your user ("RTFM")

NIMPLs

Nicht-Irrtümer belohnen, d.h. nicht permanent fragen, um Irrtümer zu vermeiden.

7Implementierung

7.1Implementierungsaspekte

"Amateure bauten die Arche, Profis bauten die Titanic."
(Unbekannter)

Höchste Risiken zuerst erledigen

Aktivitätendiagramme

technische Entscheidungen

Jedes Softwareprodukt hat einen Helden, der einen Teil seines Lebens für die Fertigstellung der Software geopfert hat. In unendlich vielen Stunden hat er das Projekt fast von Anfang an bis fast zum bitteren Ende begleitet und stellt die Seele des Quellcodes dar.

Bau der Datenbank

Finden von Datenstrukturen
Erstellen der Objekte
Konzeption von Algorithmen
Mnemonik, Inline-Dok
Erstellen der Testumgebungen
GUI-Verfeinerung

build Feature Teams with own schedule!

Fixed Shipping Date, but target milestones!
Code Complete!

Eine Software ist wie eine Modelleisenbahn - sie wird nie fertig!

7.2Codierung

"Glühlampen brennen heller, wenn man sie vor dem Einschrauben aus der Verpackung nimmt!"
(Unbekannt)

Vergessen Sie bei der Implementierung nicht all die unzähligen alten Tipps, die immer noch ihre Gültigkeit haben:

Die erste Regel der Optimierung heißt: "tu's nicht"
Die zweite Regel der Optimierung heißt: "wenn überhaupt, tu's erst am Schluss"

Hier ein paar Überschriften aus "The Practice of Programming" von Brian W. Kernighan & Rob Pike:

"Use descriptive names for globals, short names for locals" (dt. "Benutze beschreibende Namen für globale Variablen, kurze Namen für lokale Variablen")
"Use active names for functions" (dt. "Benutze aktive Namen für Funktionen")
"Indent to show structure" (dt. "Einrücken um die Struktur zu zeigen")
"Break up complex expressions" (dt. "Komplexe Ausdrücke aufbrechen")
"Give names to magic numbers" (dt. "Benenne Zahlen" (Konstanten, Arraygrößen, Indizes, etc.))
"Don´t comment bad code, rewrite it" (dt. "Schlechten Code nicht kommentieren, sondern neu schreiben")

ANTI-Beispiele aus oben genanntem Buch zur Codierung (natürlich in C, ist schließlich von Kernighan):

*x+=(*xp=(2*k<(n-m)?c[k+1):d[k--]));
child=(!LC&&!RC)?0:(!LC?RC:LC);

"Code Complete" von Steve C. McConnell

"Writing Solid Code" von Steve Maguire

Wir haben im Februar 2002 bei dem Review eines VisualBasic-Programms folgenden Code gefunden:

' Update the caption and fill in the list of options.
If CurrentUser = "xxx" Then mde_kopieren.Visible = False
If CurrentUser <> "xxx" Then mde_kopieren.Visible = False
If CurrentUser = "yyy" Then Label1.Caption = ...

Was sagen uns die beiden ersten Zeilen? Und die Namen der Benutzer waren auch tatsächlich hart codiert! Und Label1 ist doch auch selbst erklärend, oder?

Quellverwaltung (z.B. Microsoft Visual Source Safe) einsetzen, um saubere Teamarbeit zu ermöglichen.

Nur im Notfall während der Implementierung die Tools, die Versionen oder gar die technische Plattform wechseln. Dies bedarf schon sehr kräftiger Gründe.

7.3Leitung

"Willst du mit jemandem ein Schiff bauen, wecke in ihm die Sehnsucht nach dem Meer."

(Gert Kupfer)

Der amerikanische Slogan "My way or the highway!" (dt.: "Auf meine Art oder du bist auf der Straße!") hat heute als Führungsstil nur noch bedingt Gültigkeit. Selbst wenn ein Projekt vor die Wand fährt und ein Experte eingeschaltet wird, um das Projekt zu retten, kann er es nicht allein, sondern nur mit Unterstützung durch das Team schaffen. Und Wasser kocht unter Druck bekanntlich auch nicht schneller, sondern langsamer! Auf der Suche nach der richtigen Art der Motivation kommt vielleicht jeder mal zu dem Punkt, dass er nicht eine Konkurrenz zwischen den Teammitgliedern, sondern eine Konkurrenz jedes Teammitglieds mit sich selbst benötigt. Wenn man jemanden lobt, weil dieser etwas richtig getan hat, oder zumindest besser als sonst, so wird derjenige seinen persönlichen Fortschritt erkennen und weiter an sich arbeiten. Dies kann sich auf Soft Skills und Hard Facts gleichermaßen beziehen. Auf diese Art wird auch das ganze Team als Ganzes immer besser werden. Es bringt mehr, bei guten Taten zu loben, als bei schlechten zu strafen. Wer mehr über diesen Ansatz erfahren möchte, sollte [B22] lesen, ein kleines Buch mit einem großen Inhalt!

Wer diesen Ansatz verstanden hat und mit erster positiver Erfahrung anwendet, kann auch die so beliebten "Zielvereinbarungen" einführen. Denn Ziele und die Messungen dessen Erreichungsgrades sollten nicht als Druckmittel oder gar zum Aussortieren von Versagern dienen, sondern zur persönlichen Weiterentwicklung der einzelnen Teammitglieder. "Goals Begin Behaviors - Consequences Maintain Behaviors." (dt.: "Mit Zielen beginnt Verhalten - Konsequenzen pflegen Verhalten.") aus [B11] signalisiert denn auch eine sehr hohe Disziplin und eine ständige Beobachtung sowie Steuerung durch die Teamleitung. Gemäß dem Ansatz aus dem vorherigen Absatz kann ein Teamleiter seine Mitarbeiter zum Ziel steuern, wenn er sie in dem Moment lobt, wenn sie etwas tun, was sie dem Ziel näher bringt. Jeder wird das an sich selbst positiv spüren und motiviert sein, immer häufiger Dinge immer besser zu tun.

Eine Komponente der "Leitung" sollte also immer auch "Monitoring" sein. Wenn ein Projekt in einer späten Iterationsstufe in Schwierigkeiten durch Erschöpfung, Krankheit, Kündigung oder Mehrarbeit gerät, so ist es in der Regel schwierig, neue Leute ins Team zu integrieren. Ein Projekt wird in dieser Phase durch weitere oder neue Mitarbeiter zunächst nicht beschleunigt, sondern erst mal gebremst. Dies liegt daran, dass neue Mitarbeiter sich erst in die Architektur, die Tools, das Objektmodell und den bestehenden Code einarbeiten müssen und dabei auf die Hilfe der Veteranen des Projekts angewiesen sind (die ohnehin schon genug zu tun haben). Die neuen Mitarbeiter werden zu Beginn ggf. auch die eine oder andere Änderung vornehmen, die mehr schadet als nutzt. Es ist also wichtig, einen guten Kontakt zu den Teammitgliedern zu haben und Engpässe früh zu erkennen, denn dann lohnt sich die Einarbeitung weiterer Mitarbeiter auf jeden Fall. In diesem Moment zeigt sich dann auch, ob das Team wirklich funktioniert!

Zu einem Team gehören auch Rollen. Dies hat was mit "Effektivität" und "Effizienz" zu tun. "Effektivität" bedeutet: "Die richtigen Dinge tun.", "Effizienz" bedeutet: "Die Dinge richtig tun." Es ist also wichtig, erst einmal zu erkennen, was alles getan werden muss. Dann sollte der Teamleiter mit seinem Team gemeinsam überlegen, wer was am besten tun kann und auch möchte. Und erst dann sollte er verbindlich diese Aufgaben verteilen und sich von jedem Teammitglied einen Plan wünschen, wie dieses die Aufgaben zu tun gedenkt. Bei Bedarf kann die Rollenverteilung ja auch noch mal geändert werden. Falls jemand ein alter Hase in einer Rolle oder einem Thema ist, aber mal was anderes machen möchte und jemand neues erstmalig diese Rolle oder dieses Thema übernehmen möchte, ist es sicherlich sinnvoll, hier eine "Patenschaft" einzurichten. Wenn dann noch Ziele an die Rollen gekoppelt werden, wird auch jedem Teammitglied sein Beitrag zum Projekt und seine Verantwortung im Team sehr schnell klar. Viele Rollen haben Schnittstellen zu anderen Rollen, und diese Schnittstellen müssen sehr wohl ebenfalls erarbeitet und definiert werden. Beispielsweise muss ein Entwickler seine Quellen schon in das Sourcen-Verwaltungssystem einchecken, damit ein Quell-Tester den zugehörigen Prüfstandtest fahren kann.

Wo Licht ist, ist natürlich auch Schatten. Es macht sicherlich auch Sinn, Mitarbeitern mal zu sagen, wo sie etwas schlecht gemacht haben. Schon allein, weil die Leute sonst nach wenigen Monaten nur noch glauben, sie seien die Größten, weil sie ja nur noch gelobt werden und mit minimaler Steuerung ihre Ziele immer besser erreichen. Eine solche Erfahrung steigt Leuten schnell in den Kopf und sie fangen an sich aufzuspielen, weniger zu arbeiten und stattdessen mehr Geld zu verlangen. Zum Loben gehört also natürlich auch Tadeln ("Zuckerbrot und Peitsche"), das spielt auch in [B11] eine wichtige Rolle. In Notfällen und absolut dringenden Situationen kann es kurzzeitig sogar erforderlich sein, dass einer aus dem Team die absolute Führung übernimmt und bestimmt, wo es lang geht. Auch in den besten Projekten mit den bewährtesten Teams kann dies vorkommen, allein schon durch äußere Zwänge. Ich erinnere mich an ein Projekt einer Embedded Software (ein Betriebssystem eines Consumer-Produktes), bei dem die Produktion der Geräte Anfang der Woche angelaufen war und in der Folgewoche die Chips mit der Software eingesetzt werden sollten. Natürlich wurde Ende der Woche ein schwerwiegender Fehler gefunden ("Wenn etwas schief gehen kann, dann wird es auch schief gehen."). Also setzten wir uns Freitag nachmittag - gerade Zuhause angekommen - direkt wieder ins Flugzeug, um das ganze Wochenende durchzuarbeiten, damit am Montagmorgen die Chips mit der Software produziert werden konnten. Ansonsten hätten die Bänder im Produktionswerk gestoppt werden müssen! An diesem Wochenende hat aus Effizienzgründen genau einer gesagt, wer was wann wo tut! In solchen Momenten gelten die Regeln der christlichen Seefahrt: Es gibt genau einen Kapitän, und es wird gemacht, was dieser sagt - alles andere ist Meuterei! Und wie die bestraft wird, weiß ja jeder ;-)

In solchen schwierigen Situationen wird typischerweise nicht der Projektleiter das Sagen haben und evtl. nicht einmal der Teamleiter, sondern vielleicht eher eine Rolle, die gerne "DevLead" ("Development Leader", dt.: "Entwicklungsleiter") genannt wird. Dies wird der erfahrenste, respektierteste und fitteste Entwickler des Teams sein. Dennoch sind Projektleiter und Teamleiter natürlich in so einem Moment zugegen, koordinieren unterstützend Aktivitäten und Kommunikation, lösen einzelne Konflikte und holen die Pizza!

Auch wenn es gerade nicht brennt und demzufolge auch nichts gelöscht werden muss, sollten Sitzungen von Projektlenkungskreisen und Projektsteuerungsgremien stattfinden. Diese Routinen sollten zu Beginn des Projekts durch Vorstellung im Kick-Off-Meeting etabliert und wirklich in einem festen Tournus durchgeführt werden. Alle Leute der Verantwortungsmatrix sollten daran teilnehmen. In diesen Sitzungen wird natürlich ein Sachstandbericht zum Projekt geliefert, die Pläne werden kontrolliert und projektgefährdende Probleme werden signalisiert, damit gemeinsam eine Lösung gefunden werden kann. Typischerweise werden übergreifende, ganzheitliche Probleme diskutiert und gelöst, lokale dagegen nur angeschnitten und delegiert. Wichtig ist, dass die gesamte Verantwortungsmatrix große Probleme frühzeitig signalisiert bekommt (am besten gleich mit mehreren Lösungsansätzen), denn nur so kann das Vertrauen in der gesamten Matrix aufgebaut und erhalten werden. Offenheit und Fairness ist in der Verantwortungsmatrix genauso wichtig wie im Entwicklungsteam oder auch im Fachteam.

Wovon ich persönlich überhaupt nichts halte, sind diese Routinen in Entwicklerteams, die womöglich sogar zweimal wöchentlich mit allen zwanzig Entwicklern stattfinden. Da werden die wesentlichen Probleme eh nicht angesprochen, weil man diese nicht in einer solchen Gruppe diskutieren kann. Demzufolge werden da auch keine wesentlichen Entscheidungen getroffen. Also kann man sich den Quark auch gleich sparen! Man sollte sich einfach mal ausrechnen, wieviel Personenstunden da in schlechter Luft auf heißen Kohlen verbracht werden, dann kommt man schnell zu dem Schluss, dass einen dieser Aktionismus nicht weiter bringt. Operative Hektik ersetzt hier geistige Windstille! Dann doch lieber ein wöchentliches Projektfrühstück, zu dem jeder was Leckeres mitbringt. Dabei werden dann zwischendurch von ganz allein in kleinen Grüppchen auch mal die Probleme besprochen, die auf den Nägeln brennen. Wenn Projektleiter und Teamleiter da nicht auf den Ohren sitzen, erfahren sie die wichtigen Sachen, ohne danach fragen zu müssen - vor allem die Stimmung im Team!

Lesen Sie doch auch mal die Reports aus dem Windows 2000 Team von Microsoft, z.B.: "What the Boss Should Know".