Dienstag, 6. August 2013

Reengineering - Neu, strukturiert und auf lange Sicht schneller

Praktisches Beispiel 1.4

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Ignorieren wir einfach die Apache Commons CLI library und gehen wir davon aus, es gibt keine Implementierung für unser Vorhaben. Dann müssten wir uns hinsetzen und anhand der Anforderungen und des Architekturentwurfs codieren. An diesem Punkt kehren wir in der Diskussion an unseren Ausgangspunkt zurück. Die Mehrheit ist vielleicht meiner Meinung, dass wir jetzt in der Lage sind, einen qualitativ hochwertigeren Code zu schreiben. Doch das Schreiben von Software außerhalb universitärer Strukturen ist auch ein ökonomischer Prozess. Und genau diese Ökonomie steht in Frage. Haben wir nicht viel mehr Zeit verbraucht?

Wir benötigten ein Meeting für die Analyse des Altcodes, ein Meeting für das Ermitteln von Anforderungen und noch eines für den Architekturentwurf. Mit dem sofortigen Herunterschreiben des Codes hätten wir uns das alles erspart. Wirklich? Hätten wir nicht auch Zeit benötigt für das Verstehen des Altcodes und für das Neuordnen? Wären wir nicht viel unsystematischer gewesen? Doch ausschlaggebend sind die folgenden Argumente:

  • Es würde wieder keine systematische Dokumentation vorliegen, die den Zeitaufwand für Bugfixing und Change Requests in Zukunft auf ein erträgliches Maß einschränken kann.
  • Es werden wieder Codestrecken entstehen, die kaum wartbar sind und somit erheblichen Pflegebedarf benötigen.
  • Die Kommunikation im Team ist auf der Strecke geblieben, und das Wissen steckt in den Geheimratsecken Einzelner.


Das sind Argumente, die uns in der Arbeit zu einer anderen Zusammenarbeit geführt haben. Sie erscheint uns ökonomischer und menschlicher zugleich. Selbst beim Programmieren sind wir oft zu zweit. Wenn einer jedoch mal Spaß an der Arbeit in der stillen Ecke hat, dann gibt es Codereviews. Diese haben nicht nur das Ziel der Codeverbesserung. Hier wird auch der Code bekannt gemacht, es werden allgemein verständliche Namen für Klassen, Attribute und Methoden gefunden. Es wird geprüft, ob die Architekturregeln eingehalten werden. Dazu wird auch ein Blick auf Sonar geworfen. Dieses Werkzeug für die Prüfung von Architekturmetriken ist eine gute Ausgangslage für eine tiefgreifende Diskussion, es ist jedoch kein Selbstzweck zum Spiegeln langweiliger Zahlenwerte.

Der Vorteil der Kommunikation steht für mich außer Frage. Dabei ist es wichtig, in einer Atmosphäre der gegenseitigen Achtung, der höflichen Kritik und des angstfreien Zugebens von Fehlern zu arbeiten. Der Zeitvorteil ist eher eine subjektive Annahme. Ich kenne Projekte, die im Zeitplan fertiggestellt wurden und bei denen man mehr als das Doppelte in Bugfixing stecken musste. Diese Zeit wurde niemals ökonomisch erfasst, und somit konnte das Argument für ein systematisches Requirements Engineering und einen guten Architekturentwurf nicht gestärkt werden. Auch steht uns hier das kurzfristige Denken oftmals im Wege, wo auf lange Sicht ein langfristiges Denken besser gewesen wäre. Leider scheint sich dieses Denken auch auf Managementebene sehr festgesetzt zu haben.

Wenn die Verzweiflung über den Altcode zu groß wird, neigt die Programmierergemeinde zum Wegwerfen des Alten. Das geht oftmals auch wirklich schneller. Aber wieder wird auf Anforderungen, Architektur und Kommunikation verzichtet. Gestärkt wird dieses Verhalten durch technisch geschultes Leitungspotential, dessen Soft Skills nicht ausgebildet oder verkümmert sind.

Zum Abschluss dieses Post stelle ich einen Teil des Codes vor, wie er in diesem kleinen Projekt implementiert hätte werden können. Er ist schon um einiges besser als die Ausgangssituation. Vor allem ist er aber mit seinen Anforderungen, seiner Architektur und im Code dokumentiert. Noch viel besser wäre er geworden, wenn die vielen, die jetzt darauf gucken, dazu hätten beitragen können. Damit spreche ich eine große Angst aus, die oft verhindert, dass wir uns über die Jahre schneller entwickeln und besseren Code schreiben. Wir fürchten uns vor Kritik. Vor schreiender, besserwisserischer Kritik kann man sich auch fürchten. Im höhnischen Gelächter gehen viele gute Ideen unter. Gute Kritik kommt höflich daher, macht niemanden als Menschen nieder, sondern verbessert das Kritisierte aus der Sicht des Kritikers.

Die Main des Bestellgenerators.



Den ParameterParser und die ParameterParserFactory gibt es in diesem Teil nicht zu sehen. Am 11. August erscheint in meinem Blog ein Post über das Factory Pattern, so dass man die Factory leicht anhand dieser Diskussion bauen kann und der ParameterParser wird wegen der Apache Commons CLI library sowieso nochmals umgebaut.

Die Startbedingungen des Bestellgenerators.



Eine Andeutung der späteren Logik.



Einen Teil des Codes veröffentliche ich also noch in den nächsten Posts. Dort befasse ich mich auch mit der Verwendung der Apache Commons CLI library. Damit besteht die Möglichkeit, auf dem Wissen einer Community aufzubauen. Doch dazu mehr im vorletzten Post zum Reengineering.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Kritik? Kein Problem. Können wir uns bitte auf eine schwarze Schrift auf weißem Untergrund einigen? Oder wenigstens auf eine halbwegs ergonomische dunkel(!)graue auf weiß?

    AntwortenLöschen
  2. Habe eine Umfrage dazu gestartet und würde das Layout umsetzen. Der "Printer Frindly and PDF"-Button erlaubt auch eine schwarze Schrift mit weißem Untergrund und das Speichern. Nochmals vielen Dank für den Hinweis!

    AntwortenLöschen