Рефакторинг без особой боли

Рефакторинг — практически неотъемлемая часть процесса разработки. Его необходимость связана со следующими предпосылками:

• начальные требования практически никогда не бывают полными и разработка ведется в соответствии с определенными предположениями, некоторые из которых впоследствии оказываются не верными или не точными

• часто требуется внести быстрые правки, чтобы заработало прямо «здесь и сейчас», без учета дальнейшей поддержки

Обоснованные причины для рефакторинга

1. Дублирование кода

   Для наличия дублированного кода есть мало обоснований, чаще всего от него нужно избавляться

2. Универсализация

   Чтобы облегчить понимание кода и уменьшить количество проблем при эксплуатации, часто можно создать абстракцию, объединяющую похожий код. Важно иметь как минимум 3 прототипа для этой абстракции, иначе она может оказаться не точной

   Например, мне нужно было сделать интеграцию платежного шлюза с GooglePay. В процессе выяснилось, что процесс оплаты ApplePay и SamsungPay практически идентичен и изменения в одном из них часто требуются и в двух других. В итоге я сделал оплату для абстрактного VendorPay со стратегиями для каждого метода оплаты

3. Код не понятен

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

4. Переусложненный класс/метод

   Для меня достаточно таких формальных признаков, как больше 50 строк в методе или больше 500 строк в классе, чтобы задуматься над рефакторингом

Необходимое предусловие: код, который подвергается рефакторингу, должен часто меняться.

• если код лежит без движения больше года, то пусть уж дальше лежит в том же виде. Например, у нас в платежном шлюзе есть асинхронный клиент процессинга, один из ключевых классов, который можно было бы улучшить, но он не приносит много проблем. Он меняется редко и нет смысла его рефакторить, пока (если) не произойдет проблема, связанная с его структурой.

Почему многие не делают рефакторинг

• страшно поломать существующую функциональность

• трудоемко: если код, который ты рефакторишь, меняется, то мержить (многократно) его из основной ветки становится болью

• есть риск не успеть к дедлайну задачи

Как быть?

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

• иметь тесты (unit и регресс) с хорошим покрытием

• не смешивать пулл реквесты с рефакторингом и бизнес-логикой

• мержить рефакторинг сразу, не дожидаясь бизнес-задачи

Как я подхожу к рефакторингу

По нашему процессу мы создаем feature-ветку от master’а для каждой задачи.

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

По прошествии двух-трех дней разработки (бизнес-изменения + рефакторинг) чаще всего выясняется, что накопилось достаточное количество изменений структуры, которые можно выделить в отдельную ветку (от master’а), а бизнес-изменения — в ветку от рефакторинга.

После разделения изменения на две ветки я прошу коллег проревьюить ветку рефакторинга, мержу ее в master и делаю rebase бизнес-ветки на master.

Результат

Этот подход несет некоторые накладные расходы, но смягчает основные трудности при рефакторинге:

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

• поддерживать изменения других разработчиков не требуется, потому что изменения практически сразу сливаются с основной веткой

• в случае когда сроки подпирают, можно прекратить делать рефакторинг после очередного двух-трех дневного цикла