Советы по разработке — день 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 - одинаковые по смыслу поля - называются одинаково во всех таблицах Это выглядит скучно, но экономит огромное количество времени. Особенно когда переносишь архитектуру в новый проект - не нужно заново придумывать структуру, всё уже привычно и предсказуемо. ⸻ Нейминг - это мелочь, на которую не хочется тратить время. Но именно из таких мелочей и складывается ощущение “чистой” системы.