Von der Idee zum Projekt

Ein neues Projekt beginnt normalerweise mit einer Idee, ein paar Notizen und irgendwann dem ersten Commit.

Bei FlowOps möchte ich es etwas anders machen.

Dieses Projekt soll nicht nur zeigen, was ich programmieren kann. Ich möchte dokumentieren, wie ich als Entwickler an ein neues Softwareprojekt herangehe – von der ersten Idee über Anforderungen und Architektur bis hin zu Entwicklung, Testing, Deployment und der abschließenden Reflexion.

Deshalb wird diese Serie über mehrere Wochen entstehen und meinen tatsächlichen Entwicklungsprozess begleiten.

Warum dieses Projekt?

Für ein Portfolio ist es relativ einfach, eine fertige Anwendung zu zeigen.

Man kann Screenshots machen, den verwendeten Tech-Stack auflisten und auf das GitHub-Repository verlinken.

Was dabei allerdings kaum sichtbar wird, ist der Weg dorthin.

Warum wurde eine bestimmte Technologie gewählt?

Welche Alternativen wurden verworfen?

Wie wurde das Datenmodell entwickelt?

Was passiert, wenn die erste Lösung nicht funktioniert?

Wie gehe ich mit Bugs um?

Welche Teile des Projekts sind tatsächlich wichtig und welche waren vielleicht unnötiges Overengineering?

Genau diese Fragen möchte ich mit FlowOps sichtbar machen.

Was ist FlowOps?

FlowOps wird eine kleine Incident-Management-Plattform für technische Teams.

Die grundlegende Idee ist, dass ein Team technische Störungen und Incidents zentral erfassen und während ihrer Bearbeitung nachvollziehbar dokumentieren kann.

Ein typischer Ablauf könnte beispielsweise so aussehen:

Incident wird entdeckt
        ↓
Incident wird erstellt
        ↓
Severity wird festgelegt
        ↓
Verantwortlicher wird zugewiesen
        ↓
Team untersucht das Problem
        ↓
Status und Ereignisse werden dokumentiert
        ↓
Incident wird gelöst
        ↓
Postmortem wird erstellt

Dabei geht es mir nicht darum, eine vollständige Konkurrenz zu bestehenden Produkten zu entwickeln.

Das Ziel ist eine überschaubare, aber realistische Anwendung, an der sich möglichst viele Aspekte moderner Softwareentwicklung zeigen lassen.

Was möchte ich damit zeigen?

FlowOps soll verschiedene Bereiche abdecken, die auch in einem professionellen Entwicklungsprozess eine Rolle spielen.

Dazu gehören unter anderem:

• Anforderungsanalyse
• Architektur
• Datenmodellierung
• API-Entwicklung
• Frontend-Entwicklung
• Authentication und Authorization
• Testing
• Fehlerbehandlung
• Security
• CI/CD
• Deployment
• Logging und Observability
• Dokumentation

Dabei möchte ich nicht möglichst viele Technologien verwenden.

Im Gegenteil: Eine der Herausforderungen besteht darin, nur die Technologien einzusetzen, die für das Problem tatsächlich sinnvoll sind.

Ein wichtiges Ziel: Entscheidungen nachvollziehbar machen

Ein Teil dieser Serie wird sich deshalb nicht nur mit dem fertigen Code beschäftigen.

Ich möchte auch Entscheidungen dokumentieren.

Wenn ich beispielsweise zwischen zwei Technologien wählen muss, soll nicht nur das Ergebnis sichtbar sein.

Ich möchte festhalten:

Problem
   ↓
Mögliche Lösungen
   ↓
Vor- und Nachteile
   ↓
Entscheidung
   ↓
Trade-offs

Eine technische Entscheidung ist schließlich nicht automatisch gut, nur weil sie funktioniert.

Oft gibt es mehrere vernünftige Lösungen. Entscheidend ist, ob ich die Vor- und Nachteile verstehe und meine Entscheidung begründen kann.

Das Projekt hat ein Budget von 0 €

Eine weitere Vorgabe für FlowOps ist, dass für die Entwicklung und den Betrieb keine laufenden Kosten entstehen sollen.

Das ist nicht nur eine finanzielle Einschränkung, sondern auch eine interessante technische Herausforderung.

Ich möchte herausfinden, wie weit man mit kostenlosen beziehungsweise bereits vorhandenen Tools und Free-Tier-Angeboten kommt, ohne die Anwendung unnötig kompliziert zu machen.

Dabei ist mir wichtig, nicht einfach jede kostenlose Technologie einzubauen.

Wenn eine einfache Lösung ausreicht, möchte ich diese bevorzugen.

Das bedeutet auch, dass manche Entscheidungen bewusst gegen eine technisch aufwendigere Architektur ausfallen werden.

Der Entwicklungsprozess

Die Serie wird wöchentlich erscheinen.

Jeder Beitrag dokumentiert dabei einen Abschnitt des Projekts.

Die geplante Entwicklung sieht ungefähr so aus:

01  Von der Idee zum Projekt
02  Anforderungen und Scope
03  Architektur und technische Entscheidungen
04  Datenmodell und Datenbank
05  Projektgrundlage und Entwicklungsumgebung
06  Authentication und Authorization
07  Der Incident-Lifecycle
08  Testing und Qualität
09  Fehler, Bugs und unerwartete Probleme
10  Deployment und Observability
11  Rückblick und Lessons Learned

Die genaue Reihenfolge kann sich während der Entwicklung noch ändern.

Das ist sogar ein Teil des Experiments.

Wenn sich herausstellt, dass eine geplante Lösung nicht funktioniert oder eine andere Priorität sinnvoller ist, werde ich das entsprechend dokumentieren.

Nicht nur die Erfolge

Ein Punkt ist mir bei dieser Serie besonders wichtig.

Ich möchte nicht nur fertige Lösungen zeigen.

Wenn etwas nicht funktioniert, gehört das ebenfalls zum Entwicklungsprozess.

Ein Fehler, eine verworfene Architektur oder eine Entscheidung, die sich später als nicht optimal herausstellt, ist genauso interessant wie ein erfolgreich implementiertes Feature.

Deshalb möchte ich bei jedem Beitrag unter anderem festhalten:

Was wollte ich erreichen?

Was habe ich tatsächlich umgesetzt?

Welche Probleme sind aufgetreten?

Welche Entscheidungen musste ich treffen?

Was habe ich daraus gelernt?

Was möchte ich als Nächstes verbessern?

Dadurch soll am Ende nicht nur eine fertige Anwendung entstehen, sondern auch eine nachvollziehbare Geschichte darüber, wie sie entstanden ist.

Was kommt als Nächstes?

Bevor ich mit der eigentlichen Implementierung beginne, möchte ich zunächst den Scope genauer definieren.

Welche Benutzer gibt es?

Welche Funktionen gehören zum MVP?

Welche Anforderungen sind technisch relevant?

Und vor allem:

Was sollte FlowOps bewusst nicht können?

Denn ein Projekt auf einen sinnvollen Umfang zu begrenzen, ist genauso wichtig wie neue Features zu entwickeln.

Im nächsten Beitrag werde ich deshalb die Anforderungen definieren und aus der ursprünglichen Idee einen konkreten MVP machen.