Сгенерированный код делает отладку более прозрачной, а не труднее¶

13 августа 2026

Сгенерированный код часто рассматривается как признак проблем с отладкой.

Допущение понять легко. Разработчик пишет контроллер, сервис, интерфейс репозитория или аннотацию метода, но в работающем приложении есть дополнительные классы, которые не были написаны вручную. Из этого наблюдения легко сделать вывод, что отладка должна усложняться: отладчик якобы будет проваливаться в сгенерированные обёртки, навигация будет вести в незнакомые классы, стектрейсы будут содержать синтетические имена, а понимание поведения приложения потребует проводить полдня внутри build/generated.

Это описание звучит правдоподобно, но оно не соответствует тому, как отладка обычно работает в Kora.

Фреймворк Kora не заменяет приложение непрозрачным сгенерированным рантаймом. Он переносит работу фреймворка на этап компиляции и производит обычный исходный код на Java или Kotlin, который компилируется вместе с приложением. Связывание зависимостей, HTTP-обработчики, реализации репозиториев, маппинги и AOP-обёртки становятся конкретными классами, а не правилами рефлексии времени выполнения или цепочками динамических прокси. IntelliJ может по ним навигировать, JVM может их отлаживать, компилятор их валидирует, в них можно ставить точки останова, а нейро-агент может читать их как любой другой исходный файл.

Поэтому важное различие — не в том, существует ли сгенерированный код. Важное различие — в том, какую роль он играет.

В обычной разработке разработчик по-прежнему работает в первую очередь с написанным вручную кодом приложения:

Контроллер
   ↓
Сервис
   ↓
Репозиторий

Точки останова ставятся в контроллерах, сервисах, доменной логике, мапперах, интеграциях и в той части приложения, которая на самом деле исследуется. Наличие сгенерированного HTTP-обработчика или AOP-подкласса не заставляет отладчик останавливаться там. И наличие сгенерированной реализации репозитория не означает, что каждая сессия отладки, связанная с базой данных, начинается с чтения сгенерированного исходника.

Сгенерированный код становится интересным, когда вопрос пересекает границу фреймворка. Если разработчик хочет точно знать, какой компонент был связан, как именно метод репозитория выполняет свой запрос, где именно происходит валидация или как именно таймаут, повтор, circuit breaker и fallback компонуются вокруг метода, доступен дополнительный артефакт: код, который Kora на самом деле сгенерировал.

Это не бремя отладки. Это запасной выход.

Центральная идея этой статьи поэтому проста:

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

Или, если сформулировать сильнее:

Сгенерированный код — это не шум отладки по определению. В Kora это инспектируемая граница между декларативным кодом приложения и кодом JVM, который фактически выполняется.

Отладка не означает пошаговый проход по каждому методу¶

Значительная часть страха вокруг сгенерированного кода проистекает из неточной ментальной модели того, как разработчики используют отладчик.

Предположим, метод сервиса вызывает репозиторий:

Java Kotlin

public User loadUser(long id) {
    return userRepository.findById(id);
}

fun loadUser(id: Long): User {
    return userRepository.findById(id)
}

Если разработчик ставит точку останова внутри loadUser, нажимает Step Over на вызове репозитория, и репозиторий успешно возвращается, отладчик обычно выполняет вызванный метод и останавливается на следующей строке в текущем фрейме. Step Over обычно не означает «пройти по каждому классу реализации, задействованному в этом вызове». Если разработчик намеренно выбирает Step Into, использует умный step-into, ставит точку останова внутри вызываемого метода или навигирует по фреймам стека после сбоя, тогда реализация становится видимой.

Это различие важно, потому что такие утверждения, как «сгенерированные фреймворки заставляют вас постоянно проходить по сгенерированным обёрткам», часто смешивают очень разные операции отладчика.

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

Сгенерированный код не меняет эту базовую модель.

Рассмотрим типичный запрос:

HTTP-запрос
    ↓
сгенерированный обработчик Kora
    ↓
Контроллер
    ↓
Сервис
    ↓
сгенерированная AOP-обёртка, если применимо
    ↓
вызов интерфейса репозитория
    ↓
сгенерированная реализация репозитория
    ↓
JDBC

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

Это тот же принцип, который применим к самому JDK. Разработчики не проходят по каждому методу ArrayList, сокета, исполнителя или драйвера JDBC во время обычной отладки лишь потому, что эти реализации присутствуют в цепочке вызовов. Они спускаются в нижние слои, когда нижний слой становится релевантным для расследования.

С сгенерированным кодом следует обращаться так же.

Исходный код приложения остаётся основной поверхностью разработки¶

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

Основная модель разработки — всё ещё написанный вручную код приложения. Разработчики пишут контроллеры, сервисы, доменные объекты, контракты репозиториев, объявления конфигурации, интеграционный код и тесты. Они работают в этих файлах, ревьюят эти файлы и рассуждают о поведении, выраженном в них.

Обычный цикл обратной связи выглядит так:

исходник
  ↓
диагностика компилятора
  ↓
тесты
  ↓
отладчик

Только когда разработчик хочет понять, что добавил фреймворк, ещё один слой становится интересным:

сгенерированный исходник

Это различие важно, потому что сгенерированный исходник можно искажать двумя противоположными способами. Одна крайность притворяется, что его не существует, и трактует каждую абстракцию фреймворка как магию. Другая крайность подразумевает, что разработчики должны постоянно читать сгенерированные файлы, чтобы понять базовое поведение приложения.

Ни то ни другое не точно.

Модель Kora ближе к такой:

Написанный вручную исходник
        │
        ├── достаточен для обычной разработки фич
        │
        ├── компилятор ловит структурные ошибки
        │
        ├── тесты проверяют поведение
        │
        └── отладчик инспектирует состояние приложения
                    │
                    └── сгенерированный исходник доступен
                        когда механика фреймворка имеет значение

Сгенерированный слой — это дополнительное свидетельство. Он не является центром каждой задачи разработки.

Хороший способ сформулировать контракт:

Сгенерированный код — это не код, который разработчики должны понимать, чтобы использовать Kora. Это код, который они могут инспектировать, когда обычной отладки недостаточно.

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

Kora генерирует исходник, а не непрозрачную модель времени выполнения¶

Не вся абстракция фреймворка одинаково инспектируема.

Фреймворк с тяжёлым рантаймом может выводить поведение из комбинации сканирования classpath, рефлексии, метаданных времени выполнения, динамических прокси, пост-процессоров, реестров перехватчиков, состояния контейнера и условной конфигурации. Ни один из этих механизмов сам по себе не плох. Зрелые фреймворки успешно их используют, и опытные разработчики учатся их отлаживать. Дело просто в том, что исполняемое поведение может быть распределено по нескольким механизмам времени выполнения, а не представлено напрямую в одном специфичном для приложения исходном артефакте.

Концептуально путь может выглядеть так:

Модель с тяжёлым рантаймом

ваш исходник
    ↓
рантайм фреймворка
    ↓
рефлексия
    ↓
динамические прокси
    ↓
метаданные контейнера
    ↓
цепочка перехватчиков
    ↓
фактическое поведение

Kora намеренно переносит значительную часть этой работы раньше:

Kora

ваш исходник
    ↓
процессоры этапа компиляции
    ↓
сгенерированный исходник
    ↓
обычный байткод JVM
    ↓
фактическое поведение

Это различие имеет последствия для отладки.

Если приложение Kora содержит сгенерированный класс графа, сгенерированный HTTP-обработчик, сгенерированную реализацию репозитория или сгенерированную AOP-обёртку, разработчик может инспектировать этот класс как конкретный результат обработки фреймворком. Вместо реконструкции того, что, должно быть, сделал контейнер времени выполнения, инженер часто может инспектировать то, что произвёл компилятор.

Этот сгенерированный артефакт становится формой истины из первых рук.

Это особенно полезно для вопросов, ответ на которые зависит от точного приложения, а не от общей документации фреймворка. Какую зависимость получил этот компонент? Какой маппер был выбран? Какой аспект оборачивает какой метод? Какой обработчик вызывает этот контроллер? Какая реализация репозитория выполняет этот запрос? В каком порядке выполняются несколько сквозных политик?

Ответ не должен оставаться концептуальным. Он может быть представлен в коде.

Сгенерированный исходник — это запасной выход¶

Самый полезный способ понять сгенерированный код в Kora — как запасной выход из абстракции.

Абстракции полезны, потому что позволяют разработчикам работать на более высоком уровне. Интерфейс репозитория легче анализировать, чем повторяющуюся церемонию JDBC. Аннотация повтора или валидации легче поддерживать, чем переписывать ту же логику обёртки в каждом сервисе. Декларативная HTTP-маршрутизация лаконичнее, чем ручная сборка каждого обработчика.

