Die teure Architekturentscheidung ist meist ein Umschreiben, das niemand brauchte. Ein Shop, der auf WordPress schon Bestellungen annimmt, wird nicht sicherer, weil die Startseite in ein neueres Framework zieht. Ein Produkt, das vor allem eine API und ein Board ist, wird nicht klarer, weil ich es in dasselbe Theme wie den Shop gezwungen habe. Ich wähle den Stack, der das Verhalten schon hält, und halte die Kante scharf genug, dass eine Person noch hinübersehen kann.
Bleiben Sie, wo das Geschäft schon lebt
Wenn der Umsatz eine WooCommerce-Kasse ist, gehört die Arbeit neben diese Kasse: das Theme, die Plugins, denen ich wirklich traue, der Server, die Mail, die Backups. Den Katalog in ein separates Frontend zu ziehen, damit der Stack aktuell aussieht, ist ein Projekt. Es ist für sich kein Fix für einen Aktionscode oder einen verpassten Webhook. Ich habe mehr Geduld für eine schlichte PHP-Änderung, die diese Woche ausgeliefert wird, als für eine Migration, deren Gewinn ästhetisch ist.
Laravel verdient seinen Platz, wenn das Ding eine Anwendung ist, mit eigenen Regeln, eigenen Warteschlangen, eigener Verwaltung, und sich nicht in Seiten biegen lassen soll. Eine Content-Pipeline mit Ausgabengrenze und einem menschlichen Freigabeschritt ist so eine Anwendung. Eine Marketingseite ist es nicht.
| Das System ist schon | Ich greife zu | Ich greife nicht zu |
|---|---|---|
| Ein Shop, der Bestellungen annimmt | WordPress, WooCommerce und der Server darum | Ein Umschreiben, damit die Startseite ein anderes Framework wird |
| Eine Anwendung mit Warteschlangen und einem Admin | Laravel, oder Nest, wenn der Rest dieses Produkts schon TypeScript ist | Ein Haufen Plugins, der sich als Produkt ausgibt |
| Eine typisierte Schnittstelle, die ein Board und eine API teilen | TypeScript, durchgängig | Eine zweite Sprache nur für die Knöpfe |
| Wiederfinden, Bewertung, ein kleiner Dienst über Dokumente | Python | Die PHP-Laufzeit des Shops, aus Loyalität |
Eine Sprache über ein Produkt, nicht über eine Laufbahn
In einem Produkt will ich eine Hauptsprache, damit eine Änderung an der API und eine Änderung am Bildschirm dieselbe Prüfung sind. Über meine Arbeit hinweg tue ich nicht so, als wäre alles eine Sprache. PHP, TypeScript und Python laufen hier alle in Produktion, mit Absicht. Der Fehler ist, sie in einem einzigen Anfragepfad zu mischen, weil jede Schicht jemandes Vorliebe war.
PostgreSQL, wenn die Daten Beziehungen haben und die Datenbank sie durchsetzen soll. MySQL, wenn der Shop das schon fährt und das Verschieben nicht die Aufgabe ist. Redis für eine Warteschlange oder einen Cache, nicht als zweite Quelle der Wahrheit. Docker und ein langweiliges nginx, wenn das Deploy beschrieben werden muss, nicht wenn ich Lust habe, einen Orchestrator zu lernen.
Ein Umschreiben muss den Vorfall nennen, den es beseitigt
Ich verlange einen Satz, bevor ein neues Framework in den Plan darf. Welcher Vorfall, den der aktuelle Stack nicht schließen kann, verschwindet durch den Umzug? Geht der Satz um Geschmack, Recruiting oder einen Konferenzvortrag, wartet der Umzug. Ist der Satz „das Checkout-Plugin kann diese Preisregel nicht ausdrücken, und ich habe zweimal darum herumgeflickt“, ist das ein echter Satz, und dann suche ich immer noch einen kleineren Flicken vor einem neuen Storefront. Der kleinere Flicken ist meist da.
Derselbe Test gilt für einen Dienst, den ich neben den Shop zu stellen versucht bin. Eine Warteschlange ist gerechtfertigt, wenn eine Anfrage einen erneuten Versuch überleben muss. Ein separates Frontend ist gerechtfertigt, wenn zwei Clients, nicht ein Entwickler, dieselbe API brauchen. Eine neue Datenbank ist im selben Quartal wie ein Zuverlässigkeitsproblem fast nie gerechtfertigt. Die Daten, die Sie schon haben, sind das System. Sie zu verschieben ist ein eigenes Projekt, mit eigenem Inventar, und es repariert den Aktionscode nicht.
Ich kann einen Shop und einen Nebendienst halten, weil sie sich an einer dokumentierten Kante treffen: ein Webhook, eine Warteschlange, eine Tabelle. Ich kann kein System halten, dessen Kanten „frag die Person, die den Teil gebaut hat“ sind. Diese Person muss ich sein, auch nach dem Start. Ein neues Werkzeug muss also Miete zahlen. Nimmt es keine Übergabe oder eine Klasse von Vorfällen weg, ist es Geschmack, und Geschmack kann warten.
Wählen Sie den Stack, der den nächsten Vorfall in einem Kopf hält. Das Neue muss das schlagen, nicht umgekehrt.
