Что я узнал, читая книгу Мартина Флауэра
Как разработчики программного обеспечения, мы должны принимать изменения. Меняются фреймворки, меняются требования, меняются ожидания… Включение этих изменений в существующую кодовую базу не всегда просто. Но написание чистого и хорошо структурированного кода облегчит вам задачу в будущем.
Как разработчики и дизайнеры, или даже как люди, мы не всегда принимаем наилучшее решение в начале. Иногда полезно увидеть, куда заведет нас это путешествие, и тогда мы пересматриваем наши предыдущие решения. Чем внимательнее мы отнесемся к этим будущим изменениям, тем легче будет применить их, когда придет время. Это почти всегда имеет место для разработки программного обеспечения. Рефакторинг — это способ, которым мы пересматриваем наши прошлые решения для нашего программного обеспечения.
Я хотел бы поделиться своими главными выводами из книги Рефакторинг Кента Бека и Мартина Фаулера. Книга делится бесценными практическими идеями о рефакторинге. Существует также каталог многих методов рефакторинга, иллюстрированный удивительными примерами. Определенно рекомендую прочитать книгу всем, кто хочет узнать больше о рефакторинге.
Первая глава представляет собой пример рефакторинга в действии. Он оправдывает предпринятые действия и разделяет множество полезных эмпирических правил.
1. Стремитесь принять перемены
Идея о том, что программное обеспечение, которое мы кодируем, является динамическим, подразумевает неявную необходимость изменений.
Чтобы легко применить следующее изменение, нам сначала нужна хорошая структура.
Рефакторинг направлен на улучшение структуры кода без ущерба для какой-либо наблюдаемой функциональности.
2. Перед рефакторингом убедитесь, что у вас достаточно тестов
При рефакторинге кода мы хотим убедиться, что программное обеспечение продолжает работать должным образом. Лучший способ добиться этого — с помощью хорошего набора тестов.
Тесты гарантируют, что независимо от того, что мы изменяем, функциональность остается неизменной. Мы должны убедиться, что наши тесты охватывают области, которые мы затрагиваем во время рефакторинга.
Если они этого не сделают, мы должны остановиться сейчас и начать добавлять эти тесты, даже не начав переименовывать один метод.
3. Рефакторинг небольшими шагами
Рефакторинг может что-то сломать, поэтому мы сначала написали тесты, верно? Верно? Хорошо. Мы должны вносить изменения как можно меньшими шагами и тестировать эти изменения.
Таким образом, мы знаем, что и когда мы напутали, и нам легче вернуться, так как наш шаг был маленьким.
4. Имейте систему: рефакторинг, тестирование, фиксация
Как бы мы ни были осторожны, наличие системы при рефакторинге поможет в этом процессе.
Когда вы проводите рефакторинг, вы проводите рефакторинг небольшими шагами. Вы тестируете свои изменения. А затем вы фиксируете это изменение в своей любимой системе контроля версий. Теперь у вас есть четкая история проверенных изменений! Благодаря этому процессу вы можете:
- Вернитесь к любому из этих коммитов со 100% уверенностью,
- Остановитесь, когда захотите, и отпустите любую фиксацию, и это будет улучшением, и,
- Вы можете раздавить эти крошечные коммиты в более крупные и более значимые коммиты для красивой истории!
5. Сначала рефакторинг, затем расширение
Рефакторинг перед добавлением новой функциональности поможет мыслительному процессу. И оставить кодовую базу лучше, чем вы ее нашли, — это бонус!
6. Используйте описательные имена при переименовании
Переименование — ключевой метод рефакторинга. Переименование переменных, переименование методов, переименование классов... Целью переименования должно быть использование описательных имен, которые экономят наше время.
Хорошее имя для переменной избавляет нас от необходимости читать, как она сюда попала, чтобы понять, какое значение она содержит. Хорошее имя для метода избавляет нас от чтения всей его реализации, чтобы понять, что он делает. Хорошее имя для класса избавляет нас от необходимости читать его целиком, чтобы понять его ответственность.
Трата большого количества времени и усилий на выбор имени лежит в основе рефакторинга. Иначе какой смысл было бы разбивать большой метод, если бы нам все равно приходилось читать более мелкие?
7. Следите за производительностью при рефакторинге
Производительность может пострадать в процессе рефакторинга. Даже если это и происходит, то обычно в небольших масштабах без значительных потерь. Но это хорошая привычка — учитывать возможные точки снижения производительности.
После завершения рефакторинга мы должны просмотреть эти моменты и настроить производительность. Его будет легче настраивать, так как кодовая база будет иметь лучшую структуру в конце рефакторинга.
Первоначально опубликовано на https://recepinanc.com
