"Мои n8n-workflow перестали превращаться в спагетти. Вот что я поменял"
Мои n8n-workflow перестали превращаться в спагетти. Вот что я поменял
Первые workflow в n8n я строил по принципу «лишь бы работало». Работало — недели три. Потом нужно было добавить условие, поменять API, вставить новый шаг. И каждый раз — 30 минут на то, чтобы вспомнить, что куда ведёт. Знакомо?
После нескольких переписываний с нуля я выработал набор правил, которые держат workflow читаемыми спустя месяцы. Делюсь.
Один workflow — одна задача
Монолит на холсте — то же самое, что монолит в коде. Intake, обработка, отправка, логирование — всё в одном месте — это рецепт катастрофы.
Я перешёл на схему «координатор + суб-workflow». Главный workflow только маршрутизирует. Каждый суб-workflow делает одну вещь: забирает данные, обрабатывает, отправляет. Связываются через Execute Workflow.
Результат: любой кусок можно менять, не трогая остальные. Можно тестировать отдельно. Можно переиспользовать.
Error handling — первый шаг, а не последний
Стандартная ситуация: «Сейчас быстро соберу workflow, ошибки обработаю потом». «Потом» не наступает. n8n молча проглатывает сбои, а ты узнаёшь о проблеме, когда клиент спрашивает, почему не пришёл отчёт.
Теперь Error Trigger — первая нода в каждом новом workflow. Ещё до основной логики. Ловит ошибку → форматирует → шлёт в Telegram → пишет в лог. Шаблон один на все workflow, копируется за секунду.
Называйте ноды по-человечески
«HTTP Request3» — это ничего. «Fetch Weekly Sales from Stripe» — это всё, что нужно знать. Когда что-то падает в 2 часа ночи, имена нод — разница между быстрым фиксом и мучительным расследованием.
Формула: **глагол + объект + источник**. `Filter Active Users`, `Send Report to Telegram`, `→ Process Payment` (стрелка = вызов суб-workflow).
Sticky notes — для решений, а не для описаний
Не документируйте каждое поле. Документируйте **почему**:
- «Split здесь из-за rate limit Telegram: 30 msg/sec» - «Retry 3x с backoff — Stripe webhook иногда опережает создание заказа»
Через полгода эти заметки спасут от «рефакторинга», который сломает намеренное решение.
Git — обязателен
n8n хранит workflow в JSON. JSON идеально ложится в Git. Экспортируете после значимых изменений, коммитите с внятным сообщением — получаете откат, diff, код-ревью и аудит-лог бесплатно.
```bash n8n export:workflow --id=123 --output=workflows/order-processing.json ```
Тестовые данные
Для каждого workflow — статический JSON-payload. Нужно проверить изменение — подставил и запустил, не ждёшь реального триггера. Когда триггер срабатывает раз в день, это экономит часы.
Что это даёт на практике
Мои workflow живут в продакшене месяцами. Изменение занимает минуты, а не часы. Новый человек в команде читает холст без моих объяснений. Error handling ловит проблемы до того, как о них узнаёт клиент.
Ничего из этого не rocket science. Но каждый пункт — ответ на конкретную боль.
А как вы организуете свои n8n-workflow? Есть свои правила, или каждый раз — импровизация?