De dure architectuurkeuze is meestal een herschrijving die niemand nodig had. Een winkel die al bestellingen aanneemt op WordPress wordt niet veiliger omdat de homepage naar een nieuwer framework verhuist. Een product dat vooral een API en een bord is, wordt niet duidelijker omdat ik het in hetzelfde thema als de winkel heb gedwongen. Ik kies de stack die het gedrag al vasthoudt, en ik houd de rand scherp genoeg dat één persoon er nog overheen kan kijken.
Blijf waar het bedrijf al woont
Als de omzet een WooCommerce-checkout is, hoort het werk naast die checkout: het thema, de plugins die ik echt vertrouw, de server, de mail, de backups. De catalogus naar een aparte frontend verplaatsen zodat de stack er actueel uitziet, is een project. Het is op zich geen reparatie voor een promocode of een gemiste webhook. Ik heb meer geduld voor een gewone PHP-wijziging die deze week uitgaat dan voor een migratie waarvan de winst esthetisch is.
Laravel verdient zijn plek als het ding een applicatie is, met eigen regels, eigen wachtrijen en een eigen beheer, en niet in pagina’s gebogen moet worden. Een contentpijplijn met een uitgavenplafond en een menselijke goedkeuringsstap is zo’n applicatie. Een marketingsite is dat niet.
| Het systeem is al | Ik pak | Ik pak niet |
|---|---|---|
| Een shop die bestellingen aanneemt | WordPress, WooCommerce en de server eromheen | Een herschrijving zodat de homepage een ander framework wordt |
| Een applicatie met wachtrijen en een admin | Laravel, of Nest als de rest van dat product al TypeScript is | Een stapel plugins die zich als product voordoet |
| Een getypeerde interface die een bord en een API delen | TypeScript, van begin tot eind | Een tweede taal alleen voor de knoppen |
| Ophalen, scoren, een kleine dienst over documenten | Python | De PHP-runtime van de shop, uit loyaliteit |
Eén taal over een product, niet over een loopbaan
Binnen één product wil ik één hoofdtaal, zodat een wijziging in de API en een wijziging in het scherm dezelfde review zijn. Over mijn werk heen doe ik niet alsof alles één taal is. PHP, TypeScript en Python draaien hier allemaal in productie, met opzet. De fout is ze binnen één verzoekpad te mengen omdat elke laag iemands voorkeur was.
PostgreSQL als de data relaties hebben en ik wil dat de database die afdwingt. MySQL als dat is wat de winkel al draait en verplaatsen niet de taak is. Redis voor een wachtrij of een cache, niet als tweede bron van waarheid. Docker en een saaie nginx als de deploy beschreven moet worden, niet als ik zin heb een orchestrator te leren.
Een herschrijving moet het incident noemen dat ze wegneemt
Ik vraag om één zin voordat een nieuw framework het plan in mag. Welk incident, dat de huidige stack niet kan sluiten, verdwijnt door de verhuizing? Gaat de zin over smaak, werving of een conferentiepraatje, dan wacht de verhuizing. Is de zin “de checkout-plugin kan deze prijsregel niet uitdrukken, en ik heb er twee keer omheen gepatcht”, dan is dat een echte zin, en dan zoek ik nog steeds een kleinere patch vóór een nieuwe etalage. De kleinere patch is er meestal.
Dezelfde test geldt voor een dienst die ik in de verleiding kom naast de winkel te zetten. Een wachtrij is gerechtvaardigd als een verzoek een nieuwe poging moet overleven. Een aparte frontend is gerechtvaardigd als twee clients, niet één ontwikkelaar, dezelfde API nodig hebben. Een nieuwe database is in hetzelfde kwartaal als een betrouwbaarheidsprobleem bijna nooit gerechtvaardigd. De data die u al hebt, zijn het systeem. Die verplaatsen is een eigen project, met een eigen inventaris, en het repareert de promocode niet.
Ik kan een winkel en een dienst ernaast houden omdat ze elkaar raken aan een gedocumenteerde rand: een webhook, een wachtrij, een tabel. Ik kan geen systeem houden waarvan de randen “vraag de persoon die dat deel bouwde” zijn. Die persoon moet ik zijn, ook na de lancering. Een nieuw gereedschap moet dus huur betalen. Haalt het geen overdracht of een klasse incidenten weg, dan is het smaak, en smaak kan wachten.
Kies de stack die het volgende incident in één hoofd houdt. Het nieuwe moet dat verslaan, niet omgekeerd.
