Если вы столкнулись с проблемой повторного факторинга кода, написанного вами или кем-то другим, это может оказаться непростой задачей. Сказав это, это чрезвычайно распространено; Фактически, есть очень популярная и хорошо известная книга под названием Рефакторинг: улучшение дизайна существующего кода Мартина Фаулера, которая глубоко погружается в нее, систематически перечисляя стратегии того, как к ней подходить.
В этом посте мы на самом деле затронем вопрос, упомянутый Фаулером в этой книге, а именно необходимость создания жестких циклов обратной связи при повторном преобразовании кода.
Идея здесь в том, что при повторном факторинге вы захотите внести небольшие изменения. По словам Фаулера, после каждого небольшого изменения вы захотите немедленно скомпилировать и протестировать, чтобы убедиться, что вы ничего не сломали. «Ошибки легко сделать - по крайней мере, я считаю, что их легко сделать», - говорит он.
Идея здесь проста: с небольшим изменением у вас будет меньший радиус взрыва вещей, которые могли пойти не так. Вам не нужно копаться в тоннах изменений, чтобы увидеть, что именно привело к нарушению функциональности. Обнаружить это изменение и исправить - проще. Время, которое вы сэкономите на отладке, будет значительным.
Это ключ к тесной обратной связи: небольшие изменения, которые сразу же приносят результаты. С психологической точки зрения душевное спокойствие, зная, что что-то, что вы изменили, работает, может успокоить вас и даже чаще чувствовать себя хорошо на этом пути.
Компиляция важна в этом цикле обратной связи, и функциональное тестирование, безусловно, может служить своей цели в подтверждении успеха рефакторинга. Фаулер также отмечает, что надежный набор тестов действительно затянет петлю обратной связи.
По словам Фаулера, тесты должны быть самоконтрольными и, по сути, сообщать обо всем зеленом, сохраняя жизненно важные нажатия клавиш и щелчки в процессе, а не ручную проверку.
После прохождения тестов следующим шагом будет фиксация рабочих изменений в вашей локальной системе контроля версий, например в git. Таким образом, у вас всегда будет зафиксировано рабочее состояние на случай, если вы позже испортите; вам просто нужно вернуться к этому моменту времени. Фаулер обязательно подчеркивает локальную часть этого, поскольку это частные коммиты. Затем он лично превращает свои изменения в более важные коммиты, прежде чем отправить их в общий репозиторий.
С более жесткими циклами обратной связи рефакторинг станет процессом, в котором вы можете быть более уверены, а иногда он может иметь решающее значение.
