Хотя большая часть ее посвящена методам рефакторинга, эта замечательная книга М. Фаулера включает в себя пару очень хорошо структурированных глав, которые помогли мне понять жизненный цикл программного обеспечения и то, как создавать элегантные, надежные и долговечные приложения.
В этом и следующем постах я представлю свои личные заметки, в основном для того, чтобы не потерять их в какой-нибудь случайной папке, но также надеюсь, что они кому-нибудь пригодятся и побудят прочитать эту замечательную работу. Они относятся к главе 2
Определение рефакторинга
Рефакторинг: изменение внутренней структуры программного обеспечения, чтобы упростить его понимание и удешевить модификацию без изменения его наблюдаемого поведения.
Рефакторинг: реструктуризация программного обеспечения путем применения ряда рефакторингов.
Рефакторинг:
— применение небольших шагов, сохраняющих поведение
— большие изменения приходят через последовательность этих шагов
— код должен работать всегда!
Это кажется медленным и неэффективным, но это не так
– крошечные шаги очень хорошо складываются
– без отладки
Две шляпы
При использовании рефакторинга для разработки нового программного обеспечения вы должны разделить время между двумя разными действиями:
— добавление функциональности: не изменяйте существующее программное обеспечение, просто добавляйте новые возможности< br /> — рефакторинг: не добавлять функционал, просто реструктурировать код
Помните о том, какую шляпу вы носите, и о тонких различиях, которые влияют на то, как вы программируете.
Почему мы должны проводить рефакторинг?
Рефакторинг улучшает дизайн программного обеспечения
— без рефакторинга внутренняя структура кода имеет тенденцию разрушаться
— потеря структуры кода кумулятивный эффект
— плохо спроектированный код обычно требует больше кода для того же самого объекта
— дублирование
— чем больше кода, тем труднее его корректно изменить
Рефакторинг упрощает понимание программного обеспечения
— ленитесь! Это включает в себя никогда не помнить ничего о коде, который вы пишете
— организуйте код так, чтобы в будущем вы, читая код, могли понять, что он делает, ничего не зная о том, как он запрограммирован.
Рефакторинг помогает находить ошибки
— рефакторинг означает глубокую работу над тем, что делает код, а это требует глубокого понимания, позволяющего найти ошибки
— проясняя структуру кода, легче обнаруживать ошибки
«Я не великий программист; Я просто хороший программист с отличными привычками»
Рефакторинг помогает вам программировать быстрее
— каждая новая функция требует понимания того, как вписать ее в существующую кодовую базу
— хорошо организованный код упрощает эту задачу
— плохой код: патчи перекрывают патчи, так что это упражнение археологии, чтобы выяснить, как все работает. Это бремя замедляет добавление новых функций
Когда следует провести рефакторинг
Когда вы делаете что-то в первый раз, вы просто делаете это. Когда вы делаете что-то подобное во второй раз, вы вздрагиваете от дублирования, но все равно делаете дублирование. В третий раз, когда вы делаете что-то подобное, вы проводите рефакторинг.
— бейсбол: три удара, затем рефакторинг
Подготовительный рефакторинг: упрощение добавления функции
— лучшее время для рефакторинга — перед добавлением новой функции.
— посмотрите на свой код, посмотрите, какое изменение дизайна упростит добавление этой функции. Выполните это изменение с помощью рефакторинга, а затем добавьте его
— то же самое с отладкой. Исправьте ошибку, затем почистите код
Полноценный рефакторинг: сделать код более понятным
— прежде чем вносить какие-то изменения в код, нужно понять, что он делает
— плохо организованный код усложняет задачу
— путем рефакторинга, начиная с небольших изменений а затем большие, вы действительно узнаете это
Рефакторинг с уборкой мусора
— когда вы просматриваете код и видите что-то плохо запрограммированное, либо измените его немедленно, либо оставьте примечание и сделайте это позже
— рефакторинг хорош тем, что небольшие шаги составляют , даже совсем небольшое улучшение кода время от времени приводит к приятному результату через какое-то время
Плановый и оппортунистический рефакторинг
— следует ли проводить рефакторинг по плану или пока вы работаете над чем-то другим? Автор предпочитает второй подход
«Для каждого желаемого изменения сделайте его легким (предупреждение: это может быть сложно), затем сделайте легкое изменение»
Долгосрочный рефакторинг
— как вы справляетесь с рефакторингом, который занимает недели? Шаг за шагом
Рефакторинг в обзоре кода
— рефакторинг чужого кода во время его просмотра — отличный способ понять, что он делает
— это приводит к лучшим предложениям
— логический вывод — парное программирование
Что вы скажете своему руководителю?
— хороший руководитель: «Я занимаюсь рефакторингом»
— плохой руководитель, который считает это пустой тратой времени: врать и все равно делать
Шен, не рефакторинг
— старый хорошо работающий код, который можно рассматривать как API
— вещи такие уродливые, что лучше их переписать
Проблемы с рефакторингом
Замедление новых разработок
— помните: вся цель рефакторинга состоит в том, чтобы ускорить работу
— ситуации, когда вы видите большой рефакторинг, который нужно сделать, но новая функция, которую вы хотите добавить, настолько мала что вы все равно добавите его и оставите более крупный рефакторинг в покое.
— опыт авторов: обычно проблема в том, чтобы сделать слишком мало рефакторинга, а не слишком много
Владение кодом
— проблема 1: другие модули/команды используют ваш код. Правило здесь — не ломать API
— проблема 2: для некоторых организаций фрагменты кода принадлежат кому-то/команде, и вы не можете их трогать. Правило здесь (мое) - убежать от этой организации
Ветки
— проблемы со слиянием и прочее.
— Решение: Непрерывная интеграция
Тестирование
— «рефакторинг не меняет наблюдаемое поведение программы»
— плохое тестирование —› плохое наблюдаемое поведение —› сложный рефакторинг
— Правило здесь: создайте новые тесты, затем рефакторинг.
Устаревший код
— не трогайте
Базы данных
— тоже не трогаем
Рефакторинг, архитектура и YAGNI
Архитектура программного обеспечения:
— Оригинальная идея: сначала спланировать идеальную архитектуру, а затем наполнить ее кодом
— Подход с рефакторингом: сформируйте хорошо спроектированный код, который может изящно реагировать на меняющиеся потребности
Основная проблема: вы не можете понять требования к программному обеспечению на ранней стадии
— иногда только после того, как поработаете с кодом какое-то время и увидите его влияние на вашу работу.
Подход старой школы: сделать программное обеспечение гибким
— функция со многими параметрами, которая может адаптироваться к предсказанным вами требованиям
— сложная архитектура с интерфейсами и т.п.
Подход к рефакторингу: вместо того, чтобы строить догадки о том, какая гибкость вам понадобится в будущем, создавайте программное обеспечение, которое решает только текущие потребности, с превосходным дизайном. Пусть появятся новые потребности, реорганизуйте свое программное обеспечение, чтобы интегрировать их.
«ЯГНИ: тебе это не понадобится»
С помощью рефакторинга включите архитектуру и дизайн в процесс разработки
Рефакторинг и более широкий процесс разработки программного обеспечения
CI/CD для победы
Рефакторинг и производительность
Факты:
— Люди плохо умеют предсказывать производительность
— Люди еще хуже умеют определять, где их приложение использует большую часть времени выполнения
Не беспокойтесь о производительности: вы получите беспорядочный код с низкой производительностью.
Вместо этого:
— беспокойтесь о чистом и понятном коде
— используйте профилировщик, чтобы увидеть, где ваш код занимает слишком много времени выполнения
— затем оптимизируйте это
Рефакторинг и чистый код хороши тем, что
— нет дублирования кода
— легче понять вывод профилировщика
— проще оптимизировать четкие, четко определенные функции