Разработчики любят говорить о “счастливом пути” — идеальном сценарии работы программы, когда всё идёт по плану. Но в реальном мире этот путь похож на гладкий асфальт среди ухабистой дороги: большую часть кода и времени мы тратим не на него, а на обработку ошибок, исключений и неожиданных состояний.
Автор блога Third Bit поднимает интересный вопрос: а сколько именно уходит на это сил? Ответ оказался неожиданным — современных исследований практически нет.
Что мы знаем
📖 Единственная цифра — из книги Software Fault Tolerance (1995, Flaviu Cristian). Там утверждается, что более двух третей кода в продакшн-системах связано с обработкой отказов.
🧑💻 Недавние исследования повседневной жизни разработчиков дают фрагменты картины:
- 🐞 ~11 % времени уходит на отладку и багфиксы (иногда до 32 % в отдельные дни).
- 📅 4–6 % времени занимают встречи.
- 🧪 до 16 % уходит на тестирование.
Но нигде напрямую не измеряется, сколько кода и времени реально отводится на обработку ошибок (error handling).
Почему это важно
В распределённых системах (микросервисы, облака, брокеры сообщений) вероятность сбоев растёт экспоненциально. Ошибки сети, таймауты, падения зависимостей — всё это требует не только логирования, но и механизма восстановления.
⚙️ Типичный «боевой» сервис включает:
- 🔄 ретраи с экспоненциальной задержкой,
- 🛡️ circuit breakers (ограничение запросов к падающему сервису),
- 💾 fallback-логика, кеширование и graceful degradation,
- 📊 мониторинг и алертинг (Prometheus, Zabbix, Sentry).
И на практике именно эти куски кода занимают огромную часть времени разработки и ревью.
Моё видение
Я согласен с автором статьи: удивительно, что мы до сих пор не имеем точных метрик по «стоимости» отказоустойчивости. Мы легко меряем скорость LLM по BLEU score, но не знаем, сколько строк из миллиона в реальном коде посвящены обработке ошибок.
Для индустрии это критично:
- 💸 компании хотят оптимизировать расходы, а значит — понимать, сколько стоит “страховка” от сбоев;
- 🧑🎓 образовательные программы по программированию недооценивают важность обработки ошибок, хотя в реальной работе это может быть половина задач;
- 🧪 новые инструменты (например, автоматизированные “self-healing” решения или fault-injection тесты) нужно оценивать не по маркетингу, а по конкретной экономии времени и кода.
Мне кажется, было бы полезно провести крупное исследование на GitHub-репозиториях: выделить конструкции try/catch, обработку таймаутов, проверки ошибок и посчитать их долю. Это несложно сделать автоматизированно, а результат дал бы реальное понимание масштаба проблемы.
Вывод
Парадоксально, но в 2025 году, когда мы обсуждаем генеративный ИИ и “программирование будущего”, мы всё ещё не знаем точно, сколько усилий уходит на то, чтобы код не ломался. Возможно, это и есть главная зона, остающаяся вне внимания (blind spot) нашей индустрии: мы привыкли мерить успех по “фичам”, а не по “страховке” от ошибок.
🔗 Источник:
— Third Bit: Time Spent on Hardening