Rucken

Контекст и длительность работы

Проект Rucken не имел чёткой даты начала и конца — он развивался параллельно с реальной работой.

В общей сложности:

• активная разработка заняла примерно 2–3 года,
• существовало несколько итераций и версий,
• часть истории коммитов не сохранилась, так как решения переезжали между проектами и репозиториями.

Это был не «спринт», а длительный инженерный процесс с накоплением опыта и ошибок.

Исходная цель (напоминание)

Rucken создавался, чтобы:

• убрать повторяющиеся архитектурные решения,
• ускорить разработку backend / frontend / mobile,
• централизовать лучшие практики,
• выдерживать рост количества сущностей, таблиц и экранов.

Генерация кода: что сработало, а что нет

Что оказалось полезным

Генераторы кода действительно дали огромный плюс:

• массовое создание backend-кода,
• генерация frontend и mobile-частей,
• секунды вместо дней ручной работы,
• возможность быстро масштабировать проект по количеству сущностей.

На старте и в фазе активного роста это работало отлично.

Где начались реальные проблемы

Когда система стала сложной, вскрылись ограничения подхода.

1. Кастомизация под конкретные кейсы

Реальные интерфейсы почти никогда не одинаковые.

Пример:

• связь по FK может быть:
  • выпадающим списком,
  • модальным окном,
  • автокомплитом,
  • кастомным UI.

Если генератор создаёт «усреднённый» код, то:

• любую нестандартную логику нужно:
• встраивать в генератор,
• не поломать другие сценарии,
• поддерживать это дальше.

Сложность генераторов росла быстрее, чем сложность продукта.

2. Ручные правки vs повторная генерация

Появился ключевой конфликт:

• генератор хочет переписать файл,
• разработчик уже внёс в него ручные изменения.

Чтобы решить это, я реализовал механизм текстового маркера:

• генератор при повторном запуске:
• сканирует существующие файлы,
• если находит маркер ручной модификации — файл не трогает,
• маркер явно показывает:
• «здесь код изменён вручную».

Это позволило:

• безопасно перегенерировать проект,
• не терять кастомные правки,
• работать с большим количеством файлов.

3. Избыточность кода

Из-за генерации:

• файлов становилось очень много,
• значительная часть:
• не использовалась,
• использовалась только в отдельных сценариях.

Следствия:

• линтование занимает много времени,
• Angular live-reload замедляется,
• NestJS hot-reload становится ощутимо медленным,
• билды начинают идти значительно дольше.

Главные выводы по генерации

После 2–3 лет работы с этим подходом я пришёл к важным выводам:

✔️ Генерация кода — это хорошо, когда:

• нужно быстро создать много однотипного кода,
• проект находится в фазе активного роста,
• требования ещё не устоялись.