Хотя большая часть ее посвящена методам рефакторинга, эта замечательная книга М. Фаулера включает в себя пару очень хорошо структурированных глав, которые помогли мне понять жизненный цикл программного обеспечения и то, как создавать элегантные, надежные и долговечные приложения.

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

Определение рефакторинга

Рефакторинг: изменение внутренней структуры программного обеспечения, чтобы упростить его понимание и удешевить модификацию без изменения его наблюдаемого поведения.

Рефакторинг: реструктуризация программного обеспечения путем применения ряда рефакторингов.

Рефакторинг:
— применение небольших шагов, сохраняющих поведение
— большие изменения приходят через последовательность этих шагов
— код должен работать всегда!

Это кажется медленным и неэффективным, но это не так
 – крошечные шаги очень хорошо складываются
 – без отладки

Две шляпы
При использовании рефакторинга для разработки нового программного обеспечения вы должны разделить время между двумя разными действиями:
— добавление функциональности: не изменяйте существующее программное обеспечение, просто добавляйте новые возможности< br /> — рефакторинг: не добавлять функционал, просто реструктурировать код

Помните о том, какую шляпу вы носите, и о тонких различиях, которые влияют на то, как вы программируете.

Почему мы должны проводить рефакторинг?
Рефакторинг улучшает дизайн программного обеспечения
— без рефакторинга внутренняя структура кода имеет тенденцию разрушаться
— потеря структуры кода кумулятивный эффект
— плохо спроектированный код обычно требует больше кода для того же самого объекта
— дублирование
— чем больше кода, тем труднее его корректно изменить

Рефакторинг упрощает понимание программного обеспечения
— ленитесь! Это включает в себя никогда не помнить ничего о коде, который вы пишете
— организуйте код так, чтобы в будущем вы, читая код, могли понять, что он делает, ничего не зная о том, как он запрограммирован.

Рефакторинг помогает находить ошибки
— рефакторинг означает глубокую работу над тем, что делает код, а это требует глубокого понимания, позволяющего найти ошибки
— проясняя структуру кода, легче обнаруживать ошибки

«Я не великий программист; Я просто хороший программист с отличными привычками»

Рефакторинг помогает вам программировать быстрее
— каждая новая функция требует понимания того, как вписать ее в существующую кодовую базу
— хорошо организованный код упрощает эту задачу
— плохой код: патчи перекрывают патчи, так что это упражнение археологии, чтобы выяснить, как все работает. Это бремя замедляет добавление новых функций

Когда следует провести рефакторинг

Когда вы делаете что-то в первый раз, вы просто делаете это. Когда вы делаете что-то подобное во второй раз, вы вздрагиваете от дублирования, но все равно делаете дублирование. В третий раз, когда вы делаете что-то подобное, вы проводите рефакторинг.
— бейсбол: три удара, затем рефакторинг

Подготовительный рефакторинг: упрощение добавления функции
 — лучшее время для рефакторинга — перед добавлением новой функции.
 — посмотрите на свой код, посмотрите, какое изменение дизайна упростит добавление этой функции. Выполните это изменение с помощью рефакторинга, а затем добавьте его
— то же самое с отладкой. Исправьте ошибку, затем почистите код

Полноценный рефакторинг: сделать код более понятным
— прежде чем вносить какие-то изменения в код, нужно понять, что он делает
— плохо организованный код усложняет задачу
— путем рефакторинга, начиная с небольших изменений а затем большие, вы действительно узнаете это

Рефакторинг с уборкой мусора
— когда вы просматриваете код и видите что-то плохо запрограммированное, либо измените его немедленно, либо оставьте примечание и сделайте это позже
— рефакторинг хорош тем, что небольшие шаги составляют , даже совсем небольшое улучшение кода время от времени приводит к приятному результату через какое-то время

Плановый и оппортунистический рефакторинг
— следует ли проводить рефакторинг по плану или пока вы работаете над чем-то другим? Автор предпочитает второй подход

«Для каждого желаемого изменения сделайте его легким (предупреждение: это может быть сложно), затем сделайте легкое изменение»

Долгосрочный рефакторинг
— как вы справляетесь с рефакторингом, который занимает недели? Шаг за шагом

Рефакторинг в обзоре кода
— рефакторинг чужого кода во время его просмотра — отличный способ понять, что он делает
— это приводит к лучшим предложениям
— логический вывод — парное программирование

Что вы скажете своему руководителю?
— хороший руководитель: «Я занимаюсь рефакторингом»
— плохой руководитель, который считает это пустой тратой времени: врать и все равно делать

Шен, не рефакторинг
— старый хорошо работающий код, который можно рассматривать как API
— вещи такие уродливые, что лучше их переписать

Проблемы с рефакторингом

Замедление новых разработок
— помните: вся цель рефакторинга состоит в том, чтобы ускорить работу
— ситуации, когда вы видите большой рефакторинг, который нужно сделать, но новая функция, которую вы хотите добавить, настолько мала что вы все равно добавите его и оставите более крупный рефакторинг в покое.
— опыт авторов: обычно проблема в том, чтобы сделать слишком мало рефакторинга, а не слишком много

Владение кодом
— проблема 1: другие модули/команды используют ваш код. Правило здесь — не ломать API
— проблема 2: для некоторых организаций фрагменты кода принадлежат кому-то/команде, и вы не можете их трогать. Правило здесь (мое) - убежать от этой организации

Ветки
— проблемы со слиянием и прочее.
— Решение: Непрерывная интеграция

Тестирование
— «рефакторинг не меняет наблюдаемое поведение программы»
— плохое тестирование —› плохое наблюдаемое поведение —› сложный рефакторинг
— Правило здесь: создайте новые тесты, затем рефакторинг.

Устаревший код
— не трогайте

Базы данных
— тоже не трогаем

Рефакторинг, архитектура и YAGNI

Архитектура программного обеспечения:
— Оригинальная идея: сначала спланировать идеальную архитектуру, а затем наполнить ее кодом
— Подход с рефакторингом: сформируйте хорошо спроектированный код, который может изящно реагировать на меняющиеся потребности

Основная проблема: вы не можете понять требования к программному обеспечению на ранней стадии
— иногда только после того, как поработаете с кодом какое-то время и увидите его влияние на вашу работу.

Подход старой школы: сделать программное обеспечение гибким
— функция со многими параметрами, которая может адаптироваться к предсказанным вами требованиям
— сложная архитектура с интерфейсами и т.п.

Подход к рефакторингу: вместо того, чтобы строить догадки о том, какая гибкость вам понадобится в будущем, создавайте программное обеспечение, которое решает только текущие потребности, с превосходным дизайном. Пусть появятся новые потребности, реорганизуйте свое программное обеспечение, чтобы интегрировать их.

«ЯГНИ: тебе это не понадобится»

С помощью рефакторинга включите архитектуру и дизайн в процесс разработки

Рефакторинг и более широкий процесс разработки программного обеспечения
CI/CD для победы

Рефакторинг и производительность
Факты:
— Люди плохо умеют предсказывать производительность
— Люди еще хуже умеют определять, где их приложение использует большую часть времени выполнения

Не беспокойтесь о производительности: вы получите беспорядочный код с низкой производительностью.

Вместо этого:
— беспокойтесь о чистом и понятном коде
— используйте профилировщик, чтобы увидеть, где ваш код занимает слишком много времени выполнения
— затем оптимизируйте это

Рефакторинг и чистый код хороши тем, что
— нет дублирования кода
— легче понять вывод профилировщика
— проще оптимизировать четкие, четко определенные функции