1. Внесение изменений без тестирования
Это наиболее распространенная ошибка. Кто-то может посчитать, что для внесения небольших изменений не стоит тратить время на тестирование, которое порой сложно настроить.
Но ведь без тестирования даже незначительные изменения могут привести к неожиданным последствиям для других частей программы.
Я всегда начинаю с тестов. Если они уже имеются, следует внимательно изучить их возможности, чтобы понять, как использовать общедоступный API кода, который вы собираетесь изменить, как подготовить данные, чего ожидать и т. д. Если нет подходящих для тестирования средств, я их добавляю, чтобы получить уведомление, если что-то пойдет не так.
2. Реструктурирование вместо рефакторинга
Подобно многим другим терминам в ПО, понятие рефакторинг становится многозначным. Иногда рефакторингом называют реструктуризацию, замену базовых библиотек и многое другое.
Возможно, многие будут удивлены тому, что рефакторинг — это просто оптимизация существующего кода (и ничего более). А переименование переменной и функции, а также извлечение функции — это обычные рутинные операции.
Одно из возможных действий здесь — извлечение функции для выполнения mapping, а затем вызов ее в map:
Многое зависит от сложности функции. Когда она достаточно простая, вы вряд ли допустите серьезные ошибки. И поэтому длительность сбоя программы будет минимальной.
Даже в наихудшем случае, когда ситуация выходит из-под контроля, можно легко отменить изменения и без особых усилий вернуться в рабочее состояние.
3. Отдельные задачи по рефакторингу
Нередко встречаются такие задачи, как очистить асинхронный код для API продукта или рефакторинг бизнес-логики расчетного времени доставки. Это плохой признак, потому что он может означать следующее.
- Вы находитесь под пагубным давлением доставки.
- Накапливаются недоработки.
- В худшем случае это с высокой вероятностью приведет к полному рефакторингу кода, что может быть чрезвычайно сложно сделать (без нарушения существующих функций).
Поэтому вместо такого специального рефакторинга можно решать проблему в рамках текущей задачи. Например, переименовать или извлечь функцию, не слишком отвлекаясь на задачу. Если делать это регулярно, то модифицировать код и добавлять новые функции в дальнейшем будет намного проще.
4. Использование неправильных инструментов
Ранее я работал с разными редакторами, IDE и другими инструментами. Но теперь уже не вернусь к ним после того, как поработал с IntelliJ и ознакомился с сочетаниями клавиш и другими особенностями. Я уже давно использую Vim, установил и настроил более 20 плагинов. Когда нужно настроить среду разработчика, я использую визуальный код для некоторых каузальных проектов и демонстраций.
Однако для серьезной работы лучше подойдут такие продукты, как JetBrains, IntelliJ, WebStorm и Pycharm. Встроенный инструмент рефакторинга достаточно “умен”, чтобы распознавать ваши намерения и выполнять их за вас. В 99% случаев он без каких-либо проблем способен обновлять все ссылки в проекте/рабочей области, синхронизировать файлы в системе. А разработчик может сосредоточиться на более важных задачах!
Чтобы максимально использовать возможности этого инструмента и автоматически повторять часто используемые варианты рефакторинга, следует запомнить раскладку горячих клавиш. Спустя несколько лет использования я с легкостью выполняю множество действий.
Заключение
Чтобы не тратить отдельное время на рефакторинг, выполняйте его в процессе написания кода. Сделайте это привычной практикой. Начните с малого, а по завершении работы выполните тестирование.
Читайте также:
- Неужели комментировать код — это плохо?
- Как не попасть в капкан зубрежки начинающему — и продолжающему разработчику
- Живи и программируй: обретение баланса
Читайте нас в Telegram, VK и Дзен
Перевод статьи Juntao Qiu: 4 Common Mistakes You Make in Refactoring
