Когда применять рефакторинг?
На этот вопрос есть очень простой ответ: всегда. Занимайтесь рефакторингом при малейшей возможности – рефакторинг улучшает ваш код и, потратив на него сегодня 5 минут, Вы завтра сэкономите на поиске ошибок час. Самый простой метод применения рефакторинга такой: каждый раз, когда вы что-то меняете в программе – добавляете новую функцию, класс, просто объявляете переменную, или Вам надо поменять пару строк в какой-то функции – посмотрите на соседний код, находящийся выше и ниже того участка, с которым Вы работаете сейчас. Проверьте, может быть, в этот код можно внести какие-то изменения, что бы он стал ещё более понятным и/или простым, может быть Вы найдёте в нём какие-то логические ошибки или Вам в голову придёт при каком сочетании параметров код может дать сбой. Если Вы увидели что-то подобное, то займитесь рефакторингом. Но не следует скакать по коду из конца в конец – если Вы пришли что-то добавить в код или поменять – сначала сделайте то, зачем Вы пришли, а потом уже занимайтесь рефакторингом. Иначе в итоге Вы можете вообще забыть, зачем вы открыли исходник.
Когда заканчивать рефакторинг?
Постарайтесь не заболеть “синдромом рефакторинга”. Если Вы сделали код, посмотрели вокруг и всё Вас устраивает – не надо рыскать по коду в поисках “чего бы тут ещё зарефакторить”. Если Вам нечем заняться – сходите в спортзал, покатайтесь на машине, сходие в клуб или хотя бы просто попейте пивка. Делать рефакторинг только потому, что Вам лень делать что-либо ещё – это очень плохая привычка.
Рефакторинг кода
Термин рефакторинг означает изменение исходного кода программы без изменения его внешнего поведения. Иногда под рефакторингом ошибочно подразумевают изменение кода с заранее оговоренными правилами отступа, перевода строк, внесения комментариев и прочими визуально значимыми изменениями, которые никак не отражаются на процессе компиляции, с целью обеспечения лучшей читаемости кода – это не рефакторинг, это просто подгонка кода под коде-стайл проекта.
Рефакторинг изначально не предназначен для исправления ошибок и/или добавления новой функциональности – он вообще не должен менять поведение вашей программы и именно это помогает избежать ошибок и, в будущем, облегчить добавление новой функциональности в программу. Рефаткоринг выполняется только для улучшения понятности кода и/или изменения его структуры, для удаления “мёртвого” (старого, уже не нужного, оставленного “на всякий случай”) кода – для того, чтобы в будущем код было легче поддерживать и развивать ваш код. Например, добавление в программу нового поведения может оказаться сложным с существующей структурой — в этом случае Вы можете сначала выполнить необходимый рефакторинг, а уже затем добавить новую функциональность.
Так же это может быть перемещение дынных из одного класса в другой, вынесение фрагмента кода из метода и превращение его в самостоятельный метод или даже перемещение кода по иерархии классов. Каждый отдельный шаг может показаться элементарным, но совокупный эффект таких малых изменений в состоянии радикально улучшить проект или даже предотвратить распад плохо спроектированной программы.
В экстремальном программировании и других подобных гибких методологиях, рефакторинг является неотъемлемой частью цикла разработки программы: разработчики то создают новые тесты и функциональность, то выполняют рефакторинг кода для улучшения его логичности и прозрачности, и снова циклически повторяют – новые тесты/код, рефакторинг, новые тесты/код, рефакторинг и т.д. Автоматическое юнит-тестирование позволяет программистам убедиться, что рефакторинг не разрушил существующую функциональность, т.е. что он был проведён правильно и без ошибок.