Проблема начинается только тогда, когда абстракция устраняет возможность инспектировать то, что на самом деле происходит.

Подход Kora — сохранить высокоуровневую абстракцию, сохранив путь вниз.

Разработчик может оставаться здесь:

@Repository
interface UserRepository {
    ...
}

почти для всей работы над фичами.

Но когда возникает конкретный вопрос, путь продолжается:

UserRepository
      ↓
сгенерированная реализация
      ↓
вызовы API базы данных

Точно так же разработчик может оставаться на аннотированном методе сервиса, пока порядок сквозного поведения не станет релевантным:

@Retry(...)
@Timeout(...)
public Result call() { ... }

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

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

Это сильное свойство отладки.

Go to Implementation иногда должен показывать сгенерированный код¶

Навигация IDE в сгенерированный код иногда описывается так, будто IDE не смогла понять фреймворк.

Во многих случаях верно обратное.

Предположим, приложение объявляет:

Java Kotlin

@Repository
public interface UserRepository {
    ...
}

@Repository
interface UserRepository {
    ...
}

и Kora генерирует реализацию во время компиляции. Если разработчик вызывает Go to Implementation на UserRepository, то сгенерированный класс репозитория — это валидный ответ, потому что это реализация, которую приложение фактически выполняет.

Связь прямолинейна:

UserRepository
       ↓
$UserRepository_Impl

Видеть этот класс — не сломанная навигация. Это точная навигация в исполняемую реализацию объявленного контракта.

Это может быть чрезвычайно полезно. Если разработчик хочет узнать, как связывается параметр, какой маппер вызывается, какой компонент базы данных инжектируется или как результат запроса становится доменным объектом, сгенерированная реализация — ровно тот файл, который нужно инспектировать.

Ключевой момент — намерение.

При разработке бизнес-функций разработчики часто заботятся в первую очередь о контракте репозитория и сервисе, который его использует. При расследовании поведения фреймворка они могут заботиться о сгенерированной реализации. Это разные цели навигации, и фреймворк-осведомлённый плагин IDE может сделать различие удобнее, но сама сгенерированная реализация — не ошибка.

Более сильная формулировка:

Видеть сгенерированную реализацию — не сломанная навигация. Это точная навигация в код, который фактически выполняется.

Инструменты IDE улучшают удобство, а не понятность¶

Фреймворк-осведомлённые инструменты IDE ценны, потому что могут оптимизировать навигацию под распространённые намерения. Специфичный для Kora плагин может помочь разработчикам перепрыгивать между объявлениями и сгенерированными компонентами, понимать конфигурацию или удобнее раскрывать фреймворк-специфичные связи.

Но есть архитектурное различие, которое стоит сохранить: плагин улучшает опыт; он не делает отладку возможной.

Без фреймворк-специфичной поддержки IDE у разработчиков всё равно есть обычная навигация Java и Kotlin. Сгенерированные исходники всё равно существуют. Компилятор всё равно производит диагностику. Отладчик всё равно понимает скомпилированные классы. Точки останова всё равно работают. Фреймы стека всё равно существуют. Тесты всё равно выполняют тот же код приложения.

С дополнительными инструментами, осведомлёнными о Kora, навигация и UX фреймворка могут стать удобнее:

Без фреймворк-специфичного плагина

обычная навигация Java/Kotlin
сгенерированные исходники доступны
диагностика компилятора доступна
отладчик доступен
тесты доступны

С фреймворк-специфичным плагином

всё вышеперечисленное
+
навигация с учётом Kora
+
фреймворк-специфичные удобства IDE

Это различие важно, потому что демонстрирует, что прозрачность Kora архитектурна, а не зависит от проприетарных инструментов.

Плагин IDE может сделать уже инспектируемую систему приятнее в использовании. Он не создаёт инспектируемость из ничего.

Сгенерированные репозитории превращают интерфейс в конкретную цель отладки¶

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

На уровне объявления разработчик обычно хочет компактный контракт. Метод репозитория говорит, какие данные нужны, и часто раскрывает SQL напрямую. Это подходящий уровень для большинства код-ревью и разработки приложений.

Однако во время выполнения что-то всё равно должно выполнять фактическую работу. Параметры должны быть замаплены, запрос должен быть выполнен, результат должен быть прочитан, а значения должны быть преобразованы в типы приложения.

Kora генерирует эту реализацию на этапе компиляции.

Это даёт разработчику два полезных представления одного и того же поведения.

Первое — лаконичное объявление на уровне приложения:

контракт репозитория
    +
запрос
    +
тип возврата

Второе — реализация на уровне выполнения:

компонент базы данных
    ↓
маппинг параметров
    ↓
выполнение запроса
    ↓
маппинг результата
    ↓
возвращаемое значение

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

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

Поэтому сгенерированный репозиторий — не просто вывод компилятора. Это артефакт отладки, который объясняет, как высокоуровневый контракт становится работой с базой данных.

Сгенерированные HTTP-обработчики раскрывают реальный путь запроса¶

Обработка HTTP следует тому же принципу.

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

Kora генерирует инфраструктуру.

Для обычной работы разработчик видит:

объявление HTTP-маршрута
      ↓
метод контроллера
      ↓
бизнес-логика

Когда необходима более глубокая инспекция, полный путь можно проследить:

запрос
   ↓
сгенерированный HTTP-обработчик
   ↓
извлечение параметров / маппинг запроса
   ↓
перехватчики
   ↓
контроллер
   ↓
маппинг ответа
   ↓
ответ

Этот сгенерированный обработчик может ответить на очень конкретные вопросы отладки. Был ли выбран ожидаемый маппер? Какой параметр маршрута читается? Какой перехватчик выполняется? Действительно ли достигнут метод контроллера? Какой маппер ответа отвечает за финальный вывод?

Разработчику не нужно выводить всё это из метаданных фреймворка. Сгенерированный обработчик — это исполняемый мост.

Опять же, важный момент не в том, что разработчики должны рутинно просматривать каждый сгенерированный HTTP-класс. Дело в том, что когда HTTP-граница ведёт себя неожиданно, финальная интерпретация фреймворка видима.

Сгенерированный AOP — один из сильнейших аргументов отладки¶

AOP — это область, где генерация на этапе компиляции даёт одно из самых ясных преимуществ прозрачности.

Сквозное поведение концептуально просто на уровне аннотаций. Метод может объявлять валидацию, повтор, таймаут, circuit breaker, fallback, транзакцию, кеш, логирование или другую политику. Сложность появляется, когда взаимодействуют несколько политик.

Модель перехватчика времени выполнения должна как-то собрать цепочку. Опытные пользователи фреймворка могут знать правила порядка, правила прокси, правила самовызова и механику регистрации. Но когда появляется сложное взаимодействие, разработчику, возможно, придётся реконструировать фактическую цепочку из конфигурации, метаданных, конвенций фреймворка и объектов времени выполнения.

Kora генерирует обёртку как исходник.

Концептуально результат может напоминать:

Сгенерированный AOP-прокси
        ↓
fallback
        ↓
circuit breaker
        ↓
retry
        ↓
timeout
        ↓
super.businessMethod()

Точная последовательность зависит от аннотаций и правил фреймворка, но важное свойство в том, что последовательность становится кодом.

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

Это меняет вопрос отладки с:

«Как фреймворк собрал свою цепочку перехватчиков во время выполнения?»

на:

«Что делает этот сгенерированный метод?»

Второй вопрос — обычный вопрос программирования.

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

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

Валидация становится явным кодом¶

Валидация иллюстрирует тот же тезис в меньшем масштабе.

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

Сгенерированный код даёт этот ответ.

Вместо того чтобы рассматривать «валидация произошла» как невидимое событие фреймворка, разработчик может инспектировать обёртку, которая её выполняет. Сгенерированный класс раскрывает конкретные валидаторы и путь в исходный метод.

Это может быть особенно полезно, когда выведенные обобщённые типы, вложенная валидация, маппинг или композиция аннотаций создают неочевидный результат. Сгенерированный исходник становится точным представлением интерпретации фреймворком объявлений.

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

Сгенерированный код отказоустойчивости делает композицию политик видимой¶

Политики отказоустойчивости особенно чувствительны к порядку.

Таймаут внутри повтора ведёт себя иначе, чем повтор внутри таймаута. Circuit breaker снаружи повтора наблюдает другие сбои, чем circuit breaker внутри повтора. Размещение fallback меняет, какие исключения он может видеть. Это не косметические различия; они влияют на задержку, усиление нагрузки, классификацию сбоев и видимое пользователю поведение.

