Individualsoftware mit Next.js

Individualsoftware ist Software, die existiert, weil ein Unternehmen etwas Bestimmtes tut und kein Produkt dieses Etwas genau genug abbildet, um es zu verbiegen.

Das ist die ganze Definition, und es ist zugleich das Erste, was man prüfen sollte. Ein guter Teil dessen, was als Individualsoftware beauftragt wird, ist ein Produkt mit getauschtem Logo, und ein guter Teil dessen, was als Produkt gekauft wird, wird über zwei Jahre Umgehungen ohnehin zu Individualsoftware. Beides ist teuer und beides lässt sich im ersten Gespräch vermeiden.

Was das praktisch bedeutet

Die Arbeit hat fast immer eine von drei Formen.

Ein operatives System - das, worin ein Team den ganzen Tag arbeitet. Angebote, Aufträge, Fälle, Bestand, Termine, Freigaben. Es ersetzt meist eine Sammlung Tabellen, eine geerbte Anwendung, die niemand ändern kann, oder beides gleichzeitig.

Eine Oberfläche für Kunden über Systemen, die nie eine haben sollten. Ein Portal, eine Sendungsverfolgung, ein Selbstbedienungskonto, eine Buchung. Der schwierige Teil ist selten die Maske; er ist, dass die Daten dahinter in etwas Altem liegen und langsam antworten.

Ein internes Werkzeug, das existiert, weil ein Produkt das eine Wichtige nicht kann. Das sind die kleinsten und häufig die lohnendsten Projekte, denn die Alternative ist jemandes Arbeitswoche.

Warum serverseitig gerendert und nicht eine Single-Page-Anwendung

Jahrelang bedeutete eine Browser-Anwendung drei Dinge zu bauen: ein Frontend, eine API, die es versorgt, und den Klebstoff dazwischen. Ein großer Teil des Codes in diesen Systemen existierte nur, um Daten zwischen zwei Teilen derselben Anwendung zu bewegen.

Eine App-Router-Anwendung streicht diese Schicht für die meisten Masken. Der Server liest die Daten und rendert die Seite. Der Browser bekommt Markup statt eines Bundles, das anschließend die Daten nachfragt. JavaScript wird nur dort ausgeliefert, wo eine Interaktion es wirklich braucht, und in einem operativen System ist das eine Minderheit der Masken.

Die Folgen sind unspektakulär und sie summieren sich. Eine Sprache über die ganze Anwendung statt zweier. Ein Repository und ein Deployment statt zweier, die unabhängig versionieren. Eine Seite, die beim Ankommen richtig ist, statt einen Moment später. Und deutlich weniger Code, was die einzige zuverlässige Art ist, die Kosten des zweiten Jahres zu senken.

Welche Route wie rendert, bleibt eine Entscheidung und kein Standard, und sie ist das erste Architekturgespräch in jedem Bau. Das Rendering-Modell zeigt, was jede Option kostet.

Wo die Daten liegen, wird gleichzeitig entschieden

Eine individuelle Anwendung ist überwiegend ein Datenmodell mit Masken daran, also ist das Schema kein Detail für später.

Teuer umkehrbar sind die gewöhnlichen Entscheidungen. Was eine Entität ist und was ein Feld. Wo Geld und Datum liegen und in welchem Typ. Ob ein Datensatz gelöscht oder nur abgelöst werden kann. Ob ein Status eine Spalte ist oder eine Historie von Übergängen - und das ist der Unterschied zwischen einem System, das sagen kann, was passiert ist, und einem, das nur die Gegenwart beschreibt.

PostgreSQL ist bei diesen Bauten der Standard, aus Gründen, die auf der PostgreSQL-Seite stehen. Es ist ein Standard und keine Regel, und die eine echte betriebliche Falle - die Zahl der Verbindungen unter einer serverlosen Laufzeit - ist ein bekanntes Problem mit bekannter Antwort statt einer Überraschung.

Wie ein Projekt abläuft

In Phasen, jede endet mit etwas Ausgeliefertem.

Die erste Phase ist absichtlich klein. Sie nimmt den schmalsten Schnitt, der wirklich nützt - einen Ablauf von Anfang bis Ende statt des Skeletts von fünf - und stellt ihn den Leuten hin, die ihn benutzen werden. Das bewirkt zwei Dinge: die Architektur wird an echten Daten entschieden statt an einem Dokument, und alle haben eine ehrliche Grundlage, den Rest zu schätzen.

Der Umfang jeder Phase steht vor ihrem Beginn schriftlich fest. Ihre Entwickler reviewen ab der ersten Woche Pull Requests, wenn Sie welche haben, denn so übertragen sich die Konventionen, und es ist die einzige Variante, in der der Code nach uns wartbar bleibt.

Was Sie bekommen

Am Ende jeder Phase eine ausgelieferte Anwendung, die Sie benutzen können - keine Demo-Umgebung und keinen Branch.

Dazu: das Repository mit intakter Git-Historie und ohne Abhängigkeit von uns, um es zu bauen oder zu deployen. Eine Architekturnotiz, die sagt, welche Route wie rendert, wo die Client-Grenze liegt und warum, geschrieben während die Entscheidungen fielen und nicht nachträglich rekonstruiert. Die Datenbankmigrationen als Code, sodass das Schema eine Historie hat und nicht nur einen Ist-Zustand. Ein Deployment, das auf Ihrer Infrastruktur läuft, wenn das gefordert ist. Und eine Liste dessen, was wir nicht getan haben, mit Begründung, denn das bewusst Weggelassene ist der Teil, den eine Übergabe sonst verliert.

Wann das das falsche Projekt ist

Das gehört klar gesagt, denn die Antwort ist manchmal nein.

Wenn ein Produkt existiert, das achtzig Prozent erfüllt, und die anderen zwanzig Geschmack statt Prozess sind, kaufen Sie das Produkt. Konfiguration ist billiger als Code und bleibt es jedes Jahr.

Wenn gefordert sind ein paar Seiten und ein Kontaktformular, ist das eine Website. Ein Redaktionssystem mit guten Vorlagen dient Ihnen besser als eine Anwendung ohne Wartungsbudget dahinter.

Wenn der Prozess noch erfunden wird, friert Software eine Entscheidung ein, die niemand getroffen hat. Führen Sie ihn von Hand oder in einer Tabelle, bis die Form stillhält, und automatisieren Sie dann die Form, die überlebt hat.

Und wenn intern niemand das Ergebnis besitzt - keine Person, deren Arbeit besser wird, wenn es funktioniert -, wird es aufgegeben, egal wie gut es gebaut ist. Das ist der Fehler, den wir am häufigsten sehen, und der einzige, der nichts mit Entwicklung zu tun hat.