Один из участников книжного клуба отметил, что очень полезно прочитать / узнать конкретные механики выполнения каждого из представленных в книге рефакторингов. Таким образом “развеивается магия”, происходящая в IDE, когда программист выбирает нужный рефакторинг из предложенного списка. Также понимание хода изменений позволит понять границы применимости и спрогнозировать результат выполнения рефакторинга.

Подобная позиция - это проявление / поддержка принципа Технологии не могут заменить теорию, и я недавно столкнулся с очень показательным примером.

Я на днях заказывал противомоскитные сетки на окна и вызывал монтажника для их установки. У монтажника с собой был крутой шуруповерт, лазерный уровень, лазерная рулетка и тому подобные инструменты. Но при этом он все равно не смог установить сетки ровно, потому что во-первых, ошибся с размерами сеток, а во-вторых, установил петли в такие места, где им не хватало места для полноценного движения, и в результате сетки не прилегали плотно к раме окна.

Все это говорит о том, что у монтажника не хватило знаний о том, как правильно устанавливать сетки, на что обращать внимание при замерах и монтаже. И никакие инструменты не восполнят этот недостаток знаний.

Вывод №1: Качественное ПО создается не инструментами и не процессами, а людьми. Если мы хотим получать более качественный софт, нужно вкладываться не в создание новых IDE / языков программирования / линтеров фреймворков, а в создание образованных, опытных, знающих принципы и умеющих их применять на практике инженеров. В поддержку этого вывода высказывались David West и Robert Martin.

Вывод №2: Я не смогу эффективно рефакторить код без инструментальной поддержки моей IDE. Б_о_льшая часть моих навыков рефакторинга - это всего лишь знание, какой из пунктов выбрать в выпадающем меню. Мое личное понимание механик рефакторинга недостаточно, и в сложной ситуации я, скорее всего, не смогу комфортно работать и рефакторить код.