В декларативном API разработчик хочет, чтобы политика оставалась лаконичной:

Java Kotlin

@Fallback(...)
@CircuitBreaker(...)
@Retry(...)
@Timeout(...)
public Result call() {
    ...
}

@Fallback(...)
@CircuitBreaker(...)
@Retry(...)
@Timeout(...)
fun call(): Result {
    ...
}

Но когда точная композиция имеет значение, сгенерированный AOP-класс предоставляет конкретное представление того, что делает фреймворк.

Это означает, что производственная отладка может перейти от абстрактных вопросов к исполняемым. Инженер может спросить, какой слой видит исключение таймаута, оборачивает ли повтор таймаут, наблюдает ли circuit breaker исчерпанные повторы или отдельные попытки и обрабатывает ли fallback самый внешний сбой. Эти связи представлены напрямую в сгенерированном потоке управления.

Это сильный пример того, почему генерация кода может улучшать, а не снижать отлаживаемость.

Сгенерированный код ценен, потому что он читаем¶

Ко всему вышесказанному есть важная оговорка: не весь сгенерированный код одинаково полезен.

Сгенерированный исходник может быть технически доступен и при этом практически нечитаем. Генератор кода мог бы испускать гигантские конечные автоматы, глубоко вложенные синтетические имена, бессмысленные временные переменные или структуры, оптимизированные целиком под компилятор, а не под человеческую инспекцию.

В этом случае фраза «сгенерированный исходник там есть» не была бы сильным аргументом отладки.

Архитектурная цель Kora иная. Фреймворк явно представляет сгенерированный код как то, что разработчики могут инспектировать, отлаживать и ревьюить. Сгенерированный граф выглядит как логика построения компонентов. Сгенерированные репозитории выглядят как конкретные интеграции с базами данных. Сгенерированные AOP-обёртки выглядят как последовательные вызовы методов вокруг исходной реализации. Сгенерированная HTTP-инфраструктура отражает путь запроса.

Поэтому полезный вопрос не таков:

«Генерирует ли фреймворк код?»

а:

«Достаточно ли читаем сгенерированный код, чтобы объяснить, что делает фреймворк?»

Это релевантный критерий отладки.

Сгенерированный код ценен, когда он действует как читаемое человеком промежуточное представление между высокоуровневыми объявлениями и байткодом.

Сгенерированный граф — это конкретизированное связывание приложения¶

Внедрение зависимостей — ещё одна область, где генерация на этапе компиляции может превратить абстрактную модель контейнера в инспектируемый код приложения.

Разработчики в целом не хотят вручную конструировать каждый сервис. DI-фреймворк должен управлять построением, жизненным циклом, переиспользованием, модулями, конфигурацией и разрешением зависимостей. Разработчик хочет описать структуру зависимостей, а не вручную писать полную последовательность бутстрапа.

Kora строит и валидирует этот граф во время компиляции.

Поэтому сгенерированный граф представляет ответ фреймворка на такие вопросы:

Какой компонент удовлетворяет эту зависимость?
Какая фабрика модуля создаёт этот объект?
Какая реализация была выбрана?
В каком направлении текут зависимости?
Какие компоненты участвуют в жизненном цикле?
Какая зависимость вызвала ошибку графа?

Большую часть времени разработчику не нужно инспектировать исходник графа, потому что сигнатуры конструкторов и диагностика компилятора уже дают достаточно информации. Однако когда вопрос связывания становится тонким, сгенерированный граф можно открыть.

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

Разработчик может перейти от:

«Что решил контейнер?»

к:

«Покажи мне сгенерированный путь построения.»

Это ровно тот вид запасного выхода, который делает абстракцию более заслуживающей доверия.

Генерация на этапе компиляции устраняет целые категории отладки времени выполнения¶

Сгенерированный исходник помогает, когда отладка необходима, но более крупная выгода в том, что многие структурные проблемы вообще никогда не доходят до отладки времени выполнения.

Отсутствующая зависимость, неоднозначная зависимость, цикл, недопустимый маппинг, недопустимый контракт репозитория или некорректное использование AOP часто могут падать во время компиляции. Обработка графа и сгенерированный код Kora проверяются до запуска приложения.

Это меняет экономику отладки.

Сравнения фреймворков часто фокусируются только на вопросе:

Насколько легко отлаживать сбой, когда он произошёл?

Лучшее сравнение также спрашивает:

Сколько сбоев вообще становятся ошибками времени выполнения?

Самую лёгкую ошибку времени выполнения отлаживать ту, которую компиляция предотвратила от превращения в ошибку времени выполнения.

Рассмотрим отсутствующую зависимость. В модели с тяжёлым рантаймом приложение может обнаружить проблему во время инициализации контекста или когда активируется конкретный путь. В Kora разрешение графа может отклонить приложение во время компиляции.

Рассмотрим недопустимый сгенерированный контракт репозитория. Вместо ожидания, пока приложение выполнит метод и обнаружит несовместимость, обработка аннотаций и компиляция могут вскрыть проблему раньше.

Рассмотрим некорректное использование AOP. Если генератор не может произвести валидную обёртку, сама сборка может упасть.

Поэтому цикл обратной связи таков:

правка
  ↓
компиляция
  ↓
граф / процессоры / система типов валидируют
  ↓
точная ошибка
  ↓
исправление

Только поведение, пережившее эту структурную валидацию, переходит к тестам времени выполнения и отладке.

Это не означает, что Kora предотвращает все ошибки времени выполнения. Ошибки бизнес-логики, проблемы конкурентности, сетевые сбои, некорректная семантика SQL, исчерпание ресурсов и многие другие проблемы остаются заботами времени выполнения. Но сокращение числа структурных сбоев фреймворка, достигающих времени выполнения, само по себе является преимуществом отладки.

Ошибки компилятора — часть истории отладки¶

Полезно расширить определение отладки за пределы интерактивного отладчика.

В современной разработке отладка означает поиск причины некорректного поведения. Иногда инструмент — точка останова. Иногда — стектрейс. Иногда — провал теста. Иногда — диагностика компилятора.

Kora намеренно толкает ошибки фреймворка в последнюю категорию.

Это создаёт более короткий путь от ошибки к объяснению. Вместо запуска приложения, воспроизведения запроса, входа в конкретный путь и инспекции сбоя времени выполнения разработчик может получить прямой сбой компиляции, описывающий отсутствующую или неоднозначную зависимость.

Это не просто безопасность этапа компиляции. Это отладка, сдвинутая раньше в жизненном цикле.

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

Поэтому архитектура этапа компиляции влияет на отладку задолго до того, как запускается JVM-отладчик.

Стек-трейсы могут быть более явными, не будучи более красивыми¶

Есть один момент, где сгенерированный код может легитимно добавлять шум: стек-трейсы.

Если сгенерированный обработчик или AOP-обёртка участвует в выполнении, его фрейм может появиться в стек-трейсе. Чисто бизнес-стек был бы, очевидно, короче, если бы инфраструктура фреймворка не существовала, но инфраструктура фреймворка существует в каждой нетривиальной системе. Полезный вопрос — предоставляет ли её представление информацию.

Сгенерированный фрейм может быть очень информативным, потому что он может быть специфичен для приложения.

Вместо того чтобы видеть только общую машинную работу времени выполнения, такую как:

Proxy.invoke()
MethodInterceptor.invoke()
ReflectiveMethodInvocation.proceed()
...

стек-трейс может включать конкретный сгенерированный класс, связанный с конкретным сервисом или компонентом, чей вызов оборачивается.

Это не обязательно красивее. Оно всё равно может добавлять фреймы. Но «больше фреймов» и «менее отлаживаемо» — не одно и то же.

Сгенерированный класс может сказать разработчику, где в фактическом исполняемом пути произошёл сбой. Если стек пересекает $UserService__AopProxy, это может раскрыть, что был задействован аспект. Если он пересекает сгенерированную реализацию репозитория, граница базы данных видима. Если он пересекает сгенерированный обработчик, инфраструктура маршрута видима.

Поэтому честная позиция нюансирована:

Сгенерированные классы могут делать стек-трейсы длиннее, но эти фреймы часто раскрывают реальный путь выполнения, а не скрывают его.

Для диагностики явность может быть ценнее эстетической чистоты.

Отладка границы фреймворка отличается от отладки бизнес-логики¶

Повторяющаяся ошибка в обсуждениях отлаживаемости — рассматривать всю отладку как одно действие.

