Montag, 26. August 2013

Schon Vorhandenes nutzen wäre schneller gewesen

Praktisches Beispiel 1.5

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. Beispielcode
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Mehrfach haben wir schon auf Apache Commons CLI library hingewiesen. Endlich befassen wir uns mit der Verwendung von Open Source. Welche Schritte müssen wir gehen? Was müssen wir tun? Gibt es Gefahren? Diese und andere Fragen streifen unstrukturiert durch unser Hirn und bedürfen eines geordneten Weges.

Grundsätzlich müssen wir drei wesentliche Dinge klären, bevor wir Open Source in unserem Projekt verwenden dürfen.
  1. Erfüllt das Open Source Projekt unsere Anforderungen bzw. unsere wesentlichen Anforderungen und lässt sich der Rest durch einfaches Customizing ergänzen?
  2. Welche Auswirkungen hat das Lizenzmodell des Open Source Projektes auf unser Projekt und können wir damit leben?
  3. Steht hinter diesem Open Source Projekt eine Community, die lebt und die auf eventuelle Probleme schnell reagieren kann?


Ein übersichtliches Mittel für die Entscheidungsfindung ist die Entscheidungsmatrix. Diese Form der Dokumentation ermöglicht es auch später, die getroffene Entscheidung nachzuvollziehen.

Produkt 1 Produkt 2 Produkt 3
Anforderung 1
Anforderung 2
Anforderung 3


Unter der Tabelle sollte die getroffene Entscheidung kurz beschrieben werden. Dinge, gegen die man sich entschieden hat und bei denen aus der Entscheidungsmatrix diese Entscheidung nur schwer nachzuvollziehen ist, sollten näher erläutert werden.

Apache Commons CLI library findet man im Internet. Die Library wird verwendet, um die Übergabeparameter in Kommandozeilenapplikationen zu parsen. Die einzelnen Optionen werden erkannt und ggf. dazu gehörige Argumente. Damit wird die Hauptanforderung an die Kommandozeilenauswertung für unser Programm erfüllt.

Die Software wird unter der Apache-Lizenz vertrieben. Anhand der Lizenzdebingungen , aber auch unter Apache-Lizenz kann man nachlesen, ob man mit den Bedingungen einverstanden ist und die Software einsetzen will.

Unter commons-cli findet sich eine recht aktive Website, was darauf hindeutet, dass man das Ganze gut verwenden kann. Auf eine tiefere Suche, ob die Community wirklich sehr aktiv ist, wurde hier verzichtet. Bei anderen Projekten, die keinen Beispielcharakter besitzen, müsste dieser Schritt jedoch vollzogen werden.

