Помимо изменения функциональности программы программирование включает в себя изменение её структуры с сохранением семантики, что обычно называют рефакторингом. Любой рефакторинг несёт в себе риски того, что семантика всё-таки будет изменена, если программист допустит ошибку в этом процессе. Не всегда дальнейшее тестирование способно вовремя выявить такую регрессию. Кроме того, боязнь подобной регрессии вынуждает программистов отказываться от рефакторинга там, где он был бы очевидно полезен.
Однако часто рефакторинг можно разбить на набор атомарных шагов-транзакций, после каждого из которых семантика сохраняется. Чем меньше эти шаги, чем короче «разломанное состояние программы», тем меньше вероятность ошибки. В ряде случаев удаётся довести процесс до идеала: каждая команда, которую вы отдаёте среде разработки, модифицирует код, сохраняя семантику. В таком случае шанс ошибки снижается практически до нуля.
Мы посмотрим на примерах, как можно добиться этого при рефакторинге Java-кода в среде IntelliJ IDEA и каким образом можно заставить среду рефакторить атомарно, если она сопротивляется.
- делая рефакторинг руками мы можем привнести в код ошибки
- программа до и после могут быть не эквивалентны
- при переходе между состояниями программа находится в сломанном состоянии
- призвать на помощь IDE
- делать преобразования только (или очень максимально) силами IDE
- преобразования средствами IDE от текущего состояния к целевому образуют "дорожку" в виде "мостиков" между "островами" эквивалентных программ
- IDE не во всем совершенна
- путь может быть не всегда таким прямым, как при ручном рефакторинге
- изучать способы рефакторинга с помощью IDE
- расширять и настраивать свои шаблоны