В Fashinza мы уделяем большое внимание написанию чистого кода. Для этого у нас есть строгие процедуры проверки PR и утверждения. Это очень важно, поскольку помогает разработчикам эффективно читать, поддерживать и улучшать код. Так было не всегда, поскольку основной задачей было выпустить новые функции как можно раньше. Мы осознали проблему с этим не так давно; именно тогда мы решили провести рефакторинг нашей кодовой базы.
Но что такое рефакторинг кода и как мы узнаем, что он нам нужен, и как к нему подступиться? Давайте посмотрим.

Что такое рефакторинг кода?

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

Существует множество причин, по которым может потребоваться рефакторинг вашего кода; они включают, но не ограничиваются:

  • Грязный код в сочетании со сжатыми сроками.
  • Добавление последней функции в проект прямо перед его выпуском.
  • Недостаточное внимание к качеству кода и технологиям и больше внимания к выпускам функций.

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

Откуда мы знаем, что нам это нужно?

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

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

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

То же самое произошло с нами в Fashinza, и мы решили провести рефакторинг нашей кодовой базы.

Что мы сделали?

Наш основной технологический стек на фронтенде — это ReactJS в сочетании с Redux. Мы предприняли несколько шагов для рефакторинга кодовой базы внешнего интерфейса:

  • Во-первых, мы начали следовать руководствам по стилю, Linting и стандартам кода и правилам. Например, мы исправили способ сортировки импорта, начали использовать специальный регистр для переменных, имен функций и классов и т. д.
  • Затем мы отказались от неопрятных компонентов, основанных на классах, и переключились на функциональные компоненты, чтобы использовать преимущества хуков. Дошло до того, что большинство наших компонентов состояло из более чем 300 строк кода, и когда мы пытались добавить новый функционал или улучшить существующий, то ломалось что-то еще. Переход к функциональным компонентам помог нам значительно сократить код. Например, давайте посмотрим на разницу в этом простом компоненте:

Теперь сравните его с рефакторингом и посмотрите, насколько чище он выглядит.

  • Логика рендеринга и повторного рендеринга компонентов была написана в методах жизненного цикла на основе классов: componentDidMount и componentDidUpdate [Код A:строки 8–21]. Преобразование этого в функциональный хук useEffect помогло значительно упростить логику [Код B: строки 11–13].
  • Кроме того, вместо подключения к redux через mapStateToProps mapDispatchToProps мы использовали хуки useSelector и useDispatch соответственно.
  • Внесение этих изменений помогло нам сократить длину кода более чем на 50%.
  • Мы также начали использовать TypeScript, это помогло разработчикам понять типы данных и интерфейсы компонентов и функций, даже не запуская код. Когда мы начали использовать TS, производительность настолько возросла, что заслуживает отдельной статьи.
  • Мы начали правильно использовать git! Мы вносили так много изменений с такой скоростью, что компоненты, которые мы создавали, заменялись новыми еженедельно. Мы не решались удалять старый код, опасаясь, что он может быть использован снова в будущем. Это произошло так часто, что наша файловая структура стала выглядеть так:
components
   > AddOrderOld
   > AddOrderNew
   > AddOrderNewer

Мы решили эту проблему, правильно используя git, с допустимыми именами веток, заголовками PR, сообщениями коммитов, метками и т. д.

  • Мы внедрили некоторые передовые методы по всему проекту. Это включало использование styled-components для написания наших стилей вместо использования SASS. Это помогло нам избежать конфликтующих имен классов во всем проекте, а также значительно упростить взаимодействие между компонентами и их стилем.

Оглядываясь назад, мы внесли много изменений в наш репозиторий за длительный период времени. Рефакторинг кода — это не разовый процесс, а непрерывный процесс, который можно выполнять параллельно с созданием новых функций. Мы по-прежнему активно рефакторим нашу старую кодовую базу, и нам удалось перенести 45 % кода на TypeScript. Мы делаем то же самое и с серверной кодовой базой, представляя шаблоны проектирования, тестовые примеры, документацию по API и т. д.

TL;DR

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