В жизни каждого проекта возникает такой момент, когда поднимается вопрос о рефакторинге. Технические специалисты хотят чего-то нового, модного и интересного в проекте. Бизнес требует новой функциональности быстрее и быстрее. Команда говорит о том, что тяжело вносить изменения, и требуется рефакторинг. Знакомая ситуация? Cегодня только об этом и ни на байт о блокчейн.

Прежде чем соглашаться на рефакторинг системы/подсистемы, необходимо, по моему мнению, ответить на следующие вопросы:

• Действительно ли он нам необходим?
• Что нам даст рефакторинг?
• Какие будут последствия?
• Как сделать так, чтобы рефакторинг в последующем не требовался?
• Если все таки переписывать, то какой план?

Действительно ли он нам необходим, или “Пчелы против меда”

Прежде чем производить рефакторинг, стоит хорошо проанализировать проект, использовать автоматические инструменты для того, чтобы оценить существующую кодовую базу, например, SonarQube. Произвести замеры производительности и собрать детальную информацию о том, где же присутствует место для повышения произвольности.  

После этого стоит посмотреть на то, сколько времени инженеры тратят на поддержку существующего решения и внедрение новых фич. Может оказаться так, что существующая система плохо расширяема, данные по трудозатратам можно получить из JIRA/Redmine/TeamCity/TFS. Еще хорошо бы проверить, как владелец продукта вносит изменения, не меняются ли user story. В этом случае потребуется рефакторинг процесса работы, процедур, связанных с обработкой Change Requests.

Что нам даст рефакторинг, или “Где деньги, Зин?”

При совершении договоренности о рефакторинге необходимо договориться о том, что будет сделано. Стоит получить список конкретных “ценностей”, которые будут получены после рефакторинга. Они должны быть измеримы в каких-то единицах, например: 

• время обработки заказа будет сокращено на x минут;
• время на внедрение новой фичи будет понижено в 2 раза;
• рефакторинг даст возможность делать A/B тестирование, а это приведет к дополнительным продажам;
• даст возможность поддерживать больше клиентов, а следовательно – больше заказов.

На данном этапе стоит собрать те преимущества, что будут понятны бизнес-заказчику.

Какие будут последствия, или “Разработчик ни в чем не виноват”

При производстве рефакторинга очень важно понять, какие будут последствия, не только положительные :) но и критические для качества. Будет ли необходимо проводить регрессионное тестирование или нет, стоит ли запускать тесты на локализацию или производительность системы, одним словом, необходимо понять, что будет поломано, кроме того, что подвергалось рефакторингу, и что стоит усердно проверить. 

Для того чтобы понизить сайд-эффекты, лучше попросить разработчиков сопроводить рефакторинг набором unit- и автоматизированных тестов, в том числе интеграционных, - это может послужить дополнительной работой, однако добавит дополнительный уровень контроля, а также останется в системе в виде дополнительного улучшения для заказчика ;)

Для того чтобы обезопасить команду от ненужной работы по вечерам/в ночи для вывода хот фикса, стоит также прогнать цикл регрессионного тестирования в полном объеме, провести ряд exploratory testing сессий. Это даст возможность выявить интересные дефекты :)

В итоге мы должны понять:

• что может быть “задето” в результате рефакторинга;
• как мы будем проверять работоспособность системы;
• какие тесты/результаты будут предоставлены в качестве доказательств, что все в целости и сохранности;
• какие рекомендации будут предоставлены отделу контроля качества от программистов;
• как мы проверим то, что “старые” пользователи не пострадают.

Как сделать так, чтобы рефакторинг в последующем не требовался, или “Нормально делай, нормально будет”

Очень часто руководители спрашивают, а можно ли сразу разработать систему без багов? Конечно же можно, только это потребует больше времени. За годы участия в разработке программных продуктов я заметил, что в большинстве случаев разработка идет эволюционным путем, если посмотреть на историю развития ОС от одного очень крупного производителя, можно заметить, что успехом сопровождается только каждая вторая.

  Так или иначе, от ошибок не уйти, но можно воздействовать на их количество, для этого стоит принять набор мер, чтобы понизить их количество:

• использовать unit- и автоматизированное тестирование;
• внедрить BDD;
• уменьшить размер фич, вносить и публиковать изменения меньшего размера, а следовательно, упрощать систему;
• заниматься рефакторингом :) меньшего размера, на постоянной основе, подобно ежедневной домашней уборке;
• требовать от команды технической ответственности за разрабатываемую систему;
• давать доступ к измененной/новой фиче ограниченному ряду лиц, но не всей аудитории сразу же - позволит выявить проблемы гораздо раньше;
• начать использовать унифицированные архитектурные подходы для того, чтобы понизить разнообразие технических решений;
• ввести и наладить процедуру технического надзора перед созданием новой фичи / внесением изменений, производить архитектурное ревью и контроль решений, фиксировать результаты и собирать рекомендации;
• ввести сбор метрик по complexity, code quality и отслеживать эти показатели.

По моему опыту, от рефакторинга уйти не удастся, однако можно понизить “масштабы бедствия от него” :) внедрением выше перечисленных процедур. 


Если все таки переписывать, то какой план, или “Огласите весь список”

После того как разрешение на рефакторинг получено, необходимо у команды попросить:

• список того, что будет сделано, запросить список конкретных измеряемых метрик, которые будут качественно улучшены;
• архитектурное предложение/эскиз, что должно быть получено;
• график выполнения работ;
• список рисков;
• тактику работы с рисками;
• план, если рефакторинг не удастся завершить, да, именно план, когда все пропало.

Отдельно хочу выделить то, что от команды можно потребовать произвести рефакторинг таким образом, чтобы его можно было вывести в боевую систему в незаконченном виде и это никак не повлияло на систему. В этом случае инженеры будут ответственнее относиться к работе.

Из рекомендаций по производству рефакторинга могу посоветовать:

• разбивайте код на отдельные слои;
• следуйте архитектуре;
• старайтесь писать компоненты/системы компактно и взаимозаменяемо;
• понижайте связанность систем;
• пишите как можно больше тестов;
• стремитесь к связанности систем в соответствии с общими “протоколами/интерфейсами”.

P.S.:

Возможно эта статья вам показалась банальной, однако я не раз наблюдал случаи, когда инженеры увлекались рефакторингом, а ценности не приносили. Я вовсе не против рефакторинга, я за то, чтобы он был успешен. Если релиз провален из-за затянувшегося рефакторинга, потом просить новый рефакторинг будет сложнее и сложнее. Лучше сделать первый маленький рефакторинг, доказать состоятельность этой процедуры, завоевать доверие заказчика и получать разрешение на последующие шаги в разы проще. 

Большое путешествие начинается с первого шага, а модернизация системы с маленьких побед с простыми и понятными улучшениями :) 

Не срезайте углы, не делайте хаков, вам с ними еще жить :)

Удачи и приятной разработки, ваш Капитан Очевидность :)