Существует как минимум два различных случая.

Первый — бизнес-отладка:

Почему этот заказ получил неверную цену?
Почему этот пользователь был сочтён неактивным?
Почему произошёл этот переход состояния?

Релевантный код обычно является кодом приложения. Сгенерированная инфраструктура фреймворка в основном нерелевантна.

Второй — отладка границы фреймворка:

Почему был выбран этот маппер?
Почему этот репозиторий возвращает этот тип?
Почему эта зависимость связана здесь?
Почему валидация выполнилась до повтора?
Почему этот эндпоинт использует этот обработчик?
Почему этот перехватчик выполняется?

Здесь интерпретация фреймворка имеет значение.

Сгенерированный исходник Kora ценен в первую очередь во втором случае.

Поэтому архитектура сохраняет чистое разделение:

Бизнес-проблема
    ↓
отлаживать написанный вручную код

Проблема границы фреймворка
    ↓
инспектировать сгенерированный код, когда полезно

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

Точки останова в сгенерированном коде иногда лучшие¶

Поскольку сгенерированный исходник — это обычный исходник, разработчики могут ставить в нём точки останова, когда это полезно.

Предположим, HTTP-параметр маппится некорректно. Точка останова в контроллере может показать только уже неверное значение. Точка останова в сгенерированном обработчике может раскрыть, где было извлечено значение и какой маппер его преобразовал.

Предположим, поведение повтора удивляет. Точка останова в бизнес-методе раскрывает, сколько раз метод был вызван, но точка останова в сгенерированной обёртке отказоустойчивости может раскрыть, почему была запланирована ещё одна попытка или почему исключение было классифицировано как неповторяемое.

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

Это не примеры того, как сгенерированный код становится обязательным. Это примеры того, как сгенерированный код увеличивает число полезных точек наблюдения.

Фреймворк, который раскрывает больше конкретных точек наблюдения, даёт инженерам больше вариантов отладки.

Системы динамических прокси тоже можно отлаживать, но навигация может быть менее специфична для приложения. Класс прокси может создаваться во время выполнения, цепочка перехватчиков может собираться из метаданных, а видимое пользователю объявление исходника может не отображаться напрямую в один конкретный файл исходника, представляющий всё поведение.

Сгенерированная реализация Kora предоставляет этот маппинг.

Интерфейс репозитория может иметь сгенерированный класс репозитория.

Сервис с аспектами может иметь сгенерированный AOP-подкласс.

Объявление маршрута может иметь сгенерированный обработчик.

Объявление графа приложения может иметь сгенерированное связывание.

Это означает, что Go to Implementation часто может приземлиться в нечто значимое и стабильное: код, представляющий обработанное объявление этого приложения.

Ценность не в том, что сгенерированный код по своей сути превосходит любой механизм времени выполнения. Ценность в том, что связь между объявлением и выполнением явна и адресуема через исходник.

Генерация исходника даёт ревьюерам второй взгляд¶

Сгенерированный исходник также полезен вне интерактивной отладки.

Во время сложного код-ревью ревьюер может захотеть проверить, что подразумевает объявление. Если изменение добавляет несколько аспектов, ревьюер может инспектировать сгенерированную обёртку после компиляции. Если контракт репозитория меняется, сгенерированная реализация может раскрыть фактический маппинг. Если изменение графа производит неожиданную зависимость, сгенерированное связывание может помочь объяснить её.

Это создаёт два уровня ревью:

Намерение
  ↓
написанное вручную объявление

Реализация
  ↓
сгенерированный исходник

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

Это полезное свойство, потому что оно держит код приложения лаконичным, не заставляя ревьюеров слепо доверять скрытой машинной работе.

Сгенерированный код также улучшает анализ инцидентов¶

Та же прозрачность важна в работе с производственными инцидентами.

Предположим, телеметрия предполагает, что поведение повторов усиливает задержку. Команда может инспектировать сгенерированную обёртку отказоустойчивости, чтобы проверить фактический порядок композиции вокруг затронутого метода сервиса.

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

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

Предположим, приложение стартует с конфигурацией зависимостей, которая кажется неверной. Сгенерированный граф может раскрыть конкретный путь построения.

Это не заменяет телеметрию времени выполнения, логи, трассы, метрики или профилирование кучи и CPU. Они остаются необходимыми. Сгенерированный исходник просто предоставляет ещё один слой свидетельств, когда инцидент пересекает поведение фреймворка.

Сгенерированный код — лучшая истина из первых рук, чем память¶

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

Но память не всегда лучший источник отладки.

Она может быть устаревшей. Она может быть из другой версии фреймворка. Она может путаться с другим проектом. Она может упускать конфигурацию, специфичную для текущего приложения.

Сгенерированный код отражает текущую сборку.

Это даёт ему полезное эпистемическое свойство: это локальное свидетельство.

Инженер может сравнить допущения с тем, что произвело это точное приложение.

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

Нейро-технологии делают сгенерированный исходник ценнее, чем раньше¶

нейро-агенты кодирования меняют экономику инспектируемого кода.

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

нейро-агент может выполнить эту фильтрацию.

Разработчик может спросить:

Почему эта зависимость пересоздаётся?
Какой компонент графа производит этот объект?
Покажи мне, где повтор оборачивает таймаут.
Какой маппер выбран для этого метода репозитория?
Проследи этот HTTP-запрос от обработчика до контроллера.
Почему этот валидатор вызывается здесь?
Какой сгенерированный класс реализует этот репозиторий?
Объясни только фреймы, задействованные в этом стек-трейсе.
Сравни аннотации на этом методе со сгенерированным порядком вызовов.

Рабочий процесс становится:

сгенерированный исходник
       ↓
нейро-агент
       ↓
сфокусированное объяснение
       ↓
разработчик проверяет релевантное поведение

Это значительное изменение.

Ценность сгенерированного исходника больше не зависит от готовности каждого разработчика вручную читать каждую сгенерированную строку. Важно то, что исполняемое поведение существует в форме, которую могут инспектировать и люди, и машины.

Людям больше не нужно читать каждую сгенерированную строку самим. Важно то, что исполняемое поведение существует в форме, которую могут инспектировать и люди, и машины.

Это делает прозрачность более ценной в нейро-эпоху, а не менее.

Нейро-технологии могут следовать за точным приложением вместо угадывания фреймворка¶

Это особенно важно для отладки фреймворков, потому что нейросетевые модели склонны к правдоподобным обобщениям.

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

Сгенерированный код меняет задачу.

Вместо вопроса:

«Как Kora обычно это делает?»

агент может инспектировать:

«Что эта сборка сгенерировала для этого метода?»

Это превращает проблему вывода в проблему чтения кода.

Нейро-технологии полезнее, когда могут обосновывать объяснения в конкретном локальном исходнике. То же применимо к связыванию зависимостей, маппингам, реализациям репозиториев и HTTP-обработчикам.

Поэтому сгенерированные артефакты Kora уменьшают объём поведения фреймворка, которое модели приходится угадывать.

Компилятор, отладчик, тесты и нейро-технологии образуют единый диагностический стек¶

Сильнейшая история отладки — не какой-то один инструмент в изоляции. Это взаимодействие нескольких инструментов.

Архитектура этапа компиляции Kora создаёт полезную прогрессию:

1. компилятор
   ловит структурные ошибки

2. тесты
   проверяют ожидаемое поведение

3. отладчик
   инспектирует состояние приложения и поток управления

4. сгенерированный исходник
   раскрывает интерпретацию фреймворка

5. нейро-агент
   объясняет и связывает свидетельства

Проблема может остановиться на самом раннем слое, способном её объяснить.

Отсутствующая зависимость может никогда не потребовать теста.

Неверное бизнес-правило может никогда не потребовать сгенерированного исходника.

Проблема маппера может быть раскрыта тестом и объяснена сгенерированным репозиторием.

Неожиданное взаимодействие аспектов может потребовать отладчика плюс сгенерированной AOP-обёртки.

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

Самую лёгкую ошибку отлаживать ту, которая никогда не достигает времени выполнения¶

Одно из сильнейших следствий архитектуры Kora заслуживает прямого утверждения.

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

DI на этапе компиляции и генерация меняют эту границу.

Если компилятор отклоняет отсутствующую зависимость, нет инцидента времени выполнения с отсутствующим бином, который нужно отлаживать.

Если недопустимый цикл графа предотвращает компиляцию, сессия отладки запуска не нужна.

Если генерация репозитория падает, потому что объявленный контракт не может быть обработан, проблема появляется до развёртывания.

Если генерация AOP не может произвести валидный код, сборка падает до запуска сервиса.

