⚪️ Подход к проектированию

#flow

Думаю, это достаточно очевидно, но на всякий случай поделюсь своим подходом к созданию софта.

Можно условно назвать его "layered" - как лук, ибо великаны - они как лук ("Вонючие? Нет! Многослойные" (ц) Шрек).

👉 Идея в следующем.

▶️ Допустим, делаем некую софтину, которая работает через любой UI (GUI, TUI). Очевидно, что у нее есть некая логика и фейс.

▶️ Я всегда в таком случае выношу логику во внешний слой. Можно сразу делать сервер, потому что даже для локальной утилиты пригодится. Хорошая граница системы получается, к слову. Сервер в утилите может быть in-process, это когда он линкуется внутрь процесса клиента и вызывается не через сокет/порт а прямо в коде. Но логика сервера - полноценная, его одной строчкой можно запустить на отдельном порту, и получить "бесплатно" уже 2 клиента к одной и той же логике.

▶️ Следом я делаю стандартную обвязку сервера: фиксируем контракт серверных роутов/ручек/маршрутов (кто как зовет), можно в open API стандарте. Делаем типизированный client для этого api, чтобы все валидировалось и типизировалось "из коробки".

▶️ Удобно все раложить в мультирепо - client, server отдельными пакетами.

▶️ Самое важное: следом делаем CLI клиента, который имеет доступ ко всем нужным нам функциям через client пакет.

И ВОТ ЭТОТ CLI УПРАВЛЯЕТСЯ АГЕНТОМ на этапе разработки. Вы именно через него будете тестирвоать сценарий работы и основную логику вашей системы.

▶️ Дальше все реализовывается до состояния, когда все работает, под управлением агента. Можно реальные зависимости даже дергать (типа, БД там у вашего сервера реальная, миграцию затестить, экспорты/импорты). В общем, суть в том, что ВСЕ сценарии использования системы гоняются на CLI чере агента.

▶️ По итогу отработки логики с агентом, мы фиксируем успешную работу логики в ВИДЕ ТЕСТОВ e2e типа, я их называю сценариями/business processes. Это тот же сценарий, что исполнял агент, только в виде детерминирвоанного теста. На cli тест сильно проще пишется, не надо чего то тяжелого типа playwright/CDP.

▶️ Поверх живой логики в любой момент можно прикрутить ваш GUI/TUI или Desktop UI / Swift / Electron / Electrobun / Tauri и прочую хрень. Если это сделать "параллеьно", то можно будет смотреть в UI как агент ваш сценарий "проегает" по системе.

❓ В чем профит? Через cli агенту проще и ГОРАЗДО быстрее добраться до отладки именно логики системы, чтобы все работало ок. Не будет мешать GUI обвязка со своими багами

❓ Проще отладить GUI/TUI зная что логика "внизу" уже работает

❓ Проще предусмотреть все в апи чего надо, если вся логика через это апи реализуется. Доделки для GUI скорее в виде вспомогательных ручек, которые удобно для UI отдают инфу.

❓ Так сильно быстрее и надежнее. Вы получаете детерминирвоанные и достаточно быстрые тесты, которые на GUI не завяаны, значит можно исключить chrome binary / playwright и тп.

❓Playwright используем по назначению: для тестирвоания самого ГУЯ.


Как то так. Тоже так делаете?


@deksden_notes