Individualsoftware mit Laravel

Eine Geschäftsanwendung handelt überwiegend nicht vom Geschäft.

Zählt man den Code eines solchen Systems, ist der Teil, der abbildet, wie Ihr Unternehmen tatsächlich arbeitet, eine Minderheit davon. Der Rest ist der Apparat, den jede solche Anwendung braucht, bevor sie überhaupt etwas Nützliches tun kann - und diese Unterscheidung ist das Nützlichste, was man vor einer Beauftragung verstehen kann, denn dort werden Budgets gewonnen und verloren.

Die zwanzig Prozent, die wirklich Ihre sind

Der wertvolle Teil einer Eigenentwicklung ist der, den ein Produkt Ihnen nie geben konnte: Ihre Preisregeln, Ihre Freigabekette, der Weg eines Auftrags von angeboten über eingeplant bis abgerechnet, die Ausnahme für den einen Kunden aus Gründen, die ein Jahrzehnt zurückreichen.

Dort gehört das Denken hin, und in einem schlecht geführten Projekt ist dort das Denken zu Ende, weil das Budget beim Zum-Laufen-Bringen der Infrastruktur aufgebraucht wurde.

Die Frage an einen Dienstleister ist deshalb nicht, welches Framework er benutzt. Sie ist, welcher Anteil der Schätzung auf Dinge entfällt, die in jeder Anwendung identisch sind, die er je gebaut hat.

Was eine Laravel-Geschäftsanwendung braucht, bevor sie etwas Nützliches tut

Die Liste ist länger als erwartet und nichts davon ist verhandelbar.

Jemand muss sich anmelden, und jemand muss ein Passwort zurücksetzen können, ohne einen Entwickler. Verschiedene Leute müssen verschiedenes sehen, erzwungen an einer besseren Stelle als einem versteckten Menüpunkt - Autorisierung ist nicht Authentifizierung, und der Unterschied zeigt sich beim ersten Export, der Datensätze erreicht, die der Bediener nicht sehen durfte.

Arbeit muss außerhalb eines Web-Requests passieren. Ein Dokument erzeugen, eine Mail senden, ein Nachtimport, eine Zahl neu berechnen. Das heißt eine Queue, das heißt Wiederholungen, das heißt Jobs, die gefahrlos zweimal laufen können - und eine beiläufig gebaute Queue ist der Weg, auf dem ein Kunde dieselbe Rechnung dreimal bekommt.

Das Schema braucht eine Historie statt eines Ist-Zustands, damit eine Änderung geprüft und auf einer anderen Umgebung nachgezogen werden kann. Dateien müssen von Leuten außerhalb des Unternehmens angenommen werden, ohne dass das ein Sicherheitsvorfall wird. Und es braucht Tests über die Pfade, auf denen Geld und Zustand sich ändern, sonst traut sich im zweiten Jahr niemand mehr an das System.

Laravel liefert all das als Standard, in einer Qualität, die die meisten Teams selbst gebaut nicht erreichen - und, wichtiger, in einer Form, die der nächste Entwickler erkennt. Ein vor vier Jahren erfundenes eigenes Framework von jemandem, der inzwischen weg ist, ist die teuerste Art von Individualsoftware überhaupt.

Die Schnittstellen sind meist der eigentliche Umfang

Der Teil dieser Projekte, der überzieht, sind fast nie die Masken.

Es ist, dass die Anwendung sich mit einer Buchhaltung, einem ERP, einem Zahlungsdienstleister, einem Versender, einem CRM und einer Tabelle einig werden muss, von denen keines dafür gebaut wurde, sich mit irgendetwas einig zu werden. Technisch ist das Sprechen damit unkompliziert. Die Entscheidungen sind es nicht.

Welches System besitzt den Namen eines Kunden, und was passiert, wenn er auf der anderen Seite geändert wird. Wer vergibt die Rechnungsnummer. Was eine Gutschrift auf beiden Seiten tut. Wie eine Teilzahlung verbucht wird. Was passiert, wenn ein System ausgefallen ist und das andere schon gebucht hat.

Das sind kaufmännische Entscheidungen, die technisch aussehen, und sie fallen mit Ihrer Buchhaltung und Ihrem Betrieb statt von uns geschätzt zu werden. Arbeit dieser Art steht unter Integrations-Engineering; in einer Eigenentwicklung ist sie häufig die Hälfte des Projekts, und ein Plan, der sie als Position am Ende führt, ist ein Plan, der rutscht.

Wie ein individuelles Laravel-Projekt abläuft

In Phasen, jede endet mit etwas Ausgelieferten, das Leute wirklich benutzen können.

Die erste Phase nimmt einen Ablauf von Anfang bis Ende - nicht den Umriss von fünf -, denn das zwingt das Schema, echten Daten zu begegnen. Es erzeugt auch eine Schätzung für den Rest, die etwas wert ist, was eine Zahl aus Woche eins nicht ist.

Jede Phase wird vor Beginn schriftlich zugeschnitten. Wo Sie Entwickler haben, sind sie ab der ersten Woche in den Pull Requests; so übertragen sich Konventionen, und es ist die einzige Form, in der das System wartbar bleibt, nachdem wir aufhören.

Die Migration bestehender Daten läuft nebenher statt am Ende. Das neue System wird gegen das alte abgeglichen, Datensatz für Datensatz, bis sie übereinstimmen

• Abweichungen sind Befunde und keine Fehler, und es sind immer mehr, als jemand vorhergesagt hat.

Was Sie aus einem individuellen Laravel-Projekt bekommen

Zum Abschluss jeder Phase eine laufende Anwendung auf Infrastruktur, die Sie kontrollieren.

Daneben: das Repository mit vollständiger Historie, mit Build und Deployment ohne Abhängigkeit von uns. Migrationen statt eines Datenbank-Dumps. Eine schriftliche Beschreibung des Datenmodells, jedes Constraints und dessen, was es verhindert - denn ein Constraint, den niemand erklären kann, ist einer, den ein künftiger Entwickler löscht. Tests über die Pfade, die Geld bewegen oder Zustand ändern. Und die Schnittstellenentscheidungen festgehalten, einschließlich der umstrittenen, denn die braucht ein neuer Entwickler und die lässt ein Übergabedokument immer weg.

Wo Kaufen das Bauen schlägt

Diese Antwort ist manchmal nein, und sie jetzt zu hören ist billiger.

Wenn ein Produkt das meiste erfüllt und die Lücke Geschmack statt Prozess ist, kaufen und konfigurieren Sie das Produkt. Der ehrliche Vergleich ist fünf Jahre gegen fünf Jahre und nicht Jahr eins gegen Jahr eins, und auf die längere Sicht gewinnt Konfiguration häufiger, als man erwartet.

Wenn der Prozess noch erfunden wird, gießt eine Eigenentwicklung eine Entscheidung in Beton, die niemand getroffen hat. Lassen Sie ihn von Hand laufen, bis die Form stillhält.

Wenn das Volumen so klein ist, dass die Handarbeit eine Stunde pro Woche kostet, ist Automatisieren ein Hobby und keine Investition.

Und wenn es niemandem im Unternehmen besser geht, wenn es funktioniert - keiner einzelnen Person, deren Arbeit leichter wird -, wird es aufgegeben, egal wie gut es ist. Das ist der Fehler, den wir am häufigsten gesehen haben, und er ist nie ein technischer.