Это приводит к полезному принципу:

Самую лёгкую ошибку времени выполнения отлаживать ту, которую компилятор предотвратил от превращения в ошибку времени выполнения.

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

Это лучшее место для траты времени на отладку.

У сгенерированного кода всё ещё есть стоимость¶

Заслуживающий доверия аргумент должен признавать компромиссы.

Сгенерированный код вносит больше файлов в вывод сборки. Имена классов могут сначала казаться незнакомыми. Стек-трейсы могут содержать сгенерированные фреймы. Результаты поиска в IDE могут включать классы, которые разработчики не писали. Go-to-implementation иногда может вести в сгенерированные файлы, когда разработчик думал на уровне объявления. Инструменты сборки должны корректно регистрировать корни сгенерированных исходников. Инкрементальная компиляция и поведение процессоров становятся частью системы сборки.

Это реальные затраты.

Аргумент не в том, что генерация бесплатна.

Аргумент в том, что эти затраты следует сравнивать с альтернативами. Поведение фреймворка должно где-то жить. Если оно не представлено в сгенерированном специфичном для приложения исходнике, оно может жить в метаданных времени выполнения, рефлексивной логике, инфраструктуре прокси, правилах конфигурации, состоянии контейнера или внутренностях фреймворка.

Релевантный вопрос не таков:

сгенерированный код
vs
никакой машинной работы фреймворка

Он таков:

сгенерированная, инспектируемая машинная работа
vs
машинная работа, компонуемая во время выполнения

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

Сгенерированные классы не следует путать с владением вручную¶

Ещё одна забота — ответственность за сопровождение.

Разработчики не должны вручную редактировать сгенерированные классы. Они должны менять объявление, которое их произвело. Если сгенерированный репозиторий неверен, потому что неверен контракт репозитория, исправление принадлежит исходнику репозитория или объявлению маппинга. Если AOP-обёртка имеет неверное поведение, потому что аннотации упорядочены некорректно, исправление принадлежит написанному вручную объявлению метода. Если связывание графа неверно, потому что компонент был предоставлен некорректно, исправление принадлежит определению модуля или компонента.

Сгенерированный код — это поверхность наблюдения, а не поверхность владения.

Это различие предотвращает распространённый анти-паттерн, когда команды начинают патчить сгенерированный вывод напрямую.

Полезная модель:

Написанный вручную исходник
    = намерение и владение

Сгенерированный исходник
    = интерпретация фреймворка и свидетельство

Отладка может инспектировать оба. Сопровождение обычно должно модифицировать первое.

Читаемая генерация усиливает абстракцию, а не ослабляет её¶

Существует распространённое заблуждение, что если разработчикам когда-либо нужно инспектировать реализацию абстракции, значит, абстракция провалилась.

Это слишком строго.

Хорошие абстракции снижают потребность понимать детали реализации во время обычной работы. Они не обязательно запрещают инспекцию.

На самом деле, абстракция может быть более заслуживающей доверия, когда её реализация остаётся доступной.

Сгенерированный исходник Kora следует этому принципу. Контроллеры остаются контроллерами, репозитории остаются репозиториями, а политики отказоустойчивости остаются декларативными. Разработчик не обязан отказываться от этих абстракций. Но фреймворк не настаивает на том, чтобы реализация оставалась невидимой.

Это создаёт полезную комбинацию:

высокоуровневый API для продуктивности
        +
инспектируемая низкоуровневая реализация
        =
абстракция без непрозрачности

Для отладки это часто идеальный баланс.

Прозрачность фреймворка важнее минимализма фреймворка¶

Фреймворк может быть маленьким и при этом трудным для отладки, если его поведение неявно.

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

Поэтому полезная метрика — не просто сколько классов фреймворка существует или сколько кода сгенерировано.

Более релевантные вопросы:

Может ли разработчик проследить объявление до выполнения?
Можно ли инспектировать фактическое связывание?
Можно ли увидеть эффективный порядок AOP?
Можно ли понять выполнение репозитория?
Можно ли проследить обработку HTTP-запроса?
Могут ли диагностики компилятора ловить структурные ошибки?
Можно ли ставить точки останова на границах фреймворка?
Может ли нейро-агент объяснить текущий сгенерированный путь на основе свидетельств?

Kora хорошо справляется с этими измерениями, потому что генерация кода — часть её модели прозрачности, а не просто приём оптимизации.

Сгенерированный код может улучшать введение в проект¶

То же свойство, которое помогает отладке, помогает и новым инженерам.

Разработчик, изучающий Kora, может сразу понимать контроллеры и сервисы, но быть незнакомым с DI на этапе компиляции или сгенерированным AOP. Вместо изучения только из концептуальной документации они могут инспектировать то, что фреймворк сгенерировал для небольшого примера.

Последовательность обучения становится:

объявление
   ↓
сгенерированная реализация
   ↓
отладчик
   ↓
наблюдаемое поведение

Это особенно полезно для инженеров, приходящих из фреймворков с прокси времени выполнения, потому что они могут видеть контраст напрямую. Аспект Kora не просто описывается как AOP на этапе компиляции; сгенерированный подкласс демонстрирует, что это означает.

Фреймворк становится легче учить, потому что у абстракции есть видимая реализация.

Сгенерированный код помогает отделять ошибки фреймворка от ошибок приложения¶

Ещё одно практическое преимущество отладки — локализация сбоев.

Когда поведение неожиданно, команде часто нужно определить, принадлежит ли проблема логике приложения, интерпретации фреймворка или нижележащей интеграции.

Сгенерированный исходник может помочь установить эту границу.

Предположим, приложение объявляет метод репозитория и получает неожиданные данные. Разработчик может инспектировать сгенерированную реализацию. Если сгенерированный маппинг параметров соответствует объявлению, следующим подозреваемым может быть SQL или состояние базы данных. Если сгенерированный маппинг явно не то, что подразумевает объявление, более сильным подозреваемым становится процессор фреймворка или конфигурация маппинга.

Предположим, порядок аспектов ведёт себя неожиданно. Сгенерированная обёртка раскрывает, произвёл ли Kora ожидаемую последовательность вызовов. Если да, проблема может быть в семантике политики, а не в генерации. Если нет, проблема смещается к интерпретации аннотаций или поведению фреймворка.

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

Эта способность инспектировать границу фреймворка может резко сузить пространство поиска при отладке.

Истина из первых рук важнее всего в трудных ошибках¶

Простые ошибки редко нуждаются во внутренностях фреймворка.

Сгенерированный слой становится наиболее ценным именно тогда, когда проблема трудна.

Трудные ошибки часто включают расхождение между допущениями и реальностью. Код выглядит корректным, конфигурация выглядит корректной, фреймворк должен вести себя определённым образом, и всё же приложение делает что-то неожиданное.

В этот момент ещё один объясняющий документ менее полезен, чем конкретное свидетельство.

Сгенерированный исходник — это конкретное свидетельство.

Он представляет интерпретацию фреймворком объявлений, использованных в этой сборке.

Вот почему генерацию кода не следует оценивать только как затрату опыта разработчика. В трудных условиях она может быть самым полезным артефактом отладки в системе.

Более точная модель отладки¶

Историю отладки можно поэтому резюмировать как многослойный процесс принятия решений, а не как «разработчики отлаживают сгенерированный код».

Начните с приложения:

Ошибка в бизнес-логике?
        ↓ да
отлаживать написанный вручную код

Если нет, спросите, объясняет ли уже сборка проблему:

Есть ли диагностика компилятора / графа / процессора?
        ↓ да
исправить структурную проблему

Если поведение появляется только во время выполнения:

Может ли тест его воспроизвести?
        ↓ да
использовать тест + отладчик

Если вопрос пересекает границу фреймворка:

Нужно точное связывание / маппинг / AOP / поведение обработчика?
        ↓ да
инспектировать сгенерированный исходник

Если сгенерированный класс велик или незнаком:

нейро-агент
   ↓
извлечь и объяснить релевантный путь

Это гораздо более реалистичное описание разработки на Kora, чем идея, что каждая сессия отладки начинается в build/generated.

Реальное сравнение — инспектируемый механизм против скрытого механизма¶

Дебаты вокруг сгенерированного кода часто начинаются с неверной исходной точки.

Разработчики сравнивают:

написанный вручную код приложения

с:

написанный вручную код приложения + сгенерированный код

и заключают, что второе сложнее.

Но фреймворку нужна машинная работа в обоих случаях.

Реальное сравнение ближе к:

Фреймворк A

