Code Is Debt
Код — это долг
«Что ты думаешь об ИИ-инструментах для программирования?»
Отвечаю примером двух компаний.
Они одинаковы по доходу и продукту, но первая живёт с 1 млн строк кода, вторая — с 100 тыс. Какая выгоднее?
Очевидно, та, что меньше. Меньше кода — быстрее понимать и менять. Код — это долг. ИИ, генерируя код, даёт тебе этот долг.
Брать ли его? Зависит. Долг бывает полезным или разрушительным, с процентами или без. Главное — иметь доступ к инструментам и использовать их ответственно.
Спасибо Ани Талахадзе за рецензию.
Комментарии (53)
- Участники спорят, можно ли считать количество строк кода (LOC) мерой технического долга: одни считают LOC бесполезной метрикой без учёта качества, другие — формой риска и обязательств.
- Подчёркивается, что «меньше кода» ≠ «лучше», если он нечитаем, плохо документирован и не поддерживается; главное — скорость понимания и изменения.
- AI-генерация кода ускоряет объём, но усиливает долг: код быстро появляется, но никто не понимает, кто за него отвечает, и как его отлаживать.
- Код описывается как актив, который амортизируется: чем больше кода, тем выше ежегодные «выплаты» на его поддержку и рефакторинг.
- Третьи сервисы и зависимости тоже создают долг: при смене условий или закрытии поставщика страдает бизнес.
Delete tests
Удаляйте тесты
Тесты нужны для уверенности: «не сломал ли я старое?». Но если тесты сами подрывают эту уверенность — их надо выбрасывать.
- Флаки (падают случайно) учат игнорировать красный CI и скрывать реальные баги. Удаляйте.
- Слишком хрупкие (150 правок ради одной строки) замедляют разработку. Оставьте пару ключевых, остальные — в мусор.
- Долгие (не успевают прогнаться между мержами) превращаются в «всегда зелёные», но не запускаются. Это ложная уверенность — удаляйте.
- Устаревшие (проверяют поведение, которое больше не нужно) мешают внедрять новые требования. Удаляйте и пишите новые.
Если тест не приносит уверенности прямо сейчас, он вредит. Удаляйте без страха: при настоящем баге напишете лучший.
Комментарии (88)
- Участники спорят, стоит ли удалять «шаткие» (flaky) или медленные тесты, или их нужно чинить.
- Большинство считает, что лучше чинить: хрупкие тесты часто указывают на проблемы в архитектуре или race condition.
- Некоторые предлагают компромисс: временно игнорировать или выносить в отдельный набор, но не удалять окончательно.
- Автор статьи призывает удалять тесты, если они не приносят ценности, но критики считают это «кликбейтом» и предлагают просто улучшать тесты.
- Общий вывод: тесты — это код, который тоже может стать техническим долгом; решать нужно не «удалять vs оставлять», а «как сделать полезные тесты быстрыми и стабильными».