Дороге архітектурне рішення зазвичай — переписування, якого нікому не було треба. Крамниця, яка вже приймає замовлення на WordPress, не стає надійнішою від того, що головна переїжджає на новіший фреймворк. Продукт, який переважно API і дошка, не стає ясніше від того, що я втиснув його в ту саму тему, що й крамницю. Я обираю стек, який уже тримає поведінку, і тримаю межу досить різкою, щоб одна людина все ще бачила на той бік.
Залишайтеся там, де бізнес уже живе
Якщо виручка — оформлення WooCommerce, робота лежить поруч із цим оформленням: тема, плагіни, яким я справді довіряю, сервер, пошта, копії. Перенесення каталогу в окремий фронт, щоб стек виглядав сучасно, — проєкт. Сам по собі він не лагодить промокод і пропущений webhook. У мене більше терпіння на просту правку PHP, яка вийде цього тижня, ніж на міграцію, чий виграш естетичний.
Laravel доречний, коли це застосунок зі своїми правилами, своїми чергами і своєю адмінкою, і його не варто гнути в сторінки. Контентний конвеєр зі стелею витрат і кроком людської згоди — такий застосунок. Маркетинговий сайт — ні.
| Система вже і є | Беру | Не беру |
|---|---|---|
| Магазин, який приймає замовлення | WordPress, WooCommerce і сервер навколо них | Переписування, щоб головна стала іншим фреймворком |
| Застосунок із чергами й адмінкою | Laravel, або Nest, якщо решта продукту вже на TypeScript | Купа плагінів, яка вдає продукт |
| Типізований інтерфейс, спільний для дошки й API | TypeScript, від початку до кінця | Друга мова лише заради кнопок |
| Пошук, оцінка, невеликий сервіс поверх документів | Python | PHP-рантайм магазину, з лояльності |
Одна мова всередині продукту, не на всю кар’єру
Усередині одного продукту я хочу одну основну мову, щоб зміна API і зміна екрана були одним переглядом. По всій роботі я не вдаю, що все — одна мова. PHP, TypeScript і Python тут у проді навмисно. Помилка — мішати їх в одному шляху запиту, бо кожен шар був чиїмось уподобанням.
PostgreSQL, коли в даних є зв’язки і я хочу, щоб база їх тримала. MySQL, коли крамниця вже на ньому і перенесення не завдання. Redis для черги чи кешу, не як друге джерело правди. Docker і нудний nginx, коли викладку треба описати, а не коли хочеться вчити оркестратор.
Переписування має назвати інцидент, який воно прибирає
Я прошу одне речення, перш ніж новий фреймворк потрапить у план. Який інцидент, який поточний стек не може закрити, зникає через переїзд? Якщо речення про смак, наймання чи доповідь на конференції, переїзд чекає. Якщо речення таке: «плагін оформлення не вміє виразити це правило ціни, і я вже двічі обходив його латкою», це справжнє речення, і я все одно шукаю латку меншу, перш ніж нову вітрину. Менша латка зазвичай є.
Той самий тест — для сервісу, який тягне додати поруч із крамницею. Черга виправдана, коли запит має пережити повтор. Окремий фронт виправданий, коли той самий API потрібен двом клієнтам, а не одному розробнику. Нова база майже ніколи не виправдана в тому самому кварталі, що й проблема надійності. Дані, які у вас уже є, і є система. Перенесення — окремий проєкт зі своїм інвентарем, і він не лагодить промокод.
Я можу тримати крамницю і сусідній сервіс, бо вони зустрічаються на описаному краї: webhook, черга, таблиця. Я не можу тримати систему, краї якої — «запитай того, хто це зібрав». Цією людиною маю бути я, і після запуску теж. Новому інструменту доводиться платити оренду. Якщо він не прибирає передачу з рук у руки чи клас інцидентів, це смак, а смак почекає.
Оберіть стек, який тримає наступний інцидент в одній голові. Новизна має перемогти це, а не навпаки.
