4 частые ошибки в рефакторинге

1. Внесение изменений без тестирования

Это наиболее распространенная ошибка. Кто-то может посчитать, что для внесения небольших изменений не стоит тратить время на тестирование, которое порой сложно настроить.

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

Я всегда начинаю с тестов. Если они уже имеются, следует внимательно изучить их возможности, чтобы понять, как использовать общедоступный API кода, который вы собираетесь изменить, как подготовить данные, чего ожидать и т. д. Если нет подходящих для тестирования средств, я их добавляю, чтобы получить уведомление, если что-то пойдет не так.

2. Реструктурирование вместо рефакторинга

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

Возможно, многие будут удивлены тому, что рефакторинг  —  это просто оптимизация существующего кода (и ничего более). А переименование переменной и функции, а также извлечение функции  —  это обычные рутинные операции.

Одно из возможных действий здесь  —  извлечение функции для выполнения mapping, а затем вызов ее в map:

Многое зависит от сложности функции. Когда она достаточно простая, вы вряд ли допустите серьезные ошибки. И поэтому длительность сбоя программы будет минимальной.

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

3. Отдельные задачи по рефакторингу

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

1. Вы находитесь под пагубным давлением доставки.


2. Накапливаются недоработки.


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

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

4. Использование неправильных инструментов

Ранее я работал с разными редакторами, IDE и другими инструментами. Но теперь уже не вернусь к ним после того, как поработал с IntelliJ и ознакомился с сочетаниями клавиш и другими особенностями. Я уже давно использую Vim, установил и настроил более 20 плагинов. Когда нужно настроить среду разработчика, я использую визуальный код для некоторых каузальных проектов и демонстраций.

Однако для серьезной работы лучше подойдут такие продукты, как JetBrains, IntelliJ, WebStorm и Pycharm. Встроенный инструмент рефакторинга достаточно “умен”, чтобы распознавать ваши намерения и выполнять их за вас. В 99% случаев он без каких-либо проблем способен обновлять все ссылки в проекте/рабочей области, синхронизировать файлы в системе. А разработчик может сосредоточиться на более важных задачах!

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

Заключение

Чтобы не тратить отдельное время на рефакторинг, выполняйте его в процессе написания кода. Сделайте это привычной практикой. Начните с малого, а по завершении работы выполните тестирование.