Рефакторинг или другими словами переработка кода, требуется любому развивающемуся проекту.
Его цель - исправление и улучшение проблемных участков кода. Как правило это внутренние изменения, которые не имеют влияния на внешнее отображение продукта, не прибавляют функциональности и не меняют скорость загрузки.
Так почему же он важен? И на что повлияет?
Мы разрабатываем идеальные продукты, с идеальным кодом. Живем в идеальном мире, с идеальными сроками, задачами, технологиями и специалистами. Или нет? Давайте остановимся на том, что всего понемногу.
Как бы нам не хотелось, всегда есть факторы снижающие качество, внешние или внутренние. Наша задача их контролировать, но избежать вовсе не получится.
Итак, когда нужен рефакторинг?
Случалось ли такое, что разработчики ходят к вам все чаще, с запросом на исследование кода (изучение и диагностику)? А ещё, задачи стали выполняться дольше чем на старте проекта, хотя сложность та же?
Это очевидные симптомы накопившегося технического долга. Он подразумевает, что в проекте все больше сложных и запутанных кусков кода, провалов в архитектуре, проект тяжело масштабируется.
Ну и откуда в моем проекте все это?
Можно спорить, портить отношения и уходить к другим разработчикам, у которых код все таки (якобы) идеальный. Или принять факт того, что появление технического долга и рефакторинг - неотъемлемые процессы разработки ит-продукта.
И как быть?
Честность и открытость
Да-да, scrum-мастер так и говорил!
Выстраивать открытые отношения, как в команде разработчиков, так и с клиентом. В данном случае, открытость подразумевает честность о положении дел в коде и архитектуре проекта.
Что если не бояться раскрывать проблемы? Не затягивать до момента, когда исправить ситуацию сложно, больно и дорого?
Совсем не просто мотивировать разработчиков выносить наружу проблемы, особенно если проект создавался в их команде.
Обычно, мы слышим такие истории про чужие проекты, которые пришли в новую команду «и тут понеслось». Про чужие ошибки и проблемы говорить легко, а как на счёт своих?
Говорить нужно и о своих, и о чужих, мотивировать всех членов команды к такому поведению.
Инструменты
Решением будет завести бек-лог с задачами, из выявленных проблемных мест проекта, и периодически делать спринты по их закрытию.
Конкретные задачи с часами на выполнение, а не рефакторинг чего-то неведомого и мнимые улучшения.
Пополняют этот список сами разработчики, встречая шероховатости в продукте.
Естественно, выделять рабочие недели (и даже дни) сложно, давайте начнем с простейшей приоритизации и планирования в работу этих задач между основными.
Кто платит?
Да, владельцу продукта придётся закладывать рефакторинг в бюджет.
Строить иллюзии о том, что команда будет работать бесплатно не стоит, а вот заложить в цену часа или каждой задачи - могут.
Возвращаясь к открытости - проще принять, обсудить и выделять ресурсы, чем вынуждать искать лазейки. Да и зачем? Если все работает и приносит прибыль.
Отправьте вашу задачу на почту info@artwot.ru или позвоните нам по телефону +7 (495) 055-15-23. Менеджер проконсультирует вас и предложит варианты решения вашей задачи.