Lars Wunderlich gibt in seinem Buch [S.23-24, WUND05] die folgenden Faktoren an, die es beim Einsatz von Open Source zu bedenken gilt:
  • Kostenfaktoren (senkt die Kosten um 20-30 % laut Marktstudien)
  • Konkurrenzfähigkeit
  • Modifizierbarkeit
  • Fehler in Open Source ? (Prüfe die Buglisten!)
  • Bindung an eine Architektur / einen Anbieter
  • Weiterentwicklung (Achte darauf, dass das Projekt noch lebt!)
  • Dokumentation (Diese wird oft vernachlässigt!)
  • Service Level Agreements (Wie kann ich SLA's gewähren, wenn mir keine angeboten werden?)
  • Lizenzmodelle


Bei den Lizenzmodellen sollte auf die folgenden Fragen geachtet werden:"
  • Kombination mit kommerziellen Produkten erlaubt?
  • Eigene Modifikationen müssen wiederum Open Source sein?
  • Veröffentlichungen unter anderen Bedingungen erlaubt?
  • Besondere Rolle für den Lizenzinhaber inkludiert?
" [S.24, WUND05]

Die Frage, ob man etwas selbst entwickelt oder ob man ein Drittprodukt benutzt ist, letztendlich eine Kostenfrage. Wie dargestellt, sollte man dabei jedoch eine Vielzahl von Punkten beachten und sich die Antwort nicht zu leicht machen. Bei Open Source Projekten "sind die wesentlichen Kostentreiber der Anpassungsaufwand (Customizing) und der fehlende professionelle Support für Wartung und Weiterentwicklung. Man ist hier grundsätzlich auf die Gemeinschaft (Community) angewiesen und sollte daher in kritischen Projekten nicht auf sogenannte Inkubatorprojekte (Projekte, die technisch und organisatorisch noch nicht in einem stabilen Zustand sind), sondern auf stabile Projekte mit nachgewiesener langfristiger Unterstützung durch die Gemeinschaft setzen." [S.147, GRECH10]

Nachdem wir uns einige Gedanken über das "ja" oder "nein" der Verwendung gemacht und uns entschieden haben es zu wagen, einige Architekturentscheidungen zum Einbau der Open Source Library. Eine wichtige Entscheidung ist das Separieren des Zugriffes auf die Library. In unserem Beispielprojekt wird der ParameterParser durch eine ParameterParserFactory erzeugt. In dieser kann man zwischen einer eigenen und der Apache Commons CLI Variante wählen. Ein Creator baut dann den entsprechenden ParameterParser. Der genauen Hintergrund dieses Entwurfs kann man im Post Das Factory Pattern – Glaube und Wirklichkeit – Teil 1 nachlesen.

Möchten wir später doch eine andere Library eigener, kommerzieller oder nichtkommerzieller Art einbauen, ist das Herauslösen des Codes ein Einfaches. Wäre der Code mit unserer Businesslogik verwoben, hätten wir das Problem des Herauspickens und müssten den ganzen Code eigentlich neu schreiben. Den Code werde ich in einen weiteren Post auslagern, da ich noch ein kleines Refactoring [:-)] durchführen möchte. Er genügt vielleicht nicht allen Anforderungen des erfolgten Requirements Engineering, aber ich möchte ihn dem Leser auch nicht vorenthalten. Über Twitter (Baumann63Ralf) oder durch ein einfaches Nachsehen in wenigen Tagen kann man ihn dann in meinem Blog finden.

Da sich genau 13 Personen dazu entschieden haben, also mit mir eigentlich 14, werde ich noch einen weiteren Post hinzufügen. In diesem letzten Teil meiner Reengineering-Reihe werde ich mich mit dem folgenden Thema befassen: Es existiert nur noch eine Schnittstelle. Auf dieser Grundlage gilt es ein Reengineering durchzuführen. Fragt sich natürlich, ob man Code umbauen kann, den man nicht mehr hat?

  • [GRECH10] : Thomas Grechening, Mario Bernhart, Roland Breiteneder, Karin Kappel: "Softwaretechnik", Pearson Studium, 2010
  • [WUND05] : Lars Wunderlich: "Software Architekturen in Java – Modelle, Techniken, Praxis", mitp-Verlag, 1.Auflage, 2005


Habe den Beispielcode für diesen Artikel hier eingestellt.

In der Xing-Gruppe Clean Code Developer schrieb Jörg Rückert in einem Kommentar:

"zunächst einmal wären wir ohne Open Source Software sicherlich nicht dort wo wir heute sind. Die Open Source Community leistet sehr viel!

Entwicklungsumgebungen, Applikationsserver, Messaging Systeme und dutzende von Frameworks sind im Rahmen entsprechender Open Source Lizenzen frei verfügbar. Die Open Source Bewegung hat wesentlich dazu beigetragen, dass ein Umdenken bei den Softwareherstellern stattgefunden hat. Ein gutes Beispiel ist der Java Community Process (JCP), der die Standardisierung im Java-Umfeld deutlich prägt.
"

