Назовите поведение до изменения структуры
Представим учебную функцию расчёта доставки. Для заказа дешевле 3000 рублей доставка стоит 200 рублей, начиная с 3000 она бесплатна. Пока это единственное правило, которое нужно сохранить. Смена названий переменных не должна незаметно изменить границу бесплатной доставки. Запишите ожидаемые результаты для сумм 2999, 3000 и 3001. Эти примеры проверяют разные стороны порога. Отдельно уточните допустимые входные данные: принимает ли функция только неотрицательные целые суммы в рублях и что должно происходить при нарушении этого условия. Не придумывайте новое поведение молча во время наведения порядка.
Имена должны раскрывать смысл значения
Переменная с коротким названием может обозначать стоимость товаров, итог вместе с доставкой или сумму после скидки. Если смысл приходится восстанавливать по нескольким строкам, полезно выбрать более точное имя. Длина сама по себе не является проблемой, пока название помогает чтению. Число 3000 можно связать с понятным именем порога бесплатной доставки. Но не каждое число требует отдельной сложной конструкции. Важно, чтобы правило было заметно в месте использования, а выбранные названия соответствовали фактическому смыслу данных и единицам измерения.
Меняйте по одному понятному элементу
Рефакторинг предполагает изменение внутренней структуры без изменения наблюдаемого поведения. Поэтому удобнее сначала переименовать неясную переменную, проверить результат, затем при необходимости выделить расчёт в отдельную функцию. Несколько небольших шагов легче проследить, чем одновременную перестройку всей программы. Если попутно обнаружена ошибка в правиле доставки, её исправление стоит обозначить отдельно. Иначе при изменившемся результате будет непонятно, является ли это запланированной новой логикой или случайной поломкой. Разделение задач помогает и автору, и человеку, который будет проверять изменение.
Проверяйте результат, а не только новую форму
Тест на доставку должен подтверждать ожидаемую сумму для заданного заказа, а не требовать конкретного названия внутренней переменной. Тогда полезное изменение структуры не разрушает проверку без причины. При этом успешные тесты подтверждают только рассмотренные случаи и не гарантируют отсутствие всех ошибок. После переработки прочитайте код как новый участник проекта. Понятно ли, где находится правило, что возвращает функция и какие данные ей нужны? Если ради удаления двух строк появилась длинная цепочка переходов между мелкими функциями, читаемость могла ухудшиться. Цель состоит в ясности и надёжности дальнейшей работы.
Попробуйте на практике
Спланируйте небольшую переработку учебного расчёта доставки, не меняя установленное правило.
- Запишите правило: при сумме товаров меньше 3000 рублей доставка равна 200 рублям, от 3000 рублей включительно равна нулю.
- Укажите ожидаемые результаты для 2999, 3000 и 3001 рубля. Отдельно определите, какие входные данные считаются допустимыми.
- Найдите одно неясное имя или скрытое правило в учебном коде. Предложите небольшое изменение и объясните его пользу.
- После изменения проверьте те же входы и ожидаемые результаты. Если поведение изменилось, выясните причину до следующего шага.
- Попросите другого читателя пересказать правило по новой записи либо сделайте это самостоятельно спустя паузу. Оцените ясность, а не только количество строк.
Как проверить результат. Для допустимых входных данных поведение сохранено, граница 3000 обработана правильно, а смысл расчёта стал проще восстановить при чтении.
Частые вопросы
Любое сокращение кода считается рефакторингом?
Нет. Важно, сохраняется ли наблюдаемое поведение и улучшается ли структура. Сокращение может изменить смысл или сделать правило менее понятным.
Нужно ли сразу переписывать весь неудобный модуль?
Не обязательно. Начните с небольшого участка и ясной проверки. Более широкая перестройка оправданна, когда понятны её цель, зависимости и способы обнаружить нежелательные изменения.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.