Der Weg zu besseren Software-Projekten

Kennen Sie einen Sofwareentwickler der sich immer an einen Projektplan halten konnte, der stets fehlerfrei Quellcode schreibt und dazu noch entspannt jeder anstehenden Systemintegration entgegensieht? Entweder ist dieser Entwickler das Genie schlechthin oder seine Planung und sein gesamtes Projektteam sind perfekt aufeinander eingespielt. In beiden Fällen wüsste ich gerne mehr darüber.

Die Realität gestaltet sich meist so, dass mit steigender Komplexität von Softwareprojekten auch die Unbekannten steigen. Das führt zwangsläufig dazu, dass keine hundertprozentige Absicherung mehr möglich ist. Weder Tests noch Codereviews können garantieren, dass die nächste Version der neuen Software fehlerfrei funktionieren wird.

Wer jedoch die Probleme kennt und frühzeitig einen Großteil möglicher Fehler ausschließen kann, der wird ein gutes Stück entspannter dem nächsten Release entgegensehen.

In dieser Artikelserie möchten wir Ihnen den Weg zu besseren Projekten zeigen.
Wie und wodurch gute Anwendungen entstehen und das die Pflege und Lebensdauer einer Software bereits ab dem Projektstart entschieden wird.
Wir zeigen ihnen, dass Continuous Integration ein Mittel ist, dass Ihnen die Arbeit erleichtern kann und stellen Ihnen mit Jenkins einem Continuous Integration Server mit alle notwendigen Features vor.

Bessere Projekte mit CI – Notwendigkeit von Tests

In moderner und komplexer Software ist es nicht möglich alle erdenklichen Varianten eines sich möglicherweise einschleichenden Softwarefehlers (eines Bugs) mit entsprechenden Tests abzudecken. Dennoch ist es zwingend notwendig gerade markante Codefragmente intensiv und regelmäßig zu testen, um ungewollte Seiteneffekte zu erkennen. Zu sagen man braucht keine Tests, da ich der einzige Entwickler im Projekt bin und ich weiß was mein Code macht, ist hinfällig sobald man guten Code schreiben möchte. Codefragmente die man wiederverwenden kann, Methoden welche ein Programm schlank bzw. schnell halten und Klassenhierarchien die eine Software wartbar und erweiterbar halten sind nicht trivial. Ja, es ist notwendig auch seinen eigenen Code auf korrektes Verhalten zu überprüfen.

Es wird schnell klar, dass diese Aufgaben nicht irgendwann erledigt werden sollten, wie ein Punkt „Unit-Tests schreiben“ in einem Projektplan. Sicherlich gibt es verschiedene Ansätze wie den Test-driven-first, aber unumstößlich ist die Aussage, dass das Verständnis für ein Codefragment zum Zeitpunkt seiner Implementierung durch den Entwickler am größten ist. Die Überwindung in diesem Moment den Code auch entsprechend mit Tests abzusichern ist somit am geringsten. Weder ein späterer Zeitpunkt noch eine Testabteilung wird so exakt in die Logik vertieft sein, wie der Schöpfer bei seiner Arbeit.

Im nächsten Abschnitt erfahren Sie, welche angenehme Nebenwirkung das Erstellen von Tests hat und warum damit der erste Schritt zu besseren Projekten und hin zu Continuous Integration bereits getan ist.

Getagged mit: , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

* Copy This Password *

* Type Or Paste Password Here *