Эффективный рефакторинг: часть 2

Составление плана

Это вторая часть из 4 частей, посвященных эффективному рефакторингу.

Фаза планирования

Если вы не планируете, вы планируете потерпеть неудачу.

Бенджамин Франклин (предположительно) сказал это. После того, как вы решили провести рефакторинг приложения, вашим первым инстинктом будет начать копаться в коде и очищать его. Однако без плана вам почти гарантирована катастрофа.

Вы даже не захотите трогать код, пока не определитесь, что нужно сделать, и что можно сделать в рамках доступного времени и бюджета. Смысл рефакторинга - принести пользу команде и максимизировать ценность кода. Если некоторые части кода немного запутаны, но функциональны, нет особого смысла в их рефакторинге. Мы обсудим расстановку приоритетов позже, но, по крайней мере, вы должны заранее определить потенциальную ценность.

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

Выберите инструмент управления проектами

Независимо от объема рефакторинга вам понадобится инструмент для отслеживания вашего прогресса. Я большой поклонник Trello. Его стиль управления проектами Канбан хорошо подходит для подобных проектов, но используйте любой удобный инструмент. Вам понадобится инструмент, который позволит вам упорядочивать и группировать задачи с возможностью добавления комментариев и описаний. Возможность добавлять вложения и создавать ярлыки / теги - тоже полезные функции, но они не обязательны.

Для своего проекта я создал доску Trello со следующими названиями списков для отслеживания задач:

  • Отставание
  • Следующий
  • В ходе выполнения
  • Запрос на вытягивание
  • Закрыто

Я также создал метки, чтобы указать, включает ли задача компонент React, элемент Redux (то есть действия, редукторы или селекторы) или аспект конфигурации приложения. Если вы такой же визуальный человек, как я, добавление цветных меток дает возможность быстро определить характер задачи, не читая заголовок или описание. Например, я создал задачу обновить webpack с 1.0 до 3.0 и применил метку Configuration определенного цвета, чтобы быстро идентифицировать ее на доске. Теперь, когда у вас настроена система управления проектами, пора начать разбивать работу на управляемые части.

Найдите логические контексты

Если кодовая база большая, может быть сложно определить, как действовать дальше. Вместо того, чтобы думать о сотнях задач, которые необходимо добавить в план проекта, более эффективно разбить приложение на модули или контексты. Контексты представляют собой участки кода, которые могут относиться к определенному бизнес-объекту или аспекту конфигурации приложения. Этот процесс может быть сложным, особенно при неорганизованной кодовой базе. Но даже грубая поломка приведет вас на верный путь. Копание и определение того, как вы можете разделить вещи, дает дополнительное преимущество, помогая вам лучше познакомиться с кодовой базой.

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

  • Пациенты
  • Назначения
  • Навигация
  • Стоматологические записи
  • Управление пользователями

Сложная часть здесь - получить правильную детализацию. Для приложения, над которым я работал, я определил контексты на основе вызовов API и существующих редукторов Redux. В итоге я получил контекст пользователя, контекст суперпользователя (для административных действий), контекст приложения (для состояния пользовательского интерфейса) и несколько другие.

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

Создать задачи

Вам необходимо создать задачи с четко определенным объемом. Подумайте об объеме с точки зрения запросов на вытягивание. Вы не хотите отправлять PR с 5 000 строками изменений кода, но отправка 5 000 PR с 2 изменениями так же неэффективна.

Например, одной из целей моего проекта рефакторинга был переход от фреймворка Foundation к Semantic UI React и реализация Модулей CSS. Изначально я создавал одну задачу, чтобы представить это изменение, пока не осознал, какой объем работы это повлечет за собой.

Требовалось обновить почти 100 компонентов React. Однако я не хотел создавать в Trello 100 задач для представления каждого отдельного компонента. В этой ситуации мне пригодились определенные мной контексты. Во-первых, я создал задачи по рефакторингу компонентов контейнера, подключенных к Redux, в каждом контексте. Затем я просмотрел общий каталог /components и сгруппировал их по категориям (элементы управления формы, диаграммы и т. Д.). Наконец, я создал отдельные задачи для рефакторинга каждой группы общих компонентов. Вот скриншот моей доски с некоторыми примерами:

Вам также необходимо учитывать последствия ваших изменений, нарушающих работу приложения. Если вам нужно вернуть его к более старой версии, действительно ли вам нужно копаться в массовом PR, чтобы выяснить, что вызвало букашка? Я допустил эту ошибку только один раз, и это было невероятно неприятно. В итоге я просто отменил большинство своих изменений и попробовал снова с меньшими кусками.

Заказ Задач (если хотите)

Если вы хотите установить критерии для расстановки приоритетов или упорядочения задач, решать вам. Если вы установили четко определенный объем для каждой задачи, не имеет значения, в каком порядке вы их выполняете. Я имел тенденцию работать над группами задач, связанных с определенными функциями, такими как элементы Redux или управление API, но это не было специально запланировано. Я бы порекомендовал заняться некоторыми низко висящими фруктами (задачами с низким уровнем усилий и высокой отдачей), когда вы только начинаете, чтобы поддерживать свою мотивацию.

Держите свой план в актуальном состоянии

Поймите и примите тот факт, что вы не получите 100% правильное планирование, когда впервые составите его. Вы могли сделать некоторые предположения относительно кода, когда впервые сформулировали план, который оказался неверным, когда вы начали копаться в нем. Измените свой курс, но не позволяйте своему плану устаревать, обязательно обновите его и задокументируйте причины изменения. Если вы на ходу выполняете задачу рефакторинга, которой нет в плане, добавьте ее в план и отметьте как выполненную. Я знаю, что это звучит утомительно, но в конце концов окупится.

Заворачивать

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