написанный вручную исходник
+
рефлексия времени выполнения
+
динамические прокси
+
метаданные контейнера
+
реестры перехватчиков
+
связывание времени выполнения

против:

Kora

написанный вручную исходник
+
сгенерированный специфичный для приложения исходник
+
обычные скомпилированные классы

В обеих системах есть поведение фреймворка. Разница в том, где оно материализуется и насколько легко его инспектировать.

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

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

Прозрачность — это не то же самое, что простота¶

Также полезно различать прозрачность и простоту.

Сгенерированный AOP вокруг нескольких политик отказоустойчивости всё ещё может быть сложным. Большой граф приложения всё ещё может содержать много компонентов. Сгенерированный HTTP-обработчик всё ещё может координировать несколько маппингов и перехватчиков. Генерация кода не делает сложное поведение волшебным образом простым.

Что она делает — делает сложность видимой.

Это важно, потому что отладка сложных систем требует точных представлений.

Явную сложную программу часто легче анализировать, чем неявное сложное состояние времени выполнения.

Поэтому преимущество отладки Kora не следует описывать как «сложности нет». Более защитимое утверждение:

Фреймворк пытается превратить сложность фреймворка в обычный исходный код, который существующие JVM-инструменты могут инспектировать.

Это гораздо более сильный и технически точный аргумент.

Сгенерированный исходник работает с существующим JVM-тулчейном¶

Ещё одна выгода генерации обычного исходника Java и Kotlin — совместимость инструментов.

Исходник проходит через обычный компилятор.

Получившиеся классы участвуют в обычных стек-трейсах.

Отладчик может понимать сопоставления строк и методы.

IDE может индексировать символы.

Статический анализ может инспектировать сгенерированные типы.

Инструменты сборки могут рассматривать их как наборы исходников.

Тесты выполняют те же скомпилированные классы.

нейро-инструменты могут разбирать их как исходник языка программирования.

Это важно, потому что Kora не требует отдельного проприетарного отладчика, чтобы сделать поведение фреймворка видимым.

Фреймворк переиспользует зрелый тулчейн-экосистему JVM.

Это держит модель отладки знакомой, даже когда сгенерированная реализация нова для разработчика.

Почему это различие важно для более широкого дизайна Kora¶

Сгенерированный код — не изолированный приём реализации в Kora. Он связан с несколькими более широкими принципами фреймворка.

Внедрение зависимостей на этапе компиляции означает, что связывание можно валидировать и генерировать.

Тонкие абстракции означают, что сгенерированный код может оставаться близким к JDBC, HTTP, Kafka, gRPC и другим знакомым технологиям.

Один рекомендованный подход снижает число конкурирующих моделей времени выполнения, которые разработчику приходится реконструировать.

Сильная типизация увеличивает объём структуры, которую компилятор может валидировать.

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

Быстрое тестирование предоставляет ещё один дешёвый способ проверить сгенерированную модель приложения.

Ассистирование нейро-технологий выигрывает, потому что поведение фреймворка представлено в исходнике.

Эти свойства усиливают друг друга.

Поэтому аргумент отладки естественно вписывается в общую архитектуру Kora: перенести скрытую работу времени выполнения в явные артефакты этапа компиляции, а затем позволить стандартному JVM-тулчейну инспектировать эти артефакты.

Что сгенерированный код не решает¶

Сбалансированный взгляд должен также быть ясен о пределах.

Сгенерированный исходник не продиагностирует плохой план SQL-запроса.

Он не объяснит, почему удалённый сервис перегружен.

Он не определит, уместна ли политика повторов архитектурно.

Он не найдёт каждое состояние гонки.

Он не заменит распределённую трассировку.

Он не заменит анализ кучи, профилирование CPU, наблюдаемость базы данных, сетевую диагностику или производственные метрики.

Он не сделает плохо спроектированную бизнес-логику лёгкой для понимания.

Сгенерированный код помогает в первую очередь на границе, где объявления фреймворка становятся исполняемым поведением.

Это важная граница, но только одна часть производственной отладки.

Поэтому корректный аргумент не «сгенерированный код решает отладку». Это «сгенерированный код делает поведение фреймворка более инспектируемым».

Сгенерированную обёртку часто легче объяснить, чем цепочку времени выполнения¶

Это различие становится особенно видимым при обучении или ревью сквозного поведения.

Предположим, разработчик видит неожиданный таймаут после нескольких повторов.

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

В Kora сгенерированная обёртка может раскрыть конкретную композицию для этого точного метода.

Инженер может рассуждать о ней как об обычных вложенных вызовах:

fallback(
    circuitBreaker(
        retry(
            timeout(
                businessMethod()
            )
        )
    )
)

Реальный сгенерированный код может быть более детальным, но структура управления инспектируема.

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

Сгенерированная реализация может быть лучшей документацией, чем общая диаграмма¶

Документация должна оставаться общей, потому что она описывает фичу фреймворка через множество возможных приложений.

Сгенерированный исходник специфичен для приложения.

Это означает, что он может отвечать на вопросы, на которые документация не может ответить напрямую.

Документация может объяснить, как работает генерация репозиториев. Сгенерированный репозиторий показывает, какой маппер использует этот репозиторий.

Документация может объяснить правила порядка AOP. Сгенерированная обёртка показывает порядок для этого конкретного метода.

Документация может объяснить внедрение зависимостей. Сгенерированный граф показывает выбранные зависимости в этой сборке.

Документация может объяснить маппинг запросов. Сгенерированный обработчик показывает фактический маршрут и мапперы.

Это даёт сгенерированному исходнику уникальную роль отладки: это документация фреймворка, автоматически специализированная под текущее приложение.

Это мощный способ думать о нём.

Нейро-технологии превращают специфичную для приложения документацию в разговор¶

Как только нейро-агент может читать эти сгенерированные артефакты, разработчик может взаимодействовать с этой специфичной для приложения документацией разговорно.

Вместо открытия большого сгенерированного графа и ручного прослеживания конструкторов инженер может спросить:

«Почему UserService получает эту реализацию?»

Вместо сканирования AOP-обёртки:

«Покажи мне, где повтор оборачивает таймаут, и объясни, какое исключение наблюдает circuit breaker.»

Вместо чтения сгенерированного обработчика:

«Проследи POST /users/{id} от сопоставления маршрута до параметра контроллера.»

Вместо поиска в реализации репозитория:

«Какой маппер преобразует вторую колонку результата, и где он предоставлен?»

нейро-агент не выдумывает ответ. Он интерпретирует сгенерированный исходник.

Это идеальное отношение между нейро-технологиями и прозрачностью фреймворка.

Сгенерированный исходник снижает зависимость от племенных знаний¶

Отладка фреймворка часто становится трудной, когда корректное поведение зависит от правил, которые опытные разработчики знают, но кодовая база не раскрывает напрямую.

Эти правила становятся племенными знаниями:

эта аннотация перехватывается только в определённых ситуациях;
этот прокси не применяется к самовызову;
этот компонент создан, потому что условие classpath что-то активировало;
этот перехватчик имеет конкретный приоритет;
этот маппер выбран через конвенцию, скрытую в другом месте.

Kora не может устранить все знания фреймворка, но сгенерированный исходник переносит многие решения из памяти в код.

Сгенерированный артефакт может ответить, что произошло.

Это снижает потребность помнить невидимое состояние времени выполнения.

Это полезно для введения в проект, код-ревью, реагирования на инциденты и разработки при поддержке нейро-технологий в равной мере.

Явный лишний фрейм может быть лучше невидимого решения¶

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

Это возражение понятно, но следует рассмотреть альтернативу.

Сгенерированный фрейм — это явное свидетельство того, что вызов прошёл через конкретную обёртку.

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

Для отладки явное свидетельство часто предпочтительнее невидимой элегантности.

Поэтому правильная цель оптимизации — не «наименьшее число видимых фреймов фреймворка». Это «самый быстрый путь к пониманию фактического выполнения».

Сгенерированный код Kora спроектирован вокруг второго.

Генерация кода переносит сложность раньше¶

Ещё один способ описать модель Kora — что она сдвигает сложность фреймворка с времени выполнения на время сборки.

Во время сборки процессоры разрешают зависимости, валидируют структуру графа, анализируют объявления и генерируют классы.

Во время выполнения JVM выполняет эти скомпилированные классы.

Это имеет следствие для отладки помимо производительности.

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

Ни то ни другое не исчезает, но одно часто легче инспектировать детерминированно.

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

Это особенно полезно для трудных взаимодействий фреймворка.

Лучшая поверхность отладки — та, которую можно игнорировать, пока она не понадобится¶

