1. Advent: Planung und Design

Bevor wir starten noch einige obligatorische Dinge. Es wird zu jedem Advent (jeweils Samstag und Sonntag) einen Beitrag von mir und einen Beitrag von Florian geben. Jede Woche werden wir ein anderes Thema im Entwicklungsprozess von Open Source Software beschreiben und dies anhand eines realen Projektes demonstrieren. Eine Übersicht und auch die Links dazu finden sich in unserem virtuellen Software Life Circle Adventskranz.

Jede Art von Beteiligung - sei es über einen Kommentar oder Anregung, die Beteiligung beim Source-Code oder ein schlichter Klick auf den Flattr-Button - zeigt uns, dass Euch dieses Projekt gefällt und wir uns die ganze Mühe und Vorarbeit nicht umsonst gemacht haben. Wir freuen uns über jeden Response!

Legen wir los!

Vermutlich hat jeder schon einmal über eine bestehende Softwarelösung geflucht oder sich gewünschte, für ein bestehendes Problem eine passende Software zu haben (oder zu finden). Als Software-Entwickler findet man sich noch viel öfter in dieser Situation - vermutlich deswegen, weil hier der Anspruch noch viel höher ist. Doch was soll man schon groß tun, wenn man vor einem solchen Problem steht? Als Software-Entwickler hat man das Privileg einer Alternative: Selbst den Compiler auszupacken und sich das Tool (oder das Feature) selbst programmieren. Doch warum seine kostbare Freizeit opfern, wenn man sowieso schon den ganzen Tag Software schreibt?

Hier gehen die Meinungen vermutlich weit auseinander. Ich finde, es hat etwas mit Kunst zu tun; dem Bedürfnis etwas aus dem Nichts zu kreieren das im besten Fall nicht nur mir, sondern auch anderen hilft. Für mich ist es eine Art innere Erfüllung, selbst die Macht zu haben, etwas gegen das Problem zu tun und eine elegante Lösung dafür zu schaffen.

Aus diesem Bedürfnis entstehen meist die besten Ideen. So gut wie jede Open Source Software beginnt mit einer simplen Idee, die ein konkretes und akutes Problem (besser) lösen soll. So war es auch bei der Idee für diesen Adventskalender: Das leidige Thema Filesharing scheint ein immer währendes Problem zu sein und zu bleiben. Unzählige Male habe ich in den vergangenen 15 Jahren versucht, eine Datei von einem Rechner zum anderen zu übertragen. Oft gab es irgend ein Hindernis. Es gibt zwar tausende Protokolle auf den unterschiedlichsten Schichten und noch mehr Clients dazu, doch irgendwie scheint es immer noch kein vernünftiges Tool zu geben, dass es erlaubt einfach und unkompliziert Dateien zwischen zwei Rechnern auszutauschen. Windows-Dateifreigabe/SMB? Umständlich, langsam, wie war noch gleich die IP? ... Jabber/ICQ/... hat noch nie zuverlässig und auf Anhieb ohne Port-Forwarding funktioniert, ... Als E-Mail schicken? ... Anhang zu groß. Ihr wisst vermutlich genau, wovon ich rede.

Es fehlt also ein simples Tool, das es ermöglicht ohne jegliche Konfiguration Dateien (sicher) unter zwei Rechnern austauscht. Und darum soll es in diesem Adventskalender gehen.

Die ersten Schritte bei der Softwareplanung sind meist Requirements Engineering und das Aufstellen von Use-Cases; sprich dem Kunden seine Wünsche zu entlocken und zu verstehen. Diesen Prozess können wir uns hier komplett sparen, denn wir wissen genau, was wir wollen und der Use-Case sind wir selbst. Trotzdem ist es gut, wenn die Features aufgeschrieben und von anderen Tools abgegrenzt werden, denn sonst verliert man sich schnell in Details und die Software wird nie fertig. (Die häufigste Ursache für nie veröffentlichter Software!)

Folgende Features soll die Anwendung mindestens am Ende enthalten, damit sie unser Problem löst:

• Eine Benutzerliste, die alle Rechner im lokalen Netz anzeigt, die das Programm geöffnet haben und Dateien empfangen wollen.
• Einem ausgewählten Benutzer eine Datei beliebigen Formats schicken, die dieser annehmen oder ablehnen kann.
• Verschlüsselung bzw. Signierung der übertragenen Daten mittels GPG.
• Die Möglichkeit, Public-Keys von anderen in das lokale System zu importieren und zu verwalten.

Die Anwendung soll nur im lokalen Netz und nur mit Push funktionieren (User sendet Datei statt User gibt Datei frei). Auch sollen Dinge wie DoS-Attacken o.ä. vorerst ignoriert werden, damit es nicht zu komplex wird. Im Vordergrund steht der einfache und sichere Austausch von Dateien.

Die Idee ist da, eine Vorstellung wie es am Ende auszusehen hat auch. Wie geht es weiter? Bei kommerziellen Software-Projekten beginnt hier das Schreiben vom Lasten- und Pflichtenheft und das Ausformulieren eines Projektauftrags. Danach oder parallel vermutlich auch Machbarkeitsstudien und erste Architekturüberlegungen. Wir werden gleich mit der Architektur und dem eigentlichen Design der Software beginnen. Würden wir direkt mit der Implementierung starten und darauf loshacken, müssten wir höchstwahrscheinlich diesen Schritt später nachholen. Viel Code müsste durch Refactoring und größere Umbau-Aktionen wieder gerade gebogen werden. Deshalb werden wir uns ein paar Gedanken zum Design der Anwendung machen, allerdings nicht alles bis ins kleinste Detail durchplanen. Das finale Design entsteht sowieso erst bei der eigentlichen Implementierung.

Weiter geht es hier mit Florians Beitrag zum Thema Design und Architektur-Planung sowie die Auswahl der geeigneten Tools, Techniken und Technologien. Wer sich bei der Planung beteiligen möchte, ist herzlich eingeladen Kommentare zu hinterlassen.