Макс Канат-Александер: нужно ли качество кода, который можно заменить? (Рубрика #AI4SDLC)

У Max Kanat-Alexander из Capital One вышел доклад «Does Code Quality Still Matter?», который хорошо продолжает тему моего keynote на DotNext: что происходит с инженерией, когда реализацию становится проще сгенерировать заново, чем поддерживать годами?

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

Дальше он предлагает шкалу от disposable до durable software. На одном конце — программа для организации одной вечеринки. На другом — система, от которой годами зависят люди и бизнес. Положение на шкале определяют четыре вещи: последствия отказа, стоимость замены, зависимости и стоимость сопровождения. Для первого случая, считает Макс, качество кода может не иметь значения. Для второго инженерная дисциплина остаётся необходимой.

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

И вот здесь я бы отдельно развёл срок жизни системы и срок жизни её реализации.

На DotNext я развивал идеи Чада Фаулера из книги "Regenerative Software". Система может жить десятилетиями, а код отдельных компонентов — регулярно заменяться. Для этого накопленное знание должно переживать очередную генерацию:

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

Это для меня и есть важная часть regenerative software development. Мы заранее создаём условия, при которых реализацию можно выбросить, сохранив поведение и понимание системы. Одна папка с Markdown сама по себе такой способности не даёт :)

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

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

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

#AI4SDLC #Engineering #Architecture #Software #AI #Conference