Dem kann ich mich nur anschließen. Ich möchte hier nicht gegen Open Source argumentieren. Es geht mir um ein überlegtes Handeln im Umgang mit Open Source.

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. > drei wesentliche Dinge klären, bevor wir Open Source in unserem Projekt verwenden dürfen.

    > 2. Welche Auswirkungen hat das Lizenzmodell des Open Source Projektes auf unser Projekt und können wir damit leben?

    Ein sehr wichtiger Punkt, der in der Praxis in den Projekten, in denen ich Einblick hatte/habe, so gut wie garnicht berücksichtigt wird.

    Leider erlebe ich dies im KMU-, (Groß-) Konzern- und auch Behörden-Umfeld.

    Es ist schlicht keine Kompetenz vorhanden, dies zu beurteilen. Alle Augen werden zugedrückt. Die Wichtigkeit und die möglichen Konsequenzen werden nicht gesehen.

    CU
    Boeffi

    AntwortenLöschen
  2. > 3. Steht hinter diesem Open Source Projekt eine Community, die lebt und die auf eventuelle Probleme schnell reagieren kann?

    Ich bin leidenschaftlicher Verfechter von Open Source-Projekten...

    Aber leidenschaftlich liegt auch nahe bei "leiden"-schaffend - selbst bei Open Source-Projekten, mit großer, aktiver Community.

    Bei der Verwendung von Open Source sollte klar sein, dass "man auch selbst mal ran muss", wenn es beim Einsatz Probleme gibt und man auf Bugs stößt.

    Dies kann mit durchaus beträchtlichen Aufwänden verbunden sein. In der meist nicht-trivialen Komplexität der Open Source-Projekte Bugs zu finden und zu beheben, bedarf schon einiges an KnowHow, Engagement und Resourcen (Zeit, Budget, ...) - dies habe ich schon mehrfach am eigenen Leib gespürt.

    Und das ganze im Spannungsfeld von SLA.

    Das Positive daran ist, dass man nicht nur nimmt, sondern der Community auch etwas zurückgeben kann!

    (dieses Mindset muss man allerdings manchmal auch mühsam mit dem "Leiter Softwareentwicklung" diskutieren, wenn es darum geht ein Budget dafür zu Verfügung zu stellen)

    CU
    Boeffi

    AntwortenLöschen
  3. > Ein übersichtliches Mittel für die Entscheidungsfindung ist die Entscheidungsmatrix

    Bewährt hat sich Anforderungen zu gewichten (Business Value, Risk Value, ...).

    Die Matrix kann über ein Tool abgebildet werden (z.B. Excel & Co.). So erhält man schnell eine Unterstützung (Priorisierung...) über z.B. eine Signifikanz-Kennzahl (zu einer Anforderung und über die Gesamtheit).

    CU
    Boeffi

    AntwortenLöschen
  4. Ob man etwas selbst entwickelt oder vorhandenes nutzt ist nicht nur eine Kostenfrage.

    Oftmals ist es auch eine Frage der Fähigkeit etwas selbst zu entwickeln in einem Gebiet wo man kein Experte ist. Dieser Aspekt wird leider oftmals unterschätzt und man entwickelt eigene Frickelware, die die Qualität eines Drittanbieters selten erreicht. Z.B. eigene CSV-Parser die das CSV-Format nur zu 90% unterstützen, Build-Systeme basierend auf Windows Batch-Files usw...

    Manchmal ist es aber auch die Ungewohnheit der Entwickler zu recherchieren, oder auch mangelnde Englishkenntnisse, die eine Recherche behindern. Das führt zu einer Neigung selbs zu machen - das Not Invented Here Syndrom.

    Anderseits gibt es auch Frameworks und Libraries, die annehmen dass sie das Zentrum des Universums sind und zu invasiv Vererbungschierarchien oder bestimmte Strukturen der Files vorschreiben. Da lässt man eher bewusst die Finger weg und macht es selbst..

    AntwortenLöschen