Инженер-программист рассказывает о том, почему накопленные «кодовые упрощения» становятся серьезной угрозой для приложений в сфере здравоохранения и финансов, и как их устранить, не нарушая работу производственной среды.
61 миллиард рабочих дней технического долга — эта цифра приведена в отчете компании CAST, специализирующейся на аналитике программного обеспечения, который был опубликован после анализа более 10 миллиардов строк кода в 47 000 приложений в 17 странах. Даже если бы все разработчики на планете не занимались ничем другим, на устранение этого долга ушло бы почти десять лет. В этом отставании находятся диагностические системы больниц и торговые платформы — программное обеспечение, в котором один-единственный нерешенный «упрощенный путь» может нанести вред пациентам или вызвать финансовые потери.
Сергей Кузнецов более десяти лет работает с кодовыми базами, в которых накопленные «упрощения» влекут за собой реальные последствия — от медицинских приложений до институциональных торговых систем. В компании Imito AG он обеспечил стабильную работу клинического приложения, используемого для диагностики ран; в STO Solutions он переработал архитектуру, отвечающую за производительность медицинской системы NLP, которая обрабатывает миллионы диагностических записей. Сегодня Сергей возглавляет инженерную команду в международной компании поставщике ИТ-решений. Мы поговорили с Сергеем Кузнецовым о том, почему так сложно погасить «долг» в системах, чувствительных к безопасности, и в чем отрасль продолжает ошибаться.
Сергей, многие команды откладывают решение проблемы технического долга на самый конец списка задач спринта. В какой момент такой подход становится откровенно опасным?
Когда пользователи вашего программного обеспечения сталкиваются с последствиями, выходящими за рамки простого неудобства. Я видел это на собственном опыте в Imito AG, где приложение imitoWound не работало прямо у постели пациентов. Медсестры и врачи полагались на него при оценке состояния ран в режиме реального времени. В коде накопились годы «упрощений», и дефекты уже не просто замедляли выпуск обновлений — они ставили под угрозу точность клинических измерений. Я потратил восемь месяцев на рефакторинг компонентов пользовательского интерфейса и устранение значительной части задержек, что привело к заметному повышению скорости отклика приложения. Финансовые платформы несут на себе такую же ответственность: если данные, которые предоставляет ваша система, даже слегка устарели в часы работы рынка, цена этого — не заявка в службу поддержки, а денежные потери. Долг перестает быть просто пунктом списка задач и становится риском, как только реальные решения зависят от вашего кода.
Вы модернизировали в STO Solutions архитектуру медицинской системы на основе обработки естественного языка (NLP), базовая библиотека которой содержала 3,5 миллиона записей. Что пошло не так в первоначальном дизайне?
Никто не планировал 3,5 миллиона записей — именно так и возникает технический долг. Система помогала врачам назначать диагностические коды с помощью обработки естественного языка, а объем базового набора записей вырос далеко за пределы того, с чем могла эффективно справляться исходная логика загрузки. Врачи слишком долго ждали, пока инструмент станет пригодным к использованию после запуска. Я переработал способ, которым приложение загружало и кэшировало эти данные, и в результате скорость работы увеличилась на 65 процентов. Что меня поразило, так это то, что исходная архитектура была вполне адекватной в меньших масштабах. Долг не всегда возникает из-за плохих решений, иногда он возникает из-за хороших решений, из которых продукт просто вырастает.
В Feedme AB вы с нуля создали платформу для заказа еды с командой из трех человек: выбрали стек, интегрировали Klarna и Stripe, выпустили первую версию. Когда вы начинаете с чистого листа, откуда появляется долг?
Быстрее, чем вы думаете. На ранних этапах разработки продукта любой упрощённый подход кажется оправданным, ведь вы мчитесь к запуску. Нам нужно было быстро наладить обработку платежей, поэтому некоторые абстракции были пропущены. Календарь заказов должен был заработать для первого клиента, поэтому решение по крайним случаям в повторяющихся расписаниях было отложено. Каждый из этих выборов был рациональным в тот момент. Но как только продукт вошел в повседневное использование и начали поступать новые требования, эти отложенные решения превратились в препятствия. Создание продукта с нуля научило меня чему-то, что я применяю к каждому унаследованному коду: долг, который вы создаете намеренно в первый месяц, можно управлять, но только если вы записываете его и планируете время для его пересмотра. Большинство команд пропускают этот второй шаг.
Вы работали в сферах медицинских, финансовых, образовательных и пищевых технологий. Помогает ли смена отраслей обострить ваш инстинкт в отношении долга, или постоянная смена контекста становится помехой?
Это заостряет внимание, ведь в каждой сфере наказываются разные виды халатности. Медицина научила меня, что дефект это не просто проблема удобства использования, он может повлиять на исход лечения. Финансы научили меня, что медленная реакция это не просто раздражает, это бизнес-событие, которое обходится дорого. Доставка еды научила меня, что сжатые сроки запуска порождают долг, с которым придется жить годами, если не запланировать его погашение. Пройдя достаточное количество таких циклов, перестаешь думать в терминах функций и начинаешь думать о том, что может пойти не так и как быстро можно восстановить ситуацию. Такой подход полезен независимо от того, что делает продукт.
Помощники по кодированию на базе ИИ обещают ускорить именно тот вид повторяющегося рефакторинга, который связан с устранением долга. Насколько вы доверяете им на платформе, которая обрабатывает конфиденциальные финансовые данные?
Я интегрировал как GitHub Copilot, так и Claude Code в рабочий процесс нашей команды. Они позволяют реально сэкономить время при создании каркаса кода, шаблонов и генерации тестов. Copilot отлично справляется с заполнением повторяющихся шаблонов; Claude Code же более полезен, когда нужно проанализировать компромиссы в проектировании или изучить крайние случаи. Однако любой результат, затрагивающий бизнес-логику или обрабатывающий данные, подпадающие под регулирование, проходит такую же тщательную проверку, как и код, написанный коллегой. Здесь мне помогает мой опыт работы с разными языковыми стеками: я могу определить, когда предложение является синтаксически верным, но архитектурно неправильным, независимо от того, на каком языке пишет команда. Инженеры, которые терпят неудачу, — это те, кто рассматривает уверенность, с которой инструмент предлагает решения, как замену собственному суждению.
Если посмотреть на отрасль в целом, в чем заключается самый большой пробел в навыках, из-за которого технический долг выходит из-под контроля?
Переход от сильного индивидуального специалиста к человеку, способному координировать работу по устранению долга во всей команде. Опытный разработчик может очистить модуль или выявить сложный дефект, но определение приоритетов долга, обеспечение стабильности действующей системы во время очистки и согласование действий всех членов команды это задачи лидерства, а не программирования. Я разрабатываю курс для разработчиков, который направлен именно на устранение этого пробела, потому что, по моему опыту, именно в этом заключается источник наиболее предотвратимого ущерба в инженерных организациях.
