Hacker News Digest

Тег: #code-quality

Постов: 2

Code Is Debt (tornikeo.com)

Код — это долг

«Что ты думаешь об ИИ-инструментах для программирования?»
Отвечаю примером двух компаний.

Они одинаковы по доходу и продукту, но первая живёт с 1 млн строк кода, вторая — с 100 тыс. Какая выгоднее?
Очевидно, та, что меньше. Меньше кода — быстрее понимать и менять. Код — это долг. ИИ, генерируя код, даёт тебе этот долг.

Брать ли его? Зависит. Долг бывает полезным или разрушительным, с процентами или без. Главное — иметь доступ к инструментам и использовать их ответственно.

Спасибо Ани Талахадзе за рецензию.

by tornikeo • 31 августа 2025 г. в 17:58 • 84 points

ОригиналHN

#technical-debt#code-quality#software-maintenance#ai-tools#programming#code-generation

Комментарии (53)

  • Участники спорят, можно ли считать количество строк кода (LOC) мерой технического долга: одни считают LOC бесполезной метрикой без учёта качества, другие — формой риска и обязательств.
  • Подчёркивается, что «меньше кода» ≠ «лучше», если он нечитаем, плохо документирован и не поддерживается; главное — скорость понимания и изменения.
  • AI-генерация кода ускоряет объём, но усиливает долг: код быстро появляется, но никто не понимает, кто за него отвечает, и как его отлаживать.
  • Код описывается как актив, который амортизируется: чем больше кода, тем выше ежегодные «выплаты» на его поддержку и рефакторинг.
  • Третьи сервисы и зависимости тоже создают долг: при смене условий или закрытии поставщика страдает бизнес.

Delete tests (andre.arko.net)

Удаляйте тесты
Тесты нужны для уверенности: «не сломал ли я старое?». Но если тесты сами подрывают эту уверенность — их надо выбрасывать.

  • Флаки (падают случайно) учат игнорировать красный CI и скрывать реальные баги. Удаляйте.
  • Слишком хрупкие (150 правок ради одной строки) замедляют разработку. Оставьте пару ключевых, остальные — в мусор.
  • Долгие (не успевают прогнаться между мержами) превращаются в «всегда зелёные», но не запускаются. Это ложная уверенность — удаляйте.
  • Устаревшие (проверяют поведение, которое больше не нужно) мешают внедрять новые требования. Удаляйте и пишите новые.

Если тест не приносит уверенности прямо сейчас, он вредит. Удаляйте без страха: при настоящем баге напишете лучший.

by mooreds • 27 августа 2025 г. в 11:18 • 98 points

ОригиналHN

#testing#continuous-integration#code-quality#technical-debt

Комментарии (88)

  • Участники спорят, стоит ли удалять «шаткие» (flaky) или медленные тесты, или их нужно чинить.
  • Большинство считает, что лучше чинить: хрупкие тесты часто указывают на проблемы в архитектуре или race condition.
  • Некоторые предлагают компромисс: временно игнорировать или выносить в отдельный набор, но не удалять окончательно.
  • Автор статьи призывает удалять тесты, если они не приносят ценности, но критики считают это «кликбейтом» и предлагают просто улучшать тесты.
  • Общий вывод: тесты — это код, который тоже может стать техническим долгом; решать нужно не «удалять vs оставлять», а «как сделать полезные тесты быстрыми и стабильными».