Martin Fowler’s guide to reworking bad code into well-structured code
Refactoring improves the design of existing code and enhances software maintainability, as well as making existing code easier to understand. Original Agile Manifesto signer and software development thought leader, Martin Fowler, provides a catalog of refactorings that explains why you should refactor; how to recognize code that needs refactoring; and how to actually do it successfully, no matter what language you use.
- Refactoring principles: understand the process and general principles of refactoring
- Code smells: recognize “bad smells” in code that signal opportunities to refactor
- Application improvement: quickly apply useful refactorings to make a program easier to comprehend and change
- Building tests: writing good tests increases a programmer’s effectiveness
- Moving features: an important part of refactoring is moving elements between contexts
- Data structures: a collection of refactorings to organize data, an important role in programs
- Conditional Logic: use refactorings to make conditional sections easier to understand
- APIs: modules and their functions are the building blocks of our software, and APIs are the joints that we use to plug them together
- Inheritance: it is both very useful and easy to misuse, and it’s often hard to see the misuse until it’s in the rear-view mirror---refactorings can fix the misuse
Examples are written in JavaScript, but you shouldn’t find it difficult to adapt the refactorings to whatever language you are currently using as they look mostly the same in different languages.
Fowler M. Refactoring: improving the design of existing code / M. Fowler, 2-е изд., Boston: Addison-Wesley, 2019. 418 c.Оценка авторской мысли
- Какова цель автора?
- На какой вопрос автор пытается дать ответ?
- Какую информацию автор использует в своих умозаключениях?
- Каковы главные выводы автора?
- Каковы основные концепты и идеи в мышлении автора?
- Из каких предположений исходит автор?
- С какой позиции автор рассматривает вопрос?
- Если автор прав, то что из этого следует?
Конспект
Предисловие и введение
- Рефакторинг важен для построения фреймворков, но ни один фреймворк нельзя создать сразу правильно. Такое ощущение, что предисловие к первому изданию было написано достаточно давно, когда в общем считалось, что прикладные программы не часто изменяются. Сейчас это явно устаревшее представление, поэтому ограничивать (или явно отмечать сильную связанность) область рефакторинга фреймворками нельзя.
- Рефакторинг - рисковое занятие. Отмечается необходимость выполнять по одному изменению за раз, при этом подходить к этому изменению очень формально и дисциплинированно.
- Четкая связь между рефакторингом и объектно-ориентированным программированием (предисловие к первому изданию написал Эрих Гамма, один из “банды четырех”).
- Обычный вопрос - а кому и зачем нужен рефакторинг? Тут явная связь с Tidy First, Кент Бек там объясняет, как обнаружить момент требуемой уборки в коде, задавая себе четыре вопроса про выручку, затраты, связанность и связность.
- Рефакторинг - это улучшение структуры кода после того, как код уже написан. Это изменение структуры без изменения поведения. Это формализованный способ чистки кода, минимизирующий появление багов. Последнее из этих заявлений требует примечания мелким шрифтом или дальнейших пояснений о том, за счет чего достигается минимизация появления багов. На мой взгляд это достигается за счет Many More Much Smaller Steps, наверняка дальше по тексту книги это будет явно отмечено.
1. Рефакторинг: первый пример
- Рефакторинг важен перед лицом изменений. Если не нужно ничего изменять, то и рефакторинг не нужен.
- Плохо спроектированный код == плохо структурированный код. Отсутствие структуры мешает понять, что именно нужно изменить для получения требуемого результата, и как эти изменения повлияют на уже существующее поведение. А если понять это трудно, то легко сделать ошибки, зачастую неочевидные.
Из этого вроде бы следует правило Кента Бека "First make the change easy, then make an easy change".
Разница в том, что Фаулер говорит о понятности, а не о простоте внесения изменений, хотя это
и связанные понятия.
- Первый шаг в рефакторинге - это всегда тесты.
Jitter Ted’s book club
- Coupling adjustment: Замена переменной на запрос - это рефакторинг, позволяющий разорвать связанность. До рефакторинга код был связан с локальной переменной, поэтому отдельные его фрагменты нельзя было изолировать и вынести в отдельные функции, не передавая в них эту локальную переменную. После рефакторинга во всех местах использования переменной мы обращаемся к вспомогательному методу, что позволяет нам вынести отдельные фрагменты исходного метода в изолированные компоненты, не передавая в них дополнительный параметр. К тому же метод запроса выравнивает уровни абстракции, потому что инкапсулирует “как”, и декларирует “что”.