Montag, 17. Juni 2013

Reengineering - Die Analyse des Altcodes

Praktisches Beispiel 1.1

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.


Während eines Reengineering ist mir folgender Code, in ähnlicher Form, wirklich begegnet. Natürlich habe ich ihn abgeändert, denn es ist nicht meine Absicht, jemanden an den Pranger zu stellen. Meiner Meinung nach kommt es auch nicht aus Unfähigkeit zu solchem Code. Meist ist es die fehlende Zusammenarbeit im Team. Deshalb plädiere ich für eine andere Form der Zusammenarbeit. Im einzelnen sehe ich folgende Gründe:
  • Die Programmierer sind verzweifelte Einzelkämpfer.
  • Es gibt keine fairen Codereviews.
  • Die Architektur des Projektes wurde nie kommuniziert.
  • Es werden keine Qualitätsmanagementtools verwendet (z.B. Sonar).
  • Die Ergebnisse des Qualitätsmanagementtools werden nicht diskutiert.
  • Die Anforderungen sind nie wirklich ermittelt und vermittelt worden.
  • Es gibt gar keine Architektur, gegen die implementiert wurde.
  • Das Projektmanagement betätigt sich als Sklaventreiber.
  • Qualitätsmanagement ist ein Fremdwort.
Es gibt wahrscheinlich weitere Gründe, die dazu führen, dass man Spaghetticode entwickelt. Wer die angeführten Gründe akzeptiert, sieht schnell ein, dass viele der Gründe in einer aufgehobenen Teamarbeit liegen. Teamarbeit ist aber nur unter bestimmten Bedingungen wirklich möglich. Ein Team ist keine religiöse Sekte, der ein Guru vorsitzt und die nur aufgrund seiner Unfehlbarkeit zu erstklassigen Ergebnissen kommt. Ein gutes Team ist wie ein Orchester. Es setzt sich aus den unterschiedlichsten Begabungen zusammen, die nur dann harmonieren, wenn keiner die anderen erdrückt und Achtung vor dem Anderen Grundlage jeder Arbeit ist.

Jetzt der fiktive Code, der die Ausgangsbasis für die weitere Diskussion bildet. Die System.out-Zeilen können durch beliebige Logger-Ausgaben ersetzt werden.



Zu diesem Code gibt es keine Beschreibung der Anforderungen. Im Pflichtenheft steht nur der kurze Satz:

Es ist ein Kommandozeilentool zu schaffen, das die Berechnung aller Bestellungen in der Datenbank pro Kunde und Monat zusammenfasst. Es kann auch eine Vorhersage für die nächsten Monate erstellt werden.

Ein Reengineering dieses Codes ergibt eine Reihe von Annahmen, die Anforderungen sein könnten. Es ist genauso möglich, Programmier- bzw. Architekturfehler als Anforderungen zu analysieren. Deshalb ist ein genaues Reflektieren der gefundenen Annahmen notwendig.

Im Folgenden steht ein Auszug aus der Liste der gefundenen Annahmen:
  • Wenn keine Parameter übergeben werden, startet der BestellGenerator eine Berechnung über alle Bestellungen für alle Kunden pro Monat.
  • Wenn nur ein Parameter angegeben wird, kann das -forecast oder etwas beliebig anderes sein.
    • Ist es etwas beliebig anderes (z.B. auch -nichtrechnung), wird der BestellGenerator für eine Berechnung über alle Bestellungen für alle Kunden pro Monat gestartet.
    • Ist als Parameter -forecast angegeben wird eine Vorhersage für alle Bestellungen aller Kunden pro Monat gestartet. Um welchen Zeitraum es sich dabei handelt bleibt offen.
  • Bei zwei Parametern kann der Bestellgenerator nur für eine Berechnung der Bestellungen durchgeführt werden.
    • Dabei wird die Berechnung nur für -costumer ausgeführt. Das heißt die Berechnung erfolgt nur für den angegebenen Kunden mit der angegebenen Kundennummer.
    • Oder es wird die Berechnung nur für -month ausgeführt. Dabei ist die große Frage, was das bedeutet.
Ich möchte hier die Analyse der Annahmen abbrechen. Zu einer vollständigen Analyse gehört die vollständige Aufnahme aller Anforderungsquellen. Wir verfügen zum jetzigen Zeitpunkt über den Altcode und über das Pflichtenheft. Leider zeigen gewisse Annahmen recht deutlich, dass die ursprünglichen Absichten kaum noch zu erkennen sind. Führt auch eine Analyse des weiteren Codes (eine sehr aufwendige Aufgabe) nicht zu eindeutigen Ergebnissen, so sind vielleicht noch Altprogrammierer vorhanden, mit denen man eine fruchtbare und achtungsvolle Diskussion beginnen kann. Noch besser ist die Befragung des Nutzers, der das Tool verwendet.

Im nächsten Post möchte ich das Ergebnis der Anforderungsanalyse zu diesem Stück Code zeigen.

folgender Post dieses Themas


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

Keine Kommentare:

Kommentar veröffentlichen