Рефакторинг на максималках

Привет! 👋

Меня зовут Саша Беспоясов, я работаю консультантом в 0+X.
Пишу код больше 10 лет. Веду технический блог, пишу о разработке.

Сегодня я расскажу о том, как эффективно рефакторить код и какие из программистских базвордов для этого понадобятся.

Дисклеймер

👀 Восприятие искажено.
🦄 Подойдёт не всем.
📦 Нужно не каждому проекту.
🤷 Могу быть не прав.
🧠 Перед применением подумать и обсудить.

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

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

В чём польза разработчикам

Рефакторинг требует усилий, но взамен мы получаем:

🔦 Обнаружаемость — быстрее находим нужные куски кода.
🤔 Однозначность — меньше разночтений в команде.
🧬 Изменяемость — проще менять, добавлять и удалять.
🛠 Отлаживаемость — быстрее ищем и правим баги.

В чём польза бизнесу

🔦 Обнаружаемость — быстрее фиксы, меньше разочарованных юзеров.
⚙️ Расширяемость — новые фичи раньше конкурентов.
🎛 Подконтрольность — меньше чёрных лебедей.
🎟 Нет текучки кадров — от приятного кода разработчики не бегут.
🤗 Добро-пожаловать-на-борто-пригодность — дешевле онбординг.

«Плохой» код

Характеристики субъективны, их сложно измерить напрямую. Но все они отсылают к тому, «насколько код читаем».

...Если постараться, то измерить характеристики, конечно, можно, но об этом позже 🤫

Костыли для определения «плохого» кода

Когнитивные костыли, которые говорят, как узнать «плохой» код.

📖 Сложно читать — длинно, запутанно, трудно держать в голове.
😬 Тяжело менять — водопад изменений, перепроверка всего подряд.
🧪 Трудно тестировать — сложная инфраструктура, лишние сущности.

Запахи кода

Иногда достаточно посмотреть на список запахов, найти подходящий и использовать рецепт против него.

Программистские словечки™

Separation of Concerns
Coupling & Cohesion
Declarative Approach
Abstraction Layers
Functional Pipeline
Functional Core / Imperative Shell
Data Structures
Modelling for Transformations
12 Factor Apps
Hey, I'm on the TV!
Unrepresentable Invalid Data
Architecture Layers
Dependency Direction
Tests
Command-Query Separation
Immutability

💩 → 🍬

От простого к сложному

👔 Форматирование.
🦄 Возможности языка и среды.
🏷 Имена сущностей.
👯 Дедупликация и функции.
🌈 Абстракция и функции.
🍴 Разделение ответственности.
⏰ Ранний return.

🍩 Функциональный пайплайн.
🫥 Ссылочная прозрачность.
🔗 Зацепление и связность.
🏛 Абстракции и архитектура.
🧭 Направление зависимостей.
🤖 Моделирование трансформаций.
👀 Декларативность.

Прежде, чем начать

🧑‍💻 Изучить существующий код.
🖼 Определить рамки изменений.
🧪 Покрыть существующий код тестами.

Не забывать

🐾 Двигаться маленькими шагами.
1️⃣ Одна техника за раз.
🙅 Никаких фич и багфиксов.
🧪 Аккуратнее с тестами.
🪚 Работоспособность на каждом шаге.

Все примеры на Гитхабе!

Изучите историю коммитов. В ней я показал, как применять разные техники и использовать словечки™, чтобы находить проблемные места.

Пример сообщения о коммите, где рассказано, что и зачем сделано с кодом

Форматирование

Линтеры

Как минимум помогут найти «мёртвый» код и неиспользуемые переменные.

Линтер указывает на неиспользуемую переменную

Возможности языка

Тернарник иногда можно заменить на Math.min

Сериализация на FormData работает также, но занимает меньше места и лучше расширяется

Возможности браузера

Можно избавиться от лишнего кода, если использовать возможности языка

Возможности среды

Используйте автоматизированные средства рефакторинга

...Но следите за изменениями, которые они делают

Короткие имена и сокращения

Избегайте сокращений, в них слишком мало контекста

Чрезмерно длинные имена

Не перегружайте имя лишними подробностями

Вариант именования

Паттерн A/HC/LC Pattern предполагает использовать максимум два контекста на одну сущность

Следить за контекстом

Если информация доступна из близкого контекста, её можно опустить. Но лучше с этим быть аккуратнее.

Если информация доступна из контекста, её можно опустить

Одинаковые имена у разных сущностей

Избегайте одинаковых имён для разных сущностей

Повсеместный язык

Используйте понятия из предметной области

Функции и дедупликация

Выделяйте повторяющиеся действия в функции

Функции и абстракция

