Regenerative Software — Чад Фаулер (Рубрика #Books)

Книга ещё не дописана, а рекомендовать её уже хочется. "Regenerative Software" Чада Фаулера выходит у O’Reilly в Early Release, и текущие главы, на мой взгляд, очень хорошо объясняют, куда движется разработка софта и почему. Финальный релиз издательство пока планирует на апрель 2027 года, но предмет для разговора уже есть.

Фаулер начинает с экономики. Десятилетиями работающий код было дорого создавать, поэтому вокруг его сохранения выросла вся культура разработки. При этом в коде оседало знание о системе: странные исключения, последствия инцидентов, особенности клиентов. Когда всё это существует только внутри реализации, переписывание превращается в археологическую работу. Новую версию написать можно. Вспомнить всё, что было зашито в старой версии, гораздо сложнее (и никто это без острой нужды не делал). Кстати, эти размышления напоминают те, что были в whitepaper "What Happens When Technical Debt Vanishes?", что я уже разбирал.

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

Отсюда и regenerative software: систему проектируют так, чтобы её части можно было заново создавать, сохраняя накопленное знание. Реализация может смениться, а контракты, ограничения, проверки и причины решений должны пережить эту смену. У Фаулера есть хорошая аналогия с инфраструктурой: мы уже ушли от pets к catlle и научились пересоздавать сервера из yaml файлов. Теперь он предлагает продумать, что потребуется для такой же заменяемости самого софта (видимо много md файлов).

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

Особенно показательна глава про evaluations. Фаулер рассказывает, как участвовал в переписывании системы для школ: современная архитектура, TDD, стопроцентное покрытие unit-тестами. Пользователи новую систему не приняли, и её пришлось откатить. Нужное им поведение жило в привычках и неявных правилах работы, которые команда не перенесла в требования. Все тесты были зелёными. Проверяли просто не всё, что имело значение.

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

Ещё один важный слой — provenance или история происхождения решений. Почему здесь ограничено число повторных попыток? Почему валидация продублирована? Какие варианты уже пробовали и отвергли? Для следующего инженера или агента эти причины должны быть доступны вместе с подтверждающими данными. Иначе очередное «упрощение» легко удалит защиту от старой аварии.

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

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

#Books #AI4SDLC #Architecture #Engineering #Software