Droga decyzja architektoniczna to zwykle przepisanie, którego nikt nie potrzebował. Sklep, który już przyjmuje zamówienia na WordPress, nie staje się bezpieczniejszy, bo strona główna przechodzi na nowszy framework. Produkt, który jest głównie API i tablicą, nie staje się jaśniejszy, bo wcisnąłem go w ten sam motyw co sklep. Wybieram stos, który już trzyma zachowanie, i trzymam granicę na tyle ostrą, by jedna osoba wciąż widziała na drugą stronę.
Zostań tam, gdzie biznes już żyje
Jeśli przychód to kasa WooCommerce, praca należy obok tej kasy: motyw, wtyczki, którym naprawdę ufam, serwer, poczta, kopie. Przeniesienie katalogu do osobnego frontu, żeby stos wyglądał nowocześnie, to projekt. Samo w sobie nie jest poprawką kodu promocyjnego ani zgubionego webhooka. Mam więcej cierpliwości dla zwykłej zmiany w PHP, która wychodzi w tym tygodniu, niż dla migracji, której zysk jest estetyczny.
Laravel zasługuje na miejsce, gdy rzecz jest aplikacją z własnymi regułami, własnymi kolejkami i własną administracją, i nie powinna być wyginana w strony. Potok treści z limitem wydatków i krokiem ludzkiej zgody jest taką aplikacją. Strona marketingowa nie jest.
| System już jest | Sięgam po | Nie sięgam po |
|---|---|---|
| Sklep, który przyjmuje zamówienia | WordPress, WooCommerce i serwer dookoła | Przepisanie, żeby strona główna była innym frameworkiem |
| Aplikacja z kolejkami i panelem | Laravel albo Nest, jeśli reszta tego produktu jest już w TypeScript | Sterta wtyczek udających produkt |
| Typowany interfejs wspólny dla tablicy i API | TypeScript, od początku do końca | Drugi język tylko dla przycisków |
| Wyszukanie, ocena, mała usługa nad dokumentami | Python | Runtime PHP sklepu, z lojalności |
Jeden język w jednym produkcie, nie w całej karierze
W jednym produkcie chcę jednego głównego języka, żeby zmiana w API i zmiana na ekranie były tym samym przeglądem. W całej pracy nie udaję, że wszystko jest jednym językiem. PHP, TypeScript i Python są tu na produkcji celowo. Błąd to mieszanie ich w jednej ścieżce żądania, bo każda warstwa była czyjąś preferencją.
PostgreSQL, gdy dane mają relacje i chcę, by baza ich pilnowała. MySQL, gdy to już działa w sklepie, a przenoszenie nie jest zadaniem. Redis do kolejki albo cache, nie jako drugie źródło prawdy. Docker i nudny nginx, gdy wdrożenie trzeba opisać, nie gdy mam ochotę uczyć się orkiestratora.
Przepisanie musi nazwać incydent, który usuwa
Proszę o jedno zdanie, zanim nowy framework wejdzie do planu. Jaki incydent, którego obecny stos nie umie zamknąć, znika przez przeniesienie? Jeśli zdanie jest o guście, rekrutacji albo wykładzie na konferencji, przeniesienie czeka. Jeśli zdanie brzmi „wtyczka kasy nie umie wyrazić tej reguły ceny i już dwa razy łatałem wokół niej”, to prawdziwe zdanie, a i tak szukam mniejszej łaty przed nową witryną sklepu. Mniejsza łata zwykle tam jest.
Ten sam test dotyczy usługi, którą kusi mnie dodać obok sklepu. Kolejka jest uzasadniona, gdy żądanie musi przeżyć ponowienie. Osobny front jest uzasadniony, gdy dwóch klientów, nie jeden programista, potrzebuje tego samego API. Nowa baza prawie nigdy nie jest uzasadniona w tym samym kwartale co problem niezawodności. Dane, które już masz, są systemem. Przeniesienie ich to osobny projekt, z własnym inwentarzem, i nie naprawia kodu promocyjnego.
Mogę utrzymać sklep i usługę obok, bo spotykają się na udokumentowanej krawędzi: webhook, kolejka, tabela. Nie utrzymam systemu, którego krawędzie to „zapytaj osobę, która zbudowała tę część”. Tą osobą muszę być ja, także po starcie. Nowe narzędzie musi więc płacić czynsz. Jeśli nie usuwa przekazania albo klasy incydentów, to gust, a gust może poczekać.
Wybierz stos, który trzyma następny incydent w jednej głowie. Nowość musi to pobić, nie odwrotnie.
