Советы по разработке — день 2

Нейминг - самое недооценённое “оружие” разработчика.
Большинство игнорирует, а потом теряет часы на то, чтобы вспомнить, “что тут вообще происходит”.
Правильные имена - это документация, которая пишет себя сама.

⸻

1. Сценарии и вебхуки
Я всегда начинаю с указания триггера - откуда приходит запрос (вебхук, крон, ручной запуск), как часто он срабатывает и какое главное действие выполняет. Например - [Trigger - Lovable] Create new user

Все сценарии раскладываю по папкам.

С недавнего времени стал задавать кастомные имена вебхукам, совпадающие с названием сценария - так проще видеть, как взаимодействуют модули.
Про модульность подробнее напишу отдельно.

⸻

2. Нейминг нод

Каждая нода должна отражать конкретное действие и субъект этого действия:
таблицу, сервис, статус или сущность, с которой идёт работа.

Не “Supabase”, а “Insert user into users”.
Не “HTTP Request”, а “Send invoice to Stripe”.

Это занимает буквально пару лишних секунд, но в будущем:
- вы читаете сценарий как текст,
- другому разработчику не нужно разбираться с нуля,
- ИИ проще анализировать структуру,
- документирование упрощается в разы.

Фактически сценарий превращается в самодокументируемую схему.

⸻

3. Нейминг в базе данных (Supabase)

У меня свой базовый стандарт:
- snake_case
- таблицы - во множественном числе
- внешние ключи — table_name_id
- одинаковые по смыслу поля - называются одинаково во всех таблицах

Это выглядит скучно, но экономит огромное количество времени.
Особенно когда переносишь архитектуру в новый проект - не нужно заново придумывать структуру, всё уже привычно и предсказуемо.

⸻

Нейминг - это мелочь, на которую не хочется тратить время.
Но именно из таких мелочей и складывается ощущение “чистой” системы.