Принял участие в первом заседании книжного клуба JitterTed, начали читать книгу Refactoring, 2nd edition. Для меня это первая такая встреча, где мне пришлось активно слушать и участвовать в дискуссии на английском языке в группе из примерно 20 человек. Зафиксирую впечатления, пока они еще свежи в памяти.
- Состав участников - все довольно взрослые люди, я бы сказал, что большей части уже за тридцать, но были и значительно старше (насколько я могу судить по внешнему виду). География не очень обширная, Германия, Бельгия, Голландия, США, Канада и Аргентина (это помимо меня). Среди 21 участника было три женщины, процент маленький, но очень весомый, как оказалось. В основном Java и C#, но было и немножко Go, немного JavaScript. По большей части все уже состоявшиеся профессионалы, по-моему, было всего два человека, которые сказали, что программируют недавно.
- Активное участие в обсуждение принимали примерно 7 человек, то есть треть группы. Очень круто, что у всех очень разный опыт и поэтому отличающийся взгляд на обсуждаемые вопросы. Кто-то приводит интересные примеры, кто-то делится выстраданным опытом, кто-то высказывает хорошо “созревшие” мысли.
- Удивительно, что за два часа (ну, полтора, если выкинуть вступительную часть и знакомство) мы успели поговорить о материале только первых 17 страниц книги, несмотря на то, что это довольно общие вводные положения. Обсудили всеобщее неверное толкование рефакторинга как одного большого шага (в противовес концепции маленьких шагов), масштаб отдельных рефакторингов, обязательность тестов (и требования к тестам - как понять, что тестов достаточно?) и безопасность отдельных рефакторингов. Это все очень верхнеуровнево и в общих чертах.
- При разборе примера рефакторинга из первой главы книги я зацепился за следующие новые для меня
идеи и формулировки:
- Рефакторинг зачастую проще начинать с инлайна нескольких разрозненных функций в один большой метод и затем выделять осмысленные куски из этого большого метода. Причин тому несколько: (1) существующая структура методов может быть нерелевантной, вводящей в заблуждение и тяжелой для понимания; (2) внутри большого метода проще увидеть возможные дублирования и схожие паттерны кода, т.е. обнаружить “более верные” абстракции, нежели те, что были обозначены в виде отдельных функций; и (3) снизить когнитивную нагрузку и необходимость переключаться между контекстами отдельных функций в попытках понять, что же делает этот большой фрагмент кода.
- Отличное предложение выносить в отдельный метод не самый маленький, а наоборот, максимально большой связный кусок кода. Это по идее должно формировать следующий уровень абстракции и таким образом постепенно формировать понимание того, что делает код. Выделение сначала маленьких функций сразу создает самый нижний уровень абстракции, и разрыв между верхним уровнем исходного метода и нижним уровнем примитивных функций не облегчает понимание функционирования.
- Рефакторинг
Replace Temp with Query- это пример “управления связанностью” (coupling adjustment), то есть разрыв связей с локальной переменной для того, чтобы можно было выносить отдельные маленькие функции, не передавая в них эту переменную.
В общем и целом я этой вводной встречей доволен, как слон, с нетерпением жду следующей!