Хороший диагностический механизм не должен навязывать себя каждой задаче.

Сгенерированный исходник работает лучше всего, когда обладает ровно этим свойством.

Во время рутинной работы над фичами разработчики могут его игнорировать.

Во время код-ревью они могут его игнорировать, если только взаимодействие фреймворка не имеет значения.

Во время тестирования они могут его игнорировать, если только тест не раскрывает проблему границы.

Во время отладки они могут оставаться в коде приложения, если только поведение не становится неясным.

Когда необходимо, сгенерированная реализация доступна.

Это сильная модель эргономики, потому что она сочетает абстракцию с инспектируемостью.

Практический пример: отладка репозитория¶

Представьте, что метод репозитория неожиданно возвращает объект с одним отсутствующим полем.

Разумное расследование может протекать следующим образом.

Во-первых, инспектируйте SQL и объявленный тип возврата. Если проблема очевидна там, исправьте её.

Во-вторых, запустите релевантный тест и воспроизведите проблему.

В-третьих, поставьте точку останова в сервисе или вызывающем репозиторий и инспектируйте возвращённое значение.

Если маппинг остаётся необъяснённым, перейдите к сгенерированной реализации репозитория. Там разработчик может инспектировать, какой маппер результата вызывается и какие значения поставляются.

Если сам маппер сгенерирован или инжектирован, проследуйте за этим компонентом.

Ни в один момент разработчик не был вынужден начинать в сгенерированном исходнике. Сгенерированная реализация стала релевантной только тогда, когда абстракция репозитория больше не объясняла поведение.

Это паттерн, который включает Kora.

Практический пример: отладка отказоустойчивости¶

Представьте, что метод сервиса аннотирован таймаутом, повтором, circuit breaker и fallback, а производственные трассы показывают большую задержку, чем ожидалось.

Первый шаг не обязательно открывать сгенерированный код. Команда может начать с метрик, трассировки, логов, конфигурации и сфокусированного теста.

Если оставшийся вопрос — точная вложенность политик, тогда сгенерированная AOP-обёртка становится сильнейшим источником истины.

Разработчик может инспектировать метод и определить, повторно ли входит повтор в таймаут для каждой попытки, наблюдает ли circuit breaker отдельные сбои или финальный результат повтора и где fallback перехватывает получившееся исключение.

Это намного быстрее, чем спорить по памяти о порядке аннотаций.

Практический пример: отладка DI¶

Предположим, разработчик ожидает одну реализацию интерфейса, но компиляция сообщает о неоднозначности.

Сама ошибка может уже быть достаточной. Kora предотвратил превращение проблемы в загадку времени выполнения.

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

Опять же, сгенерированный код — вторичное свидетельство. Главное преимущество в том, что проблема была обнаружена до времени выполнения.

Это демонстрирует, почему полная история отладки должна включать валидацию этапа компиляции, а не только навигацию отладчика.

Практический пример: отладка HTTP-маппинга¶

Предположим, контроллер получает неожиданное значение параметра, хотя объявление маршрута выглядит корректным.

Точка останова в контроллере подтверждает неверное значение.

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

Если сгенерированный код соответствует ожиданиям, внимание может перейти к входящему запросу или реализации маппера. Если нет, граница локализуется немедленно.

Поэтому сгенерированный обработчик функционирует как точная граница между объявлением HTTP и выполнением контроллера.

Лучший словарь для сгенерированного кода¶

Фраза «сгенерированный код» охватывает слишком много разных вещей.

Она может означать непрозрачные внутренности компилятора.

Она может означать исходник, испущенный генератором схем.

Она может означать оптимизированные конечные автоматы.

Она может означать повторяющийся клей приложения.

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

У них очень разные свойства отладки.

Модель Kora лучше всего описывается как сгенерированная инфраструктура приложения в форме обычного исходника.

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

Это различие предотвращает непродуктивные споры, где вся генерация кода рассматривается как эквивалентная.

Модель Kora ближе к сгенерированному клею, чем к сгенерированному рантайму¶

Фраза «сгенерированный рантайм» тоже может вводить в заблуждение.

У Kora, конечно, есть библиотеки времени выполнения. HTTP-серверы, драйверы баз данных, Kafka-клиенты, gRPC-библиотеки, компоненты телеметрии и реализации отказоустойчивости существуют во время выполнения.

Но специфичная для приложения композиция этих частей генерируется как исходник, а не обнаруживается и собирается в первую очередь через рефлексию времени выполнения.

Поэтому сгенерированный слой ближе к клеевому коду:

ваши компоненты
   +
библиотеки фреймворка
   +
сгенерированный клей
   =
работающее приложение

Это важное различие, потому что клеевой код естественно инспектируем.

Инженер может видеть, как одна часть соединяется с другой.

Прозрачность масштабируется лучше, чем заученные правила фреймворка¶

По мере роста фреймворка разработчики неизбежно сталкиваются с фичами, которые используют редко.

Человек может очень хорошо знать HTTP-слой, но редко касаться планирования. Другой может знать репозитории баз данных, но не композицию отказоустойчивости. Третий может сопровождать Kafka-консьюмеров, но редко инспектировать AOP.

Если отладка зависит от запоминания внутренних правил каждой подсистемы, экспертизу становится трудно масштабировать на команду.

Инспектируемый сгенерированный исходник меняет это.

Разработчики могут реконструировать незнакомое поведение из текущих артефактов, а не полагаться целиком на память.

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

Это позволяет более широкой группе инженеров диагностировать взаимодействия фреймворка, не становясь экспертами в каждом модуле.

Прозрачность также помогает мейнтейнерам фреймворка¶

Сгенерированный исходник полезен не только разработчикам приложений.

Мейнтейнеры фреймворка могут использовать сгенерированный вывод, чтобы проверять, что процессоры испускают задуманную структуру. Регрессионные тесты могут сравнивать поведение. Отчёты об ошибках могут включать сгенерированные артефакты. Проблему можно воспроизвести, инспектируя то, что процессор произвёл для конкретного объявления.

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

Сгенерированный артефакт становится общим языком отладки.

Правильный компромисс — явность за сложность времени сборки¶

Kora платит за часть этой прозрачности во время компиляции.

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

Это реальный компромисс.

Но фреймворк получает взамен несколько вещей:

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

С точки зрения отладки это разумный обмен: больше работы происходит там, где компилятор и система сборки могут её валидировать, и меньше композиции фреймворка остаётся скрытой в состоянии времени выполнения.

Сгенерированный код не устраняет утечки абстракций¶

Ни один фреймворк не может полностью предотвратить утечки абстракций.

Абстракция базы данных в конце концов встречается с поведением базы данных. Абстракция HTTP в конце концов встречается с HTTP. Абстракция повтора в конце концов встречается со временем и сбоями. Абстракция DI в конце концов встречается с жизненным циклом объектов и структурой зависимостей.

Подход Kora — не притворяться, что эти утечки никогда не происходят. Он делает границу видимой, когда они происходят.

Это важно, потому что опытным инженерам не нужны идеальные абстракции. Им нужны абстракции, чьи режимы сбоев можно понять.

Сгенерированный исходник напрямую вносит вклад в это свойство.

Как выглядит хорошая отладка в Kora¶

Продуктивный рабочий процесс отладки в Kora поэтому большую часть времени обычен.

Начните с отказавшего поведения.

Воспроизведите его тестом, если возможно.

Инспектируйте написанный вручную код.

Используйте обычные точки останова.

Прочитайте ошибку компилятора, если проблема структурна.

Проверьте логи, метрики и трассы, если проблема операционная.

Пересекайте в сгенерированный исходник только тогда, когда нерешённый вопрос конкретно о том, что сгенерировал Kora или как компонуется поведение фреймворка.

В этот момент сгенерированный код даёт конкретный ответ.

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

Простая диагностическая иерархия¶

Общая стратегия может быть резюмирована компактно:

1. Написанный вручную исходник
       ↓
   Ошибка здесь?

2. Диагностика компилятора
       ↓
   Отклонил ли Kora структуру?

3. Тесты
       ↓
   Можно ли воспроизвести поведение?

4. Отладчик / трассы / логи
       ↓
   Что произошло во время выполнения?

5. Сгенерированный исходник
       ↓
   Что именно сгенерировал Kora?

6. Исходник фреймворка
       ↓
   Почему Kora генерирует это так?

Большинство ошибок останавливаются до последних двух стадий.

Именно так и должно быть.

Сгенерированный исходник существует, чтобы делать более глубокие стадии возможными, не делая их обязательными.

История отладчика лучше, когда у пути выполнения есть файл исходника¶

