Всем привет, меня зовут Евгений Вербов, я технический директор IT-компании «Нильсен». В этой статье я хочу подробнее рассмотреть одну из актуальных проблем при разработке — технический долг, с которым столкнулась в том числе и наша компания. А еще расскажу о том, как преодоление технического долга помогло нам сразу в семь раз увеличить производительность системы.
Что такое технический долг?
Технический долг — это метафора, которая описывает ситуацию, когда команда разработчиков принимает решение не писать код с нуля, а использовать уже существующий код, даже если он не идеален. Это может быть связано с нехваткой времени, ресурсов или просто потому, что код уже работает. Однако такой подход может привести к проблемам в будущем.
Представьте, что вы строите дом, но вместо того, чтобы строить его с нуля, вы используете старый фундамент. Конечно, это может сэкономить время и деньги, но в итоге вы можете столкнуться с проблемами, такими как трещины в стенах, протечки крыши и т.д. То же самое происходит и в разработке программного обеспечения. При использовании старого кода ошибки, сбои и другие проблемы — почти стандартная ситуация.
Представьте, что вы строите дом, но вместо того, чтобы строить его с нуля, вы используете старый фундамент. Конечно, это может сэкономить время и деньги, но в итоге вы можете столкнуться с проблемами, такими как трещины в стенах, протечки крыши и т.д. То же самое происходит и в разработке программного обеспечения. При использовании старого кода ошибки, сбои и другие проблемы — почти стандартная ситуация.
Почему технический долг негативно влияет на работу?
Технический долг может замедлить работу, увеличить количество ошибок и сбоев, а также усложнить внесение изменений в систему. Например, если мы хотим добавить новую функцию в систему, может возникнуть необходимость сначала исправить старый код, что занимает больше времени и усилий, чем при написании кода с нуля.
Кроме того, технический долг может привести к снижению качества работы. Если команда постоянно исправляет старый код, у нее может не оставаться времени на то, чтобы написать новый, который будет соответствовать стандартам качества. В результате система может стать менее надёжной и удобной для пользователей. И именно с этим столкнулась техническая команда в «Нильсен».
Кроме того, технический долг может привести к снижению качества работы. Если команда постоянно исправляет старый код, у нее может не оставаться времени на то, чтобы написать новый, который будет соответствовать стандартам качества. В результате система может стать менее надёжной и удобной для пользователей. И именно с этим столкнулась техническая команда в «Нильсен».
Проблема: старый код и нестабильная система
В нашей компании годами существовала система для подготовки клиентских отчетов, основанных на сложных вычислениях с использованием старого набора библиотек 32-разрядного Python. Система работала медленно, была ограничена по использованию памяти и часто выдавала ошибки. Отдельной проблемой была несовместимость с рядом современных библиотек. Такая ситуация — это и есть технический долг, который не позволяет улучшать производительность и стабильность системы. И именно поэтому мы решили от него избавляться.
Чтобы бороться с техническим долгом, нужно регулярно проводить рефакторинг кода. Рефакторинг — это процесс изменения структуры нашего кода без изменения его функциональности. Это позволяет улучшить качество кода, сделать его более удобным для чтения и понимания, а также упростить внесение изменений в будущем.
Несмотря на то, что доработки могут занять довольно длительное время, это важная и значительная инвестиция в будущее нашей системы. Чем больше мы вкладываем в рефакторинг, тем меньше технического долга накапливаем, а в конечном счете это приводит к более быстрой и качественной работе и повышению удовлетворённости пользователей.
Решение: переход на новые библиотеки
Шагом номер один в работе рефакторинга стал переход на более современную версию библиотек Python, которые лучше поддерживали параллельные вычисления и оптимизацию кода.
Конечно, поначалу эта идея столкнулась с критикой: существовали опасения, что в условиях непрерывного производства баз данных и плотного графика предоставления их клиентам процесс устранения технического долга будет сложным и трудоёмким, а новые технологии и методы этого устранения будут неэффективными и дорогостоящими. Однако преимущества подхода и перспективы внедрения нового функционала «перевешивали» все опасения и подтолкнули нас к этому шагу.
С технической точки зрения мы начали этот процесс с тщательного анализа кода и определения участков, которые могли бы выиграть от этих улучшений. После этого команда заменила старые библиотеки на новые, убедившись, что все функции и интеграции остались рабочими.
Конечно, поначалу эта идея столкнулась с критикой: существовали опасения, что в условиях непрерывного производства баз данных и плотного графика предоставления их клиентам процесс устранения технического долга будет сложным и трудоёмким, а новые технологии и методы этого устранения будут неэффективными и дорогостоящими. Однако преимущества подхода и перспективы внедрения нового функционала «перевешивали» все опасения и подтолкнули нас к этому шагу.
С технической точки зрения мы начали этот процесс с тщательного анализа кода и определения участков, которые могли бы выиграть от этих улучшений. После этого команда заменила старые библиотеки на новые, убедившись, что все функции и интеграции остались рабочими.
Одним из ключевых моментов во время перехода было использование многопоточности и асинхронных операций, которые позволили существенно ускорить обработку данных. Были внедрены новые алгоритмы оптимизации запросов, что уменьшило количество времени, затрачиваемое на обработку данных, и увеличило эффективность нашей системы. Например, если раньше на формирование каждого отчета для клиентов уходило в среднем 60 минут, то с улучшенной версией этой программы время сократилось до 8 минут. А при создании больших отчетов (по целым секторам рынка — продовольствие, алкоголь и т.д.) время сократилось с 1-2 суток до нескольких часов.
Результаты
После всех изменений мы провели тщательное тестирование системы — в первую очередь, чтобы убедиться, что наши обновления работают без ошибок и сбоев, и только после этого запустили новую версию системы в эксплуатацию.
В результате код после перехода на новые библиотеки стал гораздо чище и легче для понимания, а новая система стала еще быстрее, стабильнее и менее подвержена ошибкам. Если раньше за один цикл генерации было 8-9 ошибок, то сейчас за тот же период времени их количество сократилось до 2-3.
Более того, благодаря многопоточной обработке данных и новым алгоритмам оптимизации запросов мы смогли достичь уже семикратного увеличения производительности нашей системы: на один запрос теперь стало уходить не более 8 минут вместо часа. Теперь наша техническая команда может сосредоточиться на разработке новых функций и улучшении продукта, а не на решении проблем с устаревшим кодом.
В результате код после перехода на новые библиотеки стал гораздо чище и легче для понимания, а новая система стала еще быстрее, стабильнее и менее подвержена ошибкам. Если раньше за один цикл генерации было 8-9 ошибок, то сейчас за тот же период времени их количество сократилось до 2-3.
Более того, благодаря многопоточной обработке данных и новым алгоритмам оптимизации запросов мы смогли достичь уже семикратного увеличения производительности нашей системы: на один запрос теперь стало уходить не более 8 минут вместо часа. Теперь наша техническая команда может сосредоточиться на разработке новых функций и улучшении продукта, а не на решении проблем с устаревшим кодом.