Привет, Хабр! Меня зовут Евгений Старков, и я, как и вы, часто сталкиваюсь с техдолгом.
Пришло время рассказать, как я с ним справляюсь! Проблема не нова и встречается в любой компании, связанной с разработкой. Мне, по большей части, техдолг достался «в наследство». Первой задачей в Тензоре было разделение и рефакторинг большой части кодовой базы своей группы. Там попадались и суперклассы, и файлы с количеством строк, перевалившем далеко за 1000, и именование переменных по типу a, b, c.
Не так давно в мое владение перешел еще один функционал, в котором я снова столкнулся с данной проблемой. Пусть этот модуль станет пациентом, а я выступлю в роли терапевта для программного кода. Для начала давайте поймем – что такое технический долг?
Долг кода, технический долг – это термин из сферы информационных технологий, который подразумевает, что в прошлом в архитектуре или кодовой базе накопились проблемы, связанные с пренебрежением к качеству, стилю программирования или условностям и ограничениям архитектуры программного кода, которые в последующем сопровождении или модернизации приводят к дополнительным затратам.
Но мой пациент неживой, он не сможет напрямую сказать, что у него болит. Да и если у человека с его анатомией на каждую часть присутствует свой доктор, то в анатомии кода и долга специалист один – программист. А значит мне и решать все проблемы его частей. Выделим несколько из них:
сам код (качество, стиль, чистота)
исполнение в рантайме (скорость, оптимальность)
Соберем анамнез. Посмотрим, как было и потом сравним, спасли мы пациента или наоборот, сделали так, что он быстрее уйдет на покой.
Начнем с кода. Как выявить болячки здесь? Проведем диагностику. А в этом нам помогут линтеры, для предварительного диагноза. Начнем с pylint и проверим качество написания кода:
Плохо, но не критично. Тут в файлах заметно, что часть симптомов решили скрыть, отключив линтер:
Мы хотим знать объективную правду, срываем маски и видим, что пока сделали только хуже:
Начнем лечение того, что выявили:
Один файл больше 1000 строк (1847). Решим немного позже, так как можем полечить его, избавившись от других.
Дублирование кода, порой даже в пределах 100 строк. Вот пример:
Плюсом еще такое условие в 2х местах. Выносим в функцию и заменяем:
Подобным образом делаем для других повторов. Всего проблем с дублями 15 шт. Файл большой, поэтому выносим такие куски в отдельный файл, который будет хранить вспомогательный функционал. Мы избавились почти от 450 строк.
Результатом трудов стало улучшение состояния - мы делаем коду лучше.
Следующая проблема – использование форматирования строки, вместо f-строк. Данная проблема появилась по причине развития языка и ярко отображает то, что идеальный код со временем может приобрести проблемы. А таких у нас 87.
Эти ошибки исправить просто – меняем формат на f-строку.
Константы, шаблоны запросов и исключения затеряны в самом коде.
Это уменьшает читаемость. Все выносим в отдельные файлы.
Большое количество ветвлений, принимаемых и неиспользуемых аргументов.
Большие функции на 200+ строк. По возможности избавляемся от ветвлений: одну из функций пришлось сделать классом (чтобы уменьшить ветвление), упростить сам код и сделать его лаконичней.
Теперь наш код здоров:
Но ведь нет предела совершенству. Да и когда мы видим вот такой код с отсутствием у части тайп-хинтингов, один глаз все-таки начинает дергаться.
Поэтому назначаем еще одну диагностику, а именно mypy, и видим следующую картину:
Исправляем, правим типы или добавляем их, так же типизируем принимаемые параметры в функциях и получаем уже приятную глазу картину:
Но откуда же взялись эти проблемы?
Основные причины появления технического долга:
низкая квалификация сотрудников и отсутствие надзора за их исполнением;
отсутствие стандартов написания кода, проектирования функционала;
отсутствие контроля за соблюдением правил, стилистики и архитектуры;
жесткие временные рамки;
плохая взаимосвязь или ее отсутствие между бизнесом и разработкой;
ошибки проектирования или его отсутствие;
изменения требований внутри компаний или переход на новый стек технологий, иногда, обновление сторонних библиотек.
Теперь само написание кода проблем не имеет, но пациент все равно нам всеми силами намекает: «что – то не так!». Простая задачка им выполняется слишком долго, как будто он делает много лишнего.
Идем смотреть, как все работает и видим эти симптомы.
Наш запрос выполняется очень долго, больше половины времени работы всего функционала. Смотрим план, ищем проблему. Оказалась, что нам нужно прочитать несколько записей (часто не больше 10), а мы вычитывали всю базу с кучей Join`ов и фильтраций. Добавляем условие для фильтрации по конкретным идентификаторам и получаем:
То есть прирост составил больше 95% во времени и сам запрос теперь занимает не больше 10% тайминга работы всего метода.
Но теперь у нас есть трата временного ресурса на работу языка, занимающая больше 500мс или почти 70% рабочего времени.
Начинаем смотреть и видим не оптимальность.
Здесь начинаем перебор записей и сборку из них другой записи с медленным методом Set, который рекомендуется использовать для установки одной записи. Переделаем на лучший вариант:
Массовое присвоение полей работает куда быстрее. Второй вариант схож с данной ситуацией, но усложнен тем, что перебор ведется в 2х циклах, которые можно было избежать. И вот видим хорошую картину:
Теперь среднее время работы составило не 1800мс, а всего лишь 160мс. То есть мы получили прирост в скорости больше чем на 90%.
Пациент спасен и теперь гордо трудится на радость клиентам, но таких как он, еще много.
Почти все ИТ-компании имеют технический долг, но не у каждой есть с ним сложности. Где же эта тонкая грань?
Данный вопрос становится проблемой, когда он либо бесконтрольный, либо проценты уже слишком высоки. «Долговая яма» очень сильно влияет на вовлеченность команды, особенно в случаях, когда данный код достается «в наследство». Сопровождение такого кода становится тяжелой, а иногда и невыполнимой задачей. Отсюда вытекают негативные последствия:
Большие временные затраты
Сложность внедрения новыx фич, которые могут увеличить сам долг.
Снижение мотивации команды и общей комфортной среды внутри.
Выгорание и отсутствие интереса.
Один из основных способов решения – рефакторинг кода (контролируемый процесс улучшения кода или процесса старой кодовой базы без внесения в него новых возможностей).
Существуют и другие способы уменьшения долга:
Стабильная реструктуризация и рефакторинг – создание небольших задач на оптимизацию, выделение времени в процессе доработок и внесение нового функционала.
Приоритетность – вытекает из прошлого пункта. Если затраты времени неимоверно высоки, то в приоритете исправить ситуацию, нежели добавить новых фишек и, тем самым, увеличить %.
Внедрение ревью (желательно многоступенчатого), стандартов написания и стиля кода, развитие команды и совместное обсуждение, встречи. Внедрение систем автоматической проверки кода.
Разработка ТД, схем процессов, данных и архитектуры в целом. Помогает выявить проблемы на основе визуализированных и технических данных. Отличный вариант – проектирование полного бизнес-процесса на этапе создания функционала поможет избежать проблем в будущем при определённом уровне команды, поддержка актуальности документации позволит «новичкам» (не только уровень программирования, но и просто новая команда или сотрудник) вникнуть в процесс быстрее и проще. Но данный способ является больше утопией в современной разработке, чем повседневностью.
Мы для себя выявили следующе правило – оставь после себя лучше, чем было. То есть при исправлении ошибки или доработке какого-либо файла, мы пробегаемся глазами и стараемся поправить те вещи, которые нам не понравились или видно, что можно сделать лучше.
Подведем итоги
Сам долг не всегда является проблемой или чем-то плохим, он будет всегда. Но мы можем приложить определенные усилия для того, чтобы уменьшить его или избежать в будущем.
Вот и всё. Буду рад здравой критике и ярым обсуждениям.