Логгер в 2023: TDD с ChatGPT 3.5
Стоит упомянуть, что к тому времени, когда Vibe Coding успел набрать популярность, у меня уже был небольшой опыт программирования с использованием LLM и, что довольно необычно, — сразу в коммерческой разработке.
Еще в 2023 году на одном из проектов компании нам понадобилось разработать небольшой логгер для клиентского приложения. Тогда не хотелось возиться с подключением тяжелых инструментов вроде Sentry, поэтому было решено разработать свой собственный с помощью недавно вышедшего, но уже нашумевшего ChatGPT 3.5. Разумеется, это подразумевало копирование и вставку кода из чата в IDE, поскольку других вариантов тогда ещё не было. Но и без того всё происходящее уже воспринималось как безусловный прорыв.
Притом, что задача сама по себе была несложной, основную нагрузку по проверке её реализации интересно было с ревью кода переложить на автотесты. И это себя оправдало: на пару с моделью проверку получилось осуществить в режиме TDD — в классическом цикле Red-Green-Refactor. В результате ручной проверки кода, сгенерированного LLM, почти не потребовалось, а запусков тестов, напротив, было довольно много. В итоге все прошло хорошо: логгер был реализован и успешно развернут на проде.
Один из ключевых контрактов выглядел примерно так:
test('error: уровень, сообщение и контекст уходят в sink', () => {
const sent: LogRecord[] = [];
const log = createLogger((rec) => sent.push(rec));
log.error('connection failed', { userId: 42 });
expect(sent).toEqual([
{ level: 'error', message: 'connection failed', context: { userId: 42 } },
]);
});Живая спецификация
Здесь стоит отметить, что хорошие тесты — контрактные тесты, то есть те, которые создаются для проверки не всей кодовой базы, а только её ключевой части — контрактов, реализуемых программой. Притом, что контракт может быть задокументирован, он также может быть зафиксирован и в контрактных тестах, которые в этом случае сами становятся уже не просто тестами, а живой спецификацией.
Таким образом, когда все тесты в TDD основаны на контрактах, разработка становится не просто Test-Driven, а, в определённом смысле уже и Specification-First Development. А если при этом используются ещё и инструменты искусственного интеллекта, то в результате получается именно то, что сегодня известно как Spec-Driven Development.
Именно так был разработан вышеупомянутый мини-логгер, и именно в процессе этой разработки впервые стало понятно, что заранее определенные спецификации можно использовать для того, чтобы, во-первых, избегать ошибок программирования, совершаемых LLM, а, во-вторых, контролировать их (LLM) поведение.