Одно из самых практических преимуществ генерации исходника — просто то, что релевантный путь выполнения можно связать с файлом исходника.

Если JVM выполняет сгенерированный AOP-подкласс, разработчик может открыть класс.

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

Если HTTP-обработчик участвует в пути запроса, разработчик может инспектировать обработчик.

Это звучит просто, но это мощно.

Опыт отладки становится последовательностью конкретных мест кода, а не попыткой реконструировать невидимые решения фреймворка.

В этом суть прозрачности.

Сгенерированный код особенно ценен для редких проблем¶

Рутинная разработка не оправдывает постоянного изучения внутренностей.

Редкие проблемы — оправдывают.

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

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

Вот почему аргумент не следует оценивать по тому, как часто разработчики открывают сгенерированные файлы. Низкая частота не означает низкую ценность.

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

Эпоха Нейро-технологии меняют стоимость глубокой инспекции¶

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

Сегодня агент может быстро прочитать этот класс, извлечь релевантный поток управления, сравнить его с объявлением и объяснить результат.

Это фактически снижает стоимость прозрачности.

Фреймворки, которые раскрывают поведение как исходник, выигрывают непропорционально, потому что машины могут потреблять этот исходник напрямую.

Скрытая модель времени выполнения заставляет агента выводить.

Модель сгенерированного исходника даёт агенту что-то читать.

Это всё более важное различие.

Инспектируемое поведение становится архитектурным активом¶

Более широкое следствие выходит за пределы отладки.

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

Поэтому подход сгенерированного исходника Kora не следует понимать только как оптимизацию производительности.

Это архитектурный выбор о том, где живут знания фреймворка.

Вместо хранения большой доли специфичного для приложения поведения фреймворка только в состоянии времени выполнения Kora материализует значительную его часть как исходник.

Это делает систему легче для анализа после того, как компилятор сделал свою работу.

Сильнейшее сравнение — не «codegen против no codegen»¶

Сильнейшее сравнение таково:

Инспектируемое представление этапа компиляции

против:

поведение времени выполнения, которое нужно реконструировать

Каждый фреймворк выполняет работу от имени разработчика.

Вопрос в том, оставляет ли эта работа после себя понятное представление.

Kora — оставляет.

Это ядро аргумента отладки.

Заключение¶

Сгенерированный код не автоматически делает отладку труднее.

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

Модель Kora спроектирована вокруг ровно этих свойств.

Разработчики по-прежнему отлаживают свой собственный контроллер, сервис и бизнес-логику как обычную Java или Kotlin. Step Over не протаскивает их через каждую сгенерированную реализацию. Они входят в сгенерированные классы только тогда, когда намеренно шагают в них, ставят там точку останова, переходят к реализации, инспектируют фрейм стека или задают более глубокий вопрос о границе фреймворка.

Большую часть времени обычный рабочий процесс остаётся:

исходник
  ↓
компилятор
  ↓
тесты
  ↓
отладчик

Сгенерированный исходник — необязательный следующий слой.

Когда этот слой нужен, он даёт нечто ценное: специфичную для приложения истину из первых рук. Сгенерированный граф зависимостей показывает реальное связывание. Сгенерированный репозиторий показывает реализацию, которая фактически выполняет запрос. Сгенерированный HTTP-обработчик показывает, как запрос достигает контроллера. Сгенерированный AOP-подкласс показывает точную композицию валидации, отказоустойчивости, транзакций, кеширования или другого сквозного поведения.

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

Компромисс не бесплатен. Сгенерированные классы могут добавлять фреймы стека, появляться в навигации и увеличивать вывод сборки. Но эти видимые артефакты следует сравнивать с машинной работой времени выполнения, которую они заменяют, а не с воображаемым фреймворком без какой-либо машинной работы.

Подход Kora — сделать эту машинную работу явной.

Результат не в том, что разработчики проводят дни в build/generated. Результат в том, что когда появляется трудный вопрос, им есть куда конкретно посмотреть.

И всё чаще даже эта инспекция не должна быть ручной. нейро-агент может читать сгенерированный исходник, прослеживать путь выполнения, идентифицировать выбранный маппер, объяснять порядок аспектов или показывать, как именно была связана зависимость. Важно то, что поведение существует в форме, которую можно инспектировать, а не угадывать.

Это приводит к самому полезному способу описать модель отладки Kora:

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

И более широкий вывод ещё сильнее:

Сгенерированный код — это не шум отладки по определению. В Kora это инспектируемая граница между декларативным кодом приложения и кодом JVM, который фактически выполняется.

Сгенерированный код делает отладку более прозрачной, а не труднее¶

Отладка не означает пошаговый проход по каждому методу¶

Исходный код приложения остаётся основной поверхностью разработки¶

Kora генерирует исходник, а не непрозрачную модель времени выполнения¶

Сгенерированный исходник — это запасной выход¶

Go to Implementation иногда должен показывать сгенерированный код¶

Инструменты IDE улучшают удобство, а не понятность¶

Сгенерированные репозитории превращают интерфейс в конкретную цель отладки¶

Сгенерированные HTTP-обработчики раскрывают реальный путь запроса¶

Сгенерированный AOP — один из сильнейших аргументов отладки¶

Валидация становится явным кодом¶

Сгенерированный код отказоустойчивости делает композицию политик видимой¶

Сгенерированный код ценен, потому что он читаем¶

Сгенерированный граф — это конкретизированное связывание приложения¶

Генерация на этапе компиляции устраняет целые категории отладки времени выполнения¶

Ошибки компилятора — часть истории отладки¶

Стек-трейсы могут быть более явными, не будучи более красивыми¶

Отладка границы фреймворка отличается от отладки бизнес-логики¶

Точки останова в сгенерированном коде иногда лучшие¶

Навигация в сгенерированный код может быть точнее, чем навигация в динамический прокси времени выполнения¶

Генерация исходника даёт ревьюерам второй взгляд¶

Сгенерированный код также улучшает анализ инцидентов¶

Сгенерированный код — лучшая истина из первых рук, чем память¶

Нейро-технологии делают сгенерированный исходник ценнее, чем раньше¶

Нейро-технологии могут следовать за точным приложением вместо угадывания фреймворка¶

Компилятор, отладчик, тесты и нейро-технологии образуют единый диагностический стек¶

Самую лёгкую ошибку отлаживать ту, которая никогда не достигает времени выполнения¶

У сгенерированного кода всё ещё есть стоимость¶

Сгенерированные классы не следует путать с владением вручную¶

Читаемая генерация усиливает абстракцию, а не ослабляет её¶

Прозрачность фреймворка важнее минимализма фреймворка¶

Сгенерированный код может улучшать введение в проект¶

Сгенерированный код помогает отделять ошибки фреймворка от ошибок приложения¶

Истина из первых рук важнее всего в трудных ошибках¶

Более точная модель отладки¶

Реальное сравнение — инспектируемый механизм против скрытого механизма¶

Прозрачность — это не то же самое, что простота¶

Сгенерированный исходник работает с существующим JVM-тулчейном¶

Почему это различие важно для более широкого дизайна Kora¶

Что сгенерированный код не решает¶

Сгенерированную обёртку часто легче объяснить, чем цепочку времени выполнения¶

Сгенерированная реализация может быть лучшей документацией, чем общая диаграмма¶

Нейро-технологии превращают специфичную для приложения документацию в разговор¶

Сгенерированный исходник снижает зависимость от племенных знаний¶

Явный лишний фрейм может быть лучше невидимого решения¶

Генерация кода переносит сложность раньше¶

Лучшая поверхность отладки — та, которую можно игнорировать, пока она не понадобится¶

Практический пример: отладка репозитория¶

Практический пример: отладка отказоустойчивости¶

Практический пример: отладка DI¶

Практический пример: отладка HTTP-маппинга¶

Лучший словарь для сгенерированного кода¶

Модель Kora ближе к сгенерированному клею, чем к сгенерированному рантайму¶

Прозрачность масштабируется лучше, чем заученные правила фреймворка¶

Прозрачность также помогает мейнтейнерам фреймворка¶

Правильный компромисс — явность за сложность времени сборки¶

Сгенерированный код не устраняет утечки абстракций¶

Как выглядит хорошая отладка в Kora¶

Простая диагностическая иерархия¶

История отладчика лучше, когда у пути выполнения есть файл исходника¶

Сгенерированный код особенно ценен для редких проблем¶

Эпоха Нейро-технологии меняют стоимость глубокой инспекции¶

Инспектируемое поведение становится архитектурным активом¶

Сильнейшее сравнение — не «codegen против no codegen»¶

Заключение¶