В этой статье хочу затронуть актуальную и так любимую разработчиками тему рефакторинга кода.
Наверняка вы сталкивались с таким термином или даже применяли на практике. Рекомендую к прочтению одноименный труд Мартина Фаулера, кстати.
Лично я очень люблю рефакторинг, однако у меня особое к нему отношение.
На мой взгляд, выделять специально на него время имеет смысл только тогда, когда нужно разобрать какой-то легаси проект, либо вы впервые сталкиваетесь с проектом и видите объективные причины на работу с кодовой базой.
Весь остальной рефакторинг обязательно должен быть по ходу работы, но уже в формате «правила Бойскаута». Упустить своевременную корректировку архитектуры проекта чревато повышением количества багов и существенным снижением скорости работы.
В итоге все сведется к очередному выделению времени на рефакторинг. Но на мой взгляд, это расточительно для бизнеса. Понятно, что рефакторинг призван увеличить скорость разработки и упростить работу с кодом, но если не следить за кодом, то итерации по рефакторингу войдут в привычку, и в общем зачете никакой скорости не получится достичь. Бизнес от такого процесса будет тратить деньги впустую, а слово «рефакторинг» вскоре вызовет оскомину и отторжение.
👆 Короче, рефакторинг должен быть, но о нем никто не должен слышать. Уверен, все будут довольны.
ОК, а что делать?
Что делать? И как не попасть в проектный «запланированный» рефакторинг?
Предлагаю использовать такой процесс по работе с кодом.
Возьмем некоторый проект N, например это легаси, который нужно вылечить. Скорее всего, архитектура в нем отсутствует.
Представим весь этот код как неупорядоченный объем разнородных компонентов. Вернее компонентов скорее всего в нем нет, но будем понимать под ними потенциальные компоненты.
Этап 1
Первым делом нужно просмотреть код и попытаться понять задумку автора. Она же должна быть 🤔
Дальше нужно ухватиться за какую-то торчащую нить и начать тянуть. Да, именно тянуть. На этом этапе необходимо растянуть весь проект, сделав его как можно проще и прямолинейней.
⚠️ Остерегайся ошибки! Обычно разработчики с недостаточным опытом, едва начав работу, пытаются в коде сделать «правильно» и начинают создавать абстракции, толком не вникнув в предметную область и в функциональность кода. Это чревато возникновением God-objects, и обилием условных конструкций в них и не только в них.
✅ Совет. Соблюдайте дисциплину и продолжайте распутывать код, пока не получите, скажем так, его Flat-вариант.
Этап 2
Отлично. Мы получили работающий код, написанный максимально прямолинейно, избегая абстракций. Теперь можно посмотреть паттерны в коде и начать формировать компонентную архитектуру. Скорее всего, в процессе вы уже увидите что можно сделать, но, опять же, не торопитесь! Вы точно успеете сделать «правильно», но в свое время.
⚠️ Остерегайся ошибки! Опять же. Этот этап — отличное время для начала создания компонентов архитектуры, или shared-компонентов, однако ключевое слово — «начало», а не одно единственное. Не торопитесь создать сразу все.
✅ Совет. Создайте первое семейство компонентов и посмотрите как все работает. Убедившись в удачности решения — двигайтесь дальше.
Этап 3
Переход к крейсерской работе. Вот на этом этапе уже нужно перейти в «режим Бойскаута».
Притронулись к фрагменту кода — сделайте его лучше:
- примените новый компонент архитектуры, который предназначен для решения задачи
- примените shared-компонент.
- удалите старые комментарии.
- пересмотрите нейминг, задайте более говорящие названия переменным и функциям.
- пересмотрите устройство работы бизнес-логики.
- создайте заметку в микробеклог (об этом позже).
⚠️ Остерегайся ошибки! Не игнорируйте реализацию фрагментов кода, с которыми работаете. В первую очередь, обращайте внимание на нейминг. Нейминг — основа чистого кода.
✅ Совет. Обязательно делайте любой код, к которому прикасаетесь, лучше.
Этап 4
Наслаждайтесь в работе с кодом. Уверяю, соблюдая дисциплину и производя своевременные изменения вы очень скоро получите чистую кодовую базу. Понятно, что и решения должны быть удачными сами по себе 😄, но это приходит с опытом. Здесь работает насмотренность и объем выработанных часов.
⚠️ Остерегайся ошибки! Если вы ощущаете дискомфорт или усталость при работе с кодом, значит в нем есть проблемы. Их нужно решить. Решите сами, или попросите помощи у более опытных коллег.
✅ Совет. Работайте с кодом с удовольствием. В таком случае, вы не будете уставать от работы.
Резюме
Не торопитесь и не бойтесь писать простой прямолинейный код. Хорошие решения придут в свое время. Пока это время не наступило — не усложняйте. Помните про принцип KISS, и принцип Бритва Оккама.
Основной фактор здоровья кодовой базы — комфорт при работе с ней, вдохновение.
Приятного кодинга!
Релевантные статьи:
Про работу с абстракциями: Абстракции. Во сне и наяву.
Про архитектуру: Архитектура.
—
Поставь лайк, если статья понравилась 🙏
Подписывайся на мой канал в Telegram: https://t.me/cantfailcode