0100 1001 0010 0011 0101 0111 1000 0001 0110
Der zeitnahe Build nach Code Änderungen und die Durchführung von Komponenten-Tests lassen die Ursache von Fehlern und die Auswirkungen der Änderungen auf das funktionale Verhalten einer Anwendung schnell erkennen und rechtzeitig beheben. Wird dies automatisiert, so ist Continuous Integration gegeben:
Jenkins / Hudson ist ein Java Open Source Projekt mit einer Web-basierten Plattform für Continuous Integration. Jenkins kann mit einem einzeiligen Aufruf auf der Kommandozeile gestartet werden. Benutzt das Projekt bereits Maven und SVN, kann die weitere Konfiguration in wenigen Minuten abgeschlossen werden. Da Builds auch über beliebige Batch Skripts gestartet werden können, lassen sich auch andere Projekte - und eben auch nicht Java-basierte Projekte - problemlos einbinden. Über Plugins wird die Funktionalität erweitert, und es lassen sich auch andere Versionskontrollsysteme als SVN anbinden.
Als Build Server genügt ein einfacher Entwicklungsrechner mit installiertem JDK. Der Rechner sollte allerdings dediziert nur für diesen Zweck eingesetzt werden, da das Compilieren sehr Prozessor-lastig ist. Eine Installation in einer virtualisierten Umgebung (VirtualBox, VMWare) ist ebenfalls möglich. Sollte ein Build viel mehr Ressourcen benötigen, so läßt Jenkins sich auch als Cluster betreiben.
In den Vorgehensweisen nach dem klassischen Wasserfallmodell durchlaufen die Projekte nacheinander die jeweiligen Phasen. Insbesondere beginnt die Software-Entwicklung auch erst, wenn die vollständige Spezifikation erstellt ist. Integrations- und Systemtests erfolgen erst zum Projektende.
Dabei treten oft typische Schwierigkeiten auf, die zu Zeitverzug und Akzeptanzproblemen führen können. Agile Entwicklungsmethoden versuchen, diesen Schwierigkeiten zu begegnen:
Ob und welche agile Methode geeignet ist, muß abhängig von Projektsituation, Erfahrungsstand des Projektteams und der verfügbaren Ressourcen entschieden werden. Scrum eignet sich zum Beispiel, sofern Projekt- und Funktionsumfang schon relativ gut bekannt sind. XP ist bei viel unbestimmterer Ausgangslage möglicherweise besser. Sind Ressourcen eng begrenzt oder wird ein vorhandenes System im Rahmen der Wartung erweitert, so kann Kanban ein guter Ansatz sein.
So ist also für jedes Projektumfeld und je nach Kontext eine agile Methode auszuwählen und im jeweilig angebrachtem Umfang umzusetzen. Gerade auch die schrittweise Einführung von Teilaspekten kann dabei Vorteile gegenüber einem radikalen Paradigma-Wechsel haben.
Softwarequalität läßt sich durch manuelle Reviews und Software-basierte Verfahren (den Code Metriken) prüfen und verbessern. Damit kann Fehleranfälligkeit und Wartungsaufwand bereits während der Entwicklung reduziert werden. Dieses gilt nicht allein für den Programmcode, sondern auch schon für die gewählte Architektur.
Ist die gewählte Architektur dem Zweck angemessen? Ist ein einfacherer Ansatz gegenüber unnötig komplexen Ansätzen möglich? Kann eine Aufteilung in kleinere, unabhängig von einander zu testenden und zu wartenden Komponenten vorgenommen werden? Wie sieht es mit einem REST (Representational State Transfer) Ansatz aus? Sind Microservices mit jeweils dedizierter Infrastruktur ein Konzept zur Modularisierung einer komplexen Anwendung?
Werden die Daten so modelliert, wie sie später von der Anwendung gelesen und geschrieben werden? Werden einheitliche Datentypen verwendet? Können sinnvolle Views definiert werden? Z. B. ist der Zugriff auf eine View mit komplexen Joins performanter als die Joins per SQL direkt auszuführen.
Code Metriken können nicht alles abprüfen, ein manueller Blick in den Sourcecode ist zusätzlich sinnvoll - und nebenbei können so auch Erfahrungen weitergegeben.
Mit Code Metriken kann Softwarequalität definiert und gemessen werden. Der Umfang und die genaue Ausprägung sind dabei jeweils von Fall zu Fall festzulegen. Bei Einführung dieser Qualitätsmaßnahmen sollte erst nur mit wenigen Punkten begonnen werden.
Ein derartiges Vorgehen folgt der Goal-Question-Metric Methode: Was ist das Ziel der Maßnahme? Was soll damit gemessen werden? Welche Metrik ist dazu geeignet?.
Einige wichtige Kriterien sind dabei:
Lesbarkeit des Sourcecodes:
Hiermit kann vor allem die Wartbarkeit der Software verbessert werden. Welche Werte dabei akzeptabel sind, wird im Einzelfall festgelegt - Metriken hierzu:
Wert [in %] =
Anzahl Kommentarzeilen / (Anzahl Codezeilen+Anzahl Kommentarzeilen) * 100
Wert [in %] = 100 - Anzahl Verletzungen / Anzahl Codezeilen * 100
Wert [in %] = Anzahl duplizierte Zeilen / Anzahl Codezeilen * 100
Komplexität der Software:
Mit der Komplexität nimmt die Fehleranfälligkeit einer Software zu. Gleichzeitig sinken Wartbarkeit und auch Testbarkeit - Metriken hierzu:
Mittelwert = Summe der zyklomatischen Komplexitäten aller Methoden / Anzahl der Methoden
Anzahl Codezeilen)
durchschnittliche Vererbungstiefe einer Klasse =
Summe der Vererbungstiefe aller Klassen / Anzahl aller Klassen
Coupling = Summe benutzter Klassen pro Klasse / Anzahl aller Klassen
Fehlerfreiheit der Software:
Dieses Maß gibt Auskunft über die tatsächliche Funktionalität der Software - Messung über:
(Anzahl Tests - Anzahl fehlerhafter Tests) / Anzahl Tests * 100
Liegen Daten strukturiert als XML Dokument vor, kann diese Quelle in unterschiedliche Formate zur Weitergabe an verschiedene Empfänger umgewandelt werden. Da es nur eine Quelle gibt, ist dabei auch sichergestellt, dass die Datenbasis immer exakt gleich ist.
Die Umwandlungen können mit XML Stylesheets (XSL) vorgenommen werden, das nur einmal festgelegt werden muß. Die Ausgabe in ein Maschinen-lesbares Format - XML ist das natürlich selbst schon - ebenso wie in ein HTML Dokument zur Anzeige im Webbrowser oder für den Mailversand ist möglich. Das XSL definiert das Layout und enthält Platzhalter für die konkreten Daten aus dem XML Dokumemt.
Mit Hilfe des Java-basierte Open Source Projekt Apache FOP kann insbesondere mittels XSL-Transformation auch PDF erzeugt werden.
Zur Dokumentation von Anwendungen und APIs bietet Java seit Beginn Javadoc. Hier werden direkt im Source Code Klassen, Methoden und Attribute mit der Besschreibung annotiert. Der Javadoc Prozessor generiert daraus eine HTML-basierte Dokumentation. Javadoc richtet sich als Dokumentation nicht nur an die Entwicklung (Weiterentwicklung und Wartung), sondern kann auch die technische Dokumentation bilden.
Obwohl Javadoc schon Jahrzehnte vorhanden ist, wird diese Dokumentationsmöglichkeit selten oder falsch genutzt:
TODO ("mache ich irgendwann später", sagt sich der Entwickler und tut es nie) bis zur Wiederholung des Attributnamens.
@param: Hiermit werden die Parameter der Methoden kommentiert. In Eclipse etzeugt dies der Wizard und hängt den Parameternamen an. Fertig? Es fehlt natürlich noch der Beschreibungstext. Dabei ist zu beachten: das erste Wort dieses Beschreibungstextes - also die Zeichenkette vor dem ersten Leerzeichen - wird als Datentyp von Javadoc interpretiert. Dies wird in den Übersichtstabellen eingetragen. Also: @param Parametername Datentyp und jetzt der Beschreibungstext.
@return: Dies ist der Kommentar für den Rückgabeparameter einer Methode: @return Datentyp und jetzt der Beschreibungstext.
@throws Exceptionklasse und jetzt der Beschreibungstext, wann und warum die Ausnahme auftreten kann.
package.html zu erstellen. Diese enthält natürlich die Beschreibung als HTML (der Inhalt des body).
Javadoc ist zunächst spezifisch für Java. Aber nach diesem Beispiel haben sich entsprechende Kommentierungen entwickelt für PHP, C++, C# ... Hier kann der Ersatz für den Javadoc Prozessor nicht so leistungsfähig sein. Aber ein derartiger Prozessor läßt sich einfach einmalig erstellen.
Vorbemerkung: Nachfolgend kann sich Dokumentation hier sowohl auf die Dokumentation einer Anwendung als auch einer fachlichen Spezifikation beziehen oder auch auf sonstige andere Inhalte, die das Erstellen eines umfangreichen Dokuments erforderlich machen.
Fachliche und technisches Spezifikationen können auch in einem Wiki, also als Webseiten, geschrieben werden. Doch warum sollte man das tun?
Typischerweise werden Dokumentaionen mit MS Word estellt. Die Gründe sind klar:
Doch in der Praxis ergibt sich eine Vielzahl von Problemen, die nur mit der Raison des ersten Punktes akzeptiert werden - und die das Management nicht zu sehen bekommt. Welche Schwierigkeiten treten konkret auf?
Die Dokumentation erfolgt in einem Wiki.
Hierfür wird eine Wiki Software benötigt mit eigener Versionskontrolle oder der Anbindung an ein vorhandenes System wie z. B. Subversion, Textvergleich und Benutzerverwaltung. Dies bieten die meisten Wikis an, beispielsweise MediaWiki (das Wiki der Wikipedia), DokuWiki, JSPWiki, Confluence (Atlassian) (mit kommerziellen Support).
Aber wie wird hieraus jetzt ein Dokument?
Ähnlich wie eine Suchmaschine das Web indiziert, wird hier eine spezielle Software auf die Startseite der Dokumentation im Wiki angesetzt. Dieser Crawler generiert dann das vollständige Dokument.
Der Start des Crawler kann manuell oder auch zeitgesteuert automatisiert erfolgen.
Die Vorgehensweise des Crawler ist wie folgt:
Der Crawler erstellt zunächst eine XML Datei, die alle für das zu generierende Dokument erforderliche Informationen enthält. Dieses XML wird dann mit einem XSL Stylesheet in das endgültige Ausgabeformat transformiert, z. B. HTML oder PDF. Die auf diese Weise generierte Dokumentdatei kann dann - auch automatisiert - in einem Versionskontrollsystem abgelegt werden.
Insbsondere kann auch die XML Datei versioniert werden, bei der Änderungen leicht mit einem Textvergleich erkennbar sind. Eine erstellte und versionierte PDF Datei bildet einen definierten Stand, der so dokumentiert auch an den Kunden gegeben werden kann.
Dieser Lösungsansatz erfolgt bewußt nicht auf Basis eines Plugin, um unabhängig von dem jeweilig eingesetztem Wiki zu sein.
FIT ist das Framework for Integrated Testing. Dieses Testframework bietet Komponenten- und Integrationstests. Das Framework ist eine Java Anwendung. Testcode ist ebenfalls in Java - ähnlich wie JUnit Klassen - zu implementieren.
Bei FIT werden Testdaten und Testaufrufe in der Testdokumentation (auf Basis von Word, Excel, Wiki/HTML) tabellarisch eingebunden. Insbesondere sind hier auch die erwarteten Testergebnisse enthalten. Dieses Dokument dient dem Testframework als Eingabe. Nach manuellen - oder auch z. B. per Ant Skript automatisierten - Start werden die Testfälle mit den zugehörigen Eingabedaten programmatisch extrahiert und die korrespondierenden Testklassen aufgerufen. Die Testergebnisse werden in dem Eingabedokument - oder auch einer Kopie - eingetragen. Insbesondere wird dabei der Erfolg (Übereinstimmung mit dem erwarteten Ergebnis) oder Fehlschlag festgehalten.
Auf diese Weise kann mit FIT der Fachbereich Testszenarien und sinnvolle Testdaten erfassen. Gleichzeitig wird jeder Testlauf und dessen Ergebnis dokumentiert (und archiviert).
Außerdem ist es insbesondere auch nicht-technischen Mitarbeitern möglich, Funktionalität einer Anwendung bereits zu testen, ohne dass eine Benutzeroberfläche vorhanden ist.
Ein Testszenario besteht aus dem Laden von Testdaten (Klasse test.LoadTestData mit Aufruf der Methode load()) und der anschließenden Verarbeitung (Aufruf der Methoden checkResult() und checkOtherResult() der Klasse test.ProcessTestData). Das Testdokumemt enthält im beschreibenden Text dazu die Tabellen:
| test.LoadTestData | |||
|---|---|---|---|
| attribute 1 | attribute 2 | ... | load() |
| value 1 | value 3 | ... | |
| value 2 | value 4 | ... | |
| ... | ... | ... | |
| fit.ActionFixture | ||
|---|---|---|
| process | test.ProcessTestdata | |
| check | check result | expected result value 1 |
| check | check other result | expected result value 2 |
| ... | ... | ... |
Nach dem Testlauf sind im Erfolgsfall die Tabellenzellen grün hinterlegt oder bei Fehlern rot, also zum Beispiel:
| test.LoadTestData | |||
|---|---|---|---|
| attribute 1 | attribute 2 | ... | load() |
| value 1 | value 3 | ... | true |
| value 2 | value 4 | ... | true |
| ... | ... | ... | ... |
| fit.ActionFixture | ||
|---|---|---|
| process | test.ProcessTestdata | |
| check | check result | expected result value 1 |
| check | check other result | expected result value 2 (expected) some value (actual) |
| ... | ... | ... |
Gibt es eine Alternative zum Eclipse-basierten Rational Application Developer von IBM mit dem darin integrierten Websphere Application Server?
Der Umstieg auf die Open Source-Version von Eclipse ist problemlos möglich. Statt des integrierten Webspheres kann der separat zu installierende Websphere Standalone verwendet werden, der für die Entwicklung frei von Lizenzkosten ist. Es sind lediglich die folgenden Punkte umzustellen:
Mit einem solchen Umstieg lassen sich Lizenzkosten einsparen. Außerdem sind die Hardware Anforderungen nicht mehr so hoch. Die Entwicklungsumgebung mit dem reinen Eclipse reagiert zügiger, der Websphere Standalone startet bzw. aktualisiert die Anwendungen schneller.
Oft wird vorgeschlagen, die Entwicklungsumgebung zu virtualisieren z. B. mit VirtualBox. Als Argumente werden genannt:
Doch ist das wirklich so? Meine Erfahrungen aus einem Projekt mit etwa 150 Mitarbeitern:
"Einheitliche Arbeitsplätze"
Da die Images nur den gemeinsamen Anfangszustand haben, änderte sich das schnell ...
"Zeitersparnis bei Installation und neues Aufsetzen einfach möglich"
Tatsächlich wurde das Master Image niemals aktualisiert und war immer auf einem sehr alten Zustand ... Updates, neue Software und geänderte Konfigurationen waren so zeitaufwendig manuell nachzuziehen.
"Performante Entwicklungsrechner sind nicht erforderlich"
In der Praxis wurden (2015) Rechner mit 16GB Hauptspeicher, mehreren Prozessorkernen und SSD benötigt ... trotzdem blieben zeitverzögerte Reaktionen beim Zugriff und langsamer Bildschirm-Refresh bestehen. Auch eine virtualisierte Umgebung braucht die Ressourcen, die die Anwendungen benötigen. Einen performanteren Rechner als das Host-System virtuell zur Verfügung stellen zu wollen, wird immer scheitern.
Stattdessen die Images auf einem Remote System laufen lassen und nur die Oberfläche über das Netzwerk zu den Entwicklungsrechnern holen? Das geht, wenn man die Latenzen in Griff bekommt und das Netzwerk nicht ausfällt (bei 150 Mitarbeitern war das pro Stunde Ausfall ein Personen-Monat Verzug ...).
Die beiden ersten Punkte lassen sich natürlich durch Disziplin und guten Willen in den Griff bekommen. Aber ein technisches Hilfsmittel wie Virtualisierung allein hilft nicht.
Geht es nur darum, Installations- und Konfigurationsaufwand einzusparen, so kann auch auf "portable" Software und gezippte Installationen zugegriffen werden. Konfigurationen können in einem Versionskontrollsystem eingestellt werden, und alles wird in der richtigen Reihenfolge mit einem Skriptaufruf installiert.
Representational State Transfer (REST) ist ein Ansatz, die benutzte Technologie einer Anwendung und die Art des Aufrufs der zur Verfügung gestellten Services zu trennen.
Anfragen an ein RESTful System, also Interaktionen eines Anwenders oder Systemschnittstellen, werden über definierte URLs vorgenommen. Der Request-Type unterscheidet dabei lesende Zugriffe (GET für reine Abfrage von Daten) und schreibende (POST für neue oder geänderte Daten, DELETE für Löschungen). Unterschiedliche Ausgabeformate bei gleichem Aufruf werden über den akzeptierten Content-Type gesteuert (z. B. html für menschliche Benutzer, pdf für Reports, text (Flatfile) und xml (strukturierte Daten) für Maschinen-Schnittstellen).
Die Architektur eines Systems kann auf diese Weise wenig komplex und überschaubarer werden. Damit kann Entwicklungszeit reduziert und die Wartbarkeit verbessert werden, insbesondere bei wechselnden Entwicklerteams.
Doch ist dieser Ansatz gefährlich, wie an dieser Stelle - "restful considered harmful" - geschrieben wird? Die hervorgebrachten Argumente sind wenig überzeugend:
Warum soll bei REST auf die Dokumentation des Systems verzichtet werden?
Warum müssen Daten immer nur per JSON ausgetauscht werden?
Ist es wirklich besser bei Verwendung von Message Queues, statt ein System per URL zu exponieren, gegenüber Drittsystemen den Queue Manager erreichbar zu machen?
Eingabe-Validierung erfolge nicht automatisch, aber dies ist doch immer so? Auch wenn ein XSD definiert ist, muß die Validierung dagegen aufgerufen werden ...
Bei aller Leichtigkeit, mit der man heute das eigene Buch – in gedruckter oder elektronischer Form – veröffentlichen kann, sind dennoch einige Punkte zu bedenken, die vielleicht zu ein wenig Ernüchterung führen.
Hier möchte ich ein paar Gedanken zu meinen eigenen Erfahrungen in diesem Bereich vorstellen.
Die Vorlagen zur Herstellung eines gedruckten Buchs sind bei den meisten Anbietern PDF Dokumente. Dies gilt sowohl für den Buchblock, also den Textseiten des Buchinhalts selbst, als auch dem Cover. Die Gestaltung des Satzspiegels, also des Seitenlayouts, unterliegt dabei einer ganzen Reihe von Konventionen. Diesen liegt die Jahrhunderte lange Erfahrung zugrunde, was das Lesen eines Buchs tatsächlich angenehm macht. Sie haben durchaus ihre Berechtigung. Neben den Inhalten und den Gedanken, die ein Buch weitergeben möchte, ist somit auch der Textsatz eines Buchs von einiger Bedeutung. So leicht, wie ein Dokument zum Beispiel mit MS Word geschrieben werden kann, kommt dabei dennoch nicht immer auch ein vom Layout her anspruchsvolles Buch heraus. Und es ist wie überall: ein hässliches, aber funktional – oder bei Büchern: inhaltlich – hervorragendes Produkt bleibt trotzdem in den Läden liegen.
Textsatz spielt auch bei elektronischen Büchern eine Rolle. Hier kommt es aber nicht so sehr auf die ästhetische Gestaltung an – das übernehmen die Lesegeräte und Anwendungen selbst – als vielmehr auf eine durchgehend korrekte Strukturierung. Nur so kann ein Leseprogramm auch das Dokument optimal den Lesenden anzeigen.
Die Kosten für die Herstellung eines gedruckten Buchs sind relativ hoch. Bei einem realistischen Verkaufspreis bleiben da eher weniger als 15% Gewinnanteil als mehr. Amazons CreateSpace ist dabei der mit Abstand günstigste Hersteller.
Die Grundlage für die Einstellung eines Buchs in einem elektronischen Format ist – unabhängig von Verkaufsplattform oder Zielformat – weitgehend das standardisierte Format ePub. Hier liegt das Buch letztendlich als Webseiten vor, die in eine Archivdatei verpackt werden. Gegenüber PDF als Ausgangsformat ist nur im ePub die Kapitelstruktur eindeutig festgelegt – und ein direkter Kapitelzugriff ist für elektronische Bücher eine erwartete Komfortfunktion.
|
Ein typisches Problem:
Inhaltsverzeichnis ist erstellt, liegt klickbar im Dokument vor, ist korrekt in das ePub eingebunden – und dennoch funktioniert das Menu zur schnellen Navigation im Kindle nicht: der Link zur Seite mit dem Inhaltsverzeichnis ist ausgegraut. Abhilfe bringt der folgende Eintrag in der opf-Datei der ePub Struktur:
<guide>
Entscheidend ist dabei die Angabe des type="toc".
|
Damit haben Sie nichts zu tun? Wenn ihr Partner Amazon (Verkauf dort als Kindle-Buch) oder CreateSpace (Amazons Sparte zur Herstellung gedruckter Bücher) heißt, wird mit einem US Unternehmen zusammengearbeitet. Einnahmen werden dann pauschal mit 30% besteuert – und das entlastet nicht vor einer Steuerpflicht der 100% beim eigenen Finanzamt. Um diese pauschale Besteuerung zu umgehen, wird eine amerikanische Steuernummer benötigt. Deren Beantragung geht nicht über das Internet, sondern telefonisch. Da mag Amazon als Partner vielleicht etwas abschreckend sein.
Die ISBN wird für den Verkauf von Büchern benötigt. Mit der "kostenlosen" ISBN, mit der von den verschiedenen Anbietern gerne geworben wird, ist allerdings tatsächlich nicht unbedingt ein großes Geschenk zu erwarten. Die von Amazons CreateSpace vergebene ISBN ist eine amerikanische; damit lassen sich die Bücher über Amazon verkaufen und natürlich im amerikanischen Buchhandel – aber im lokalen Buchhandel kommt so ein Buch dann nicht. Die anderen Anbieter wie epubli oder BoD oder andere vergeben durchaus eine deutsche ISBN. Damit erfolgt dann auch der Eintrag im Verzeichnis lieferbarer Bücher – aber das garantiert noch nicht, dass die Bücher auch in die Kataloge der Buchhandlungen übernommen werden. Der Erwerb einer eigenen ISBN ist dabei auch keine Lösung – es sei denn, dass man sich sicher ist, die ca. 100 Euro dafür auch zügig zu verdienen.