Инженеры-программисты тратят большую часть своей карьеры не на написание нового кода, а на поддержку чужого. Этот факт всегда был верен — и по состоянию на 2026 год он стал более значимым, чем когда-либо в истории индустрии. Инструменты кодирования на основе искусственного интеллекта (ИИ) теперь генерируют примерно 41 процент всего нового коммерческого кода, согласно нескольким аналитическим отчетам за 2026 год, однако опрос Stack Overflow Developer Survey показал, что только три процента разработчиков «полностью доверяют» результатам, сгенерированным ИИ. Разрыв между генерацией кода и его пониманием породил новую категорию технического долга, которую исследователи называют «долгом понимания» (comprehension debt) — код, написанный быстрее, чем любая команда может его проверить, понять или безопасно изменить.
15 июня 2026 года Дэйв Андерсон — бывший технический директор и генеральный менеджер Amazon, который ведет рассылку Scarlet Ink о технологическом лидерстве — опубликовал ретроспективу, включающую его наиболее цитируемые идеи за годы писательской деятельности. Среди выделенных им материалов были его Десять заповедей поддержки устаревшего кода, впервые опубликованные 18 мая 2026 года. Две из этих заповедей вошли в число его личных лучших: принцип, согласно которому устаревший код является признаком успеха, а не неудачи, и наблюдение о том, что фраза «только на этот раз» по сути является шуткой в разработке программного обеспечения. Учитывая текущую траекторию индустрии, оба этих вывода несут больший операционный вес, чем когда-либо в истории разработки ПО.
Устаревший код — это не то, что вы думаете
Прежде чем применять какую-либо заповедь, Андерсон просит инженеров переосмыслить, как они относятся к унаследованным кодовым базам. Устаревший код (legacy code) в общепринятом пренебрежительном смысле означает запутанный, старый и плохо написанный. Первая заповедь Андерсона исправляет это предположение на фундаментальном уровне.
Код, который становится «устаревшим», — это код, который выжил. Продукты терпят неудачу, и их код исчезает. Только когда продукт добивается успеха — когда он обслуживает достаточно пользователей, обрабатывает достаточно транзакций, приносит достаточно ценности — лежащий в его основе код остается достаточно долго, чтобы накопить этот ярлык. Система, на которую инженер жалуется в понедельник утром, — это система, которая поддерживала работу компании во время ее роста.
Майкл Физерс, чья книга 2004 года Working Effectively with Legacy Code остается основополагающим текстом в этой области, дал точное определение устаревшего кода как «кода без тестов» — не старого и не уродливого кода, а кода, которого разработчики боятся изменять. Первая заповедь Андерсона затрагивает культурную половину этой проблемы: команда, которая предполагает некомпетентность или лень своих предшественников, уже подорвала свою способность понять то, что эти предшественники на самом деле построили.
Десять заповедей с пояснениями
Андерсон излагает десять принципов. Каждый из них направлен на конкретный сбой, который превращает поддерживаемые системы в неподдерживаемые.
Заповедь I — Не критикуйте код или тех, кто его написал. Инженеры, работавшие до вас, действовали в условиях ограничений — недофинансирования, сжатых сроков, неполных спецификаций, — которые не видны в истории коммитов. Предположение о недобросовестности оскорбляет бывших коллег и, что более практично, заставляет инженеров неверно истолковывать намерения, стоящие за решениями, которые могли быть правильными на момент их принятия.
Заповедь II — Не позволяйте сжатым срокам ставить под угрозу вашу систему. Фраза «только на этот раз» — это самое дорогое предложение в разработке программного обеспечения. Андерсон непреклонен: давление сроков никогда не является достаточным оправданием для того, чтобы сделать систему менее удобной для сопровождения. Один процент подлинных чрезвычайных ситуаций — тех, которые могут поставить компанию под юридический риск, — требуют немедленного исправления, запланированного на следующий спринт, без права переноса.
Заповедь III — Не добавляйте «бесхозные» функции. Функции, которые ни с чем не связаны, не служат активному варианту использования или не имеют владельца, становятся невидимыми обязательствами. Они потребляют когнитивную нагрузку у каждого будущего разработчика, читающего код, не принося при этом никакой соответствующей ценности. Андерсон называет это раздуванием (bloat) — а раздувание является накоплением индивидуально небольших решений, которые в совокупности приводят к структурным проблемам.
Заповедь IV — Не переписывайте систему, пока не исчерпаны все остальные варианты.Исследования показывают, что от 60 до 80 процентов переписываний программного обеспечения либо не приносят обещанных преимуществ, либо отменяются; те, которые увенчиваются успехом, как правило, занимают в два-четыре раза больше времени и стоят в два-четыре раза дороже, чем планировалось. Привлекательность переписывания понятна — новые системы захватывают, — но существующий код, каким бы запутанным он ни был, содержит годы исправлений ошибок, пограничных случаев и бизнес-логики, которые системе, созданной с нуля, придется заново открывать в продакшене.
Заповедь V — Не бойтесь создавать новые системы. Эта заповедь существует в намеренном напряжении с четвертой. Чрезмерный инстинкт сохранения может бесконечно запереть команды внутри неподдерживаемых кодовых баз. Бывают моменты, когда новое — это действительно правильный выбор. Вклад Андерсона заключается в создании структуры для принятия решений: сначала исчерпайте альтернативы, распознайте подлинные моменты, когда вы не можете этого сделать, и не позволяйте страху перед антипаттерном переписывания помешать необходимым действиям.
Заповедь VI — Изучите систему, прежде чем ее изменять. Новые члены команды, которые вносят изменения в код, не поняв его поведения, не просто рискуют регрессиями — они уничтожают институциональные знания, заложенные в этом коде, быстрее, чем любая документация могла бы их сохранить. Правило Андерсона простое: время, вложенное в понимание, всегда окупается с процентами. Техническим механизмом, лежащим в основе этой заповеди, является характеризационное тестирование (characterization testing) — техника, которую Физерс определил как написание тестов не для указания желаемого поведения, а для документирования фактического поведения — способ сделать реальную логику системы читаемой до ее изменения.
Заповедь VII — Чините окна, а не разбивайте их.Теория разбитых окон, представленная социальными учеными Джеймсом Уилсоном и Джорджем Келлингом в 1982 году и примененная к программному обеспечению в книге The Pragmatic Programmer в 1999 году, гласит, что видимые признаки беспорядка привлекают дальнейший беспорядок. На практике: оставляйте каждую часть кода, к которой вы прикасаетесь, в лучшем состоянии, чем нашли. Добавляйте тесты. Переименовывайте вводящие в заблуждение переменные. Рефакторите запутанную логику. Андерсон идет дальше: каждая оценка времени должна включать необсуждаемое, не подлежащее обсуждению время для инкрементального улучшения. Прогресс не требует спринта по наведению порядка — он происходит по одному коммиту за раз.
Заповедь VIII — Не пренебрегайте каркасом вашей системы. Рефакторинг кода при оставлении конвейеров сборки, процессов развертывания и инфраструктуры тестирования в неисправном состоянии — это перестановка мебели в структурно небезопасном здании. Определение рефакторинга Андерсона намеренно широкое: оно охватывает всю систему, а не только ее исходный код.
Заповедь IX — Используйте тесты для более безопасного и легкого рефакторинга. Характеризационные тесты — термин из книги Физерса 2004 года — это тесты, написанные не для указания желаемого поведения, а для документирования фактического поведения, которое система демонстрирует в настоящее время. Они формируют страховочную сетку, которая позволяет изменять код, который вы не понимаете полностью, без возникновения неизвестных регрессий. В плохо документированной кодовой базе полный набор тестов часто является самой точной доступной спецификацией.
Заповедь X — Создавайте минимум для получения ценности. Чрезмерное проектирование (over-engineering) часто является первопричиной непригодности к сопровождению, в которой позже обвиняют инженеров, унаследовавших код. Системы, разработанные для обработки каждого мыслимого будущего варианта использования, для масштабирования в десять раз по сравнению с фактическим спросом, для бесконечной расширяемости — эти системы становятся кошмарами устаревшего кода следующего десятилетия. Наименьшее количество кода, которое работает, почти всегда является самым простым в сопровождении кодом.
Почему эти правила сейчас более актуальны, чем когда-либо
Андерсон написал эти заповеди как вечный совет. Текущий момент индустрии придает им более острый оттенок.
Инструменты кодирования на базе ИИ теперь пишут примерно 41 процент нового коммерческого кода. Пять независимых исследовательских групп в начале 2026 года сошлись на одном выводе: инструменты ИИ генерируют код в пять-семь раз быстрее, чем разработчики могут его понять. Возникающий в результате «долг понимания» не отражается в дашбордах скорости, обзорах спринтов или метриках DORA. Он проявляется через шесть-восемнадцать месяцев, когда никто в команде не может уверенно изменять, отлаживать или владеть этим кодом.
Одна компания из списка Fortune 50 задокументировала десятикратное увеличение ежемесячных обнаружений уязвимостей в безопасности — с 1000 до более чем 10 000 — между декабрем 2024 года и июнем 2025 года. Анализ GitClear, охвативший 153 миллиона строк кода, показал, что «перетряхивание» кода (code churn) — скорость, с которой недавно написанные строки отменяются или переписываются, — увеличилось на 39 процентов в проектах, которые активно использовали инструменты кодирования на базе ИИ. Gartner прогнозирует, что подходы к разработке «от промпта к приложению» увеличат дефекты программного обеспечения на 2500 процентов к 2028 году, если текущая практика сохранится.
Ирония, которую выявляет структура Андерсона, точна: заповеди, которые кажутся оборонительной осторожностью — учись, прежде чем менять, создавай минимум, добавляй тесты, улучшай инкрементально, — это именно те практики, которые определяют, какую ценность инженерная команда может извлечь из инструментов ИИ. Чистая, хорошо понятная, хорошо протестированная кодовая база усиливает помощь ИИ. Запутанная — поглощает ее. Команды, добивающиеся успеха в 2026 году, не генерируют больше всего кода. Они поддерживают дисциплину, чтобы просматривать, понимать и управлять тем, что они генерируют.
В чем разница между устаревшим кодом и техническим долгом?
Эти термины часто путают, но они описывают разные проблемы. Технический долг, введенный Уордом Каннингемом в 1992 году, относится конкретно к подразумеваемой будущей стоимости решений, принятых ради краткосрочной скорости. Устаревший код — это более широкая категория: он включает код с высоким техническим долгом, но также включает код, который чист, хорошо протестирован и просто стар. Опасное пересечение — это устаревший код с высоким долгом — унаследованные системы, построенные под давлением, никогда не подвергавшиеся рефакторингу и теперь налагающие значительные накладные расходы на сопровождение при каждом изменении.
Заповеди Андерсона затрагивают обе категории. Первые пять регулируют устаревший код: как его наследовать, когда сохранять и когда заменять. Последние пять регулируют предотвращение технического долга: как инкрементально поддерживать чистоту систем, как использовать тесты как механизм безопасного изменения и как противостоять чрезмерному проектированию, которое усложняет будущее сопровождение.
Часто задаваемые вопросы
Следует ли рефакторить или переписывать устаревший код?
Почти во всех случаях сначала исчерпайте варианты рефакторинга. Заповедь IV Андерсона четко излагает правило: переписывать только после того, как все альтернативы были рассмотрены и отклонены. Данные индустрии подтверждают эту осторожность: большинство переписываний не приносят обещанных преимуществ или отменяются до завершения, а те, которые успешны, занимают значительно больше времени, чем предполагалось. Переписывание отбрасывает годы встроенных исправлений ошибок и бизнес-логики, которые новой системе придется заново открывать в продакшене. Инкрементальный рефакторинг, поддерживаемый характеризационными тестами, почти всегда безопаснее и дешевле.
Почему устаревший код так трудно поддерживать?
Определение Майкла Физерса указывает на основную проблему: устаревший код — это код, которого разработчики боятся изменять. Этот страх имеет техническую причину — недостаточные тесты делают изменения рискованными — и культурную причину: контекст, стоящий за проектными решениями, не задокументирован или больше не присутствует в команде. Андерсон добавляет третий фактор: инженеры, которые отвергают предыдущую работу как некомпетентную, а не ограниченную, теряют доступ к обоснованию, объясняющему, почему система именно такова, какая она есть.
Как код, сгенерированный ИИ, создает новые проблемы устаревшего кода?
Инструменты ИИ генерируют код быстрее, чем разработчики могут его понять. В отличие от традиционного технического долга, который возникает сознательно — компромисс, принятый для соблюдения сроков, — долг понимания, сгенерированный ИИ, часто невидим во время создания. Проверки кода выглядят чистыми; тесты проходят; функция выпускается. Долг проявляется позже, когда разработчику нужно изменить код и он обнаруживает, что никто, включая первоначального автора, не понял до конца, что было сгенерировано. Заповеди Андерсона, в частности Заповедь VI (учись, прежде чем менять) и Заповедь IX (используй тесты для безопасного рефакторинга), являются основными мерами смягчения.
Чем отличается структура Дэйва Андерсона от общих советов по рефакторингу?
Заповеди Андерсона основаны на организационной и культурной динамике инженерных команд, а не только на гигиене кода. Заповедь I касается культуры обвинений. Заповедь II касается давления сроков. Заповедь III касается раздувания функций. Заповедь V признает, когда переписывание уместно, а не только когда оно неуместно. В результате получается структура, которую старший инженер может использовать, чтобы противостоять организационному давлению с помощью принципиальных аргументов, а не только эстетических предпочтений.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Adrian Parham