Сложность не исчезает

Но с ней проще справляться.

Со сложностью проще справляться, когда детали реализации абстрагированы за понятным названием

Всё как в жизни

Абстрагирование помогает работать со сложными концепциями

Абстрагируйте детали

Разделение ответственности

Функциональный пайплайн

Фокусируйтесь на преобразованиях данных. Считайте их состояния результатами бизнес-событий.

Фокусируйтесь на состояниях и преобразованиях данных как результатах бизнес-событий

Разделяем состояния

Если выделить этапы жизненного цикла заказа, станет понятно, что тут на самом деле две функции

Добавляем состояния

В функциональный пайплайн проще добавлять новые преобразования

Условия

🫓 «Плоские» условия и булева алгебра.
⏰ Ранний return.
🔬 Инверсия контроля и предикаты.
🥷 Null-объекты и Option-типы.
🗿 “Immutable by default” и “Stateless by default”.

Плоские условия

Выносите повторяющиеся условия в переменные.

Закономерности упрощайте правилами булевой логики.

!(a && b) === !a || !b
!(a || b) === !a && !b

Выносите повторяющиеся условия в переменные — это поможет увидеть закономерности

Ранний `return`

Предикаты

Immutable by default

Иммутабельность даёт уверенность в том, что в переменной содержится, исключает внезапные её изменения, уменьшает область её поиска

Ссылочная прозрачность

Чистые функции — это отличный пример абстракции. Если вызов функции можно заменить её результатом, то мы можем «абстрагировать» её детали реализации.

Predicates abstract the details of verification, leaving the code declarative

Сайд-эффекты и обработка ошибок

🥪 Почипо-бутерброд.
🎯 Разделение команд и запросов.
📦 Result-контейнеры.
🚧 Абстрагирование «служебного» кода.

Почипо-бутерброд

Почипо, потому что:

побочный эффект.
чистые преобразования.
побочный эффект.

Сайд-эффекты окружают преобразования из чистых функций

Почипо-группирование

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

Группировка по методу почипо помогает собрать весь важный код в одном месте

Команды и запросы, CQS

Избегайте смешения сайд-эффектов и возврата значения, применяйте command-query separation, CQS

«Невыразимые» невалидные состояния

Системы типов помогут подсветить проблемы с инкапсуляцией, невалидными состояниями данных и нарушением CQS.

Если вы используете статически-типизированный язык, постарайтесь сделать невалидные состояния «запрещёнными», чтобы их было невозможно получить «по ошибке»

Ошибки

🧑‍🚀 Доменные — происходят в реальности бизнес-процессов.
🧑‍💻 Инфраструктурные — вызваны техническими деталями, но ожидаемы.
😱 Исключения — от которых нельзя восстановиться к нормальной работе.

`Result`-контейнеры

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

Абстрагируйте «служебный» код

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

Проблемы слабой архитектуры

Функция требует неадекватно много данных.
Модули знают друг о друге чрезмерно много.
Сторонние библиотеки диктуют, как писать код приложения.
React special: куча логики внутри кода компонента.

Когда модули сильно зацеплены, программу сложно расширять

Слои и направление зависимостей

Бизнес-правила не должны зависеть от внешних сервисов

В коде мы реализуем такое поведение с помощью адаптеров

Адаптеры и тестируемость

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

Разделение UI и логики

Компонент, в котором намешано всё на свете сложно понимать, тестировать и изменять.

Декларативность

Рассказывайте что код должен делать, а не как.

Абстрагирование помогает коду быть декларативным

Ошибки императивности

В декларативном стиле тяжелее допустить ошибку

Иногда не прокатывает 🙄

// 🐌
array.map(x => x > 0.5);

// 🐇
for (const x of array) {
    x > 0.5;
}

«Сколько времени нужно, чтобы...»

🔍 Search — найти нужное место в коде.
✍️ Write — написать новую фичу с тестами.
😊 Agree — разработчики перестали спорить, хороший ли код.
📖 Read — прочесть и понять, что делает кусок кода.
🛠 Modify — изменить код в соответствии с новыми требованиями.
🏃 Execute — выполнить / собрать / задеплоить кусок кода.
🐛 Debug — найти и отладить баг.

Хот-тейки

💦 Следите за «протёкшими абстракциями».
🦆 Различайте «откровенное дублирование» и недостаток информации.
🧬 Выделяйте жизненный цикл доменных сущностей.
📆 Проектируйте от бизнес-событий и трансформаций данных.
📏 Старайтесь строить код линейно.
🗿 Используйте иммутабельность и декларативность по умолчанию.
🥪 Держите сайд-эффекты отдельно от логики.
🧭 Направляйте зависимости к домену.