kamyshev.code
2.16K subscribers
40 photos
565 links
Архитектура, код, софт-скиллы и всё остальное. Вопросы, пожелания, комментарии — @igorkamyshev

https://kamyshev.me
Download Telegram
​​Код протухает. С каждым днем кодовая база становится все хуже. Чтобы противодействовать этому процессу необходимо проводить рефакторинг — деятельность по улучшению кода без добавления/удаления/доработки фич. Но с этим нужно быть осторожным.

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

Цель рефакторинга — снизить цену поддержки существующего кода и написания нового.

#рефакторинг
Мудрость из книги

Рефакторинг важен. Осенью купил курс Рефакторинг.Гуру, сейчас до него добрался.

В первых разделах рассмотрены запахи плохого кода — признаки необходимости рефакторинга.

Самый распространный запах — единица кода (метод, класс, модуль) стала слишком большой.

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

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

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Еще один запах плохого кода — одержимость элементарными типами.

1. Когда деньги выражаются как float или телефонный номер как string — это проблема. Подобные значения должны быть выделены в класс, вместе с присущим ему поведением.

2. Когда константа используется для кодирования информации (например, USERADMINROLE = 1 для обозначения роли) — это проблема. Вместо этого лучше использовать разные классы.

3. Когда строковый константы выступают ключами ассоциативного массива — это проблема. Такие массивы легко заменяются DTO.

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Если параметров функции становиться больше 3-4 — случилась ошибка проектирования и ее нужно исправить.

Варианты этой проблемы:
1. Функция объединяет несколько алгоритмов. Тогда ее легко разбить на несколько функций с меньшим числом параметров.
2. Функция принимает набор связанных данных, но отдельными аргументами. В таком случае, параметры следует передавать единым аргументом — DTO.

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

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Если в нескольких местах встречаются одинаковые группы данных (например, параметры подключения к БД) — этот код, возможно, плох.

Такие группы данных нужно выносить в отдельные классы, которые будут отвечать за всю группу.

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

В хорошем коде редко встречается большое количество операторов switch и if. С такими местами нужно бороться.

Самый простой способ — изолировать их в специльной функции. Чтобы никакой внешний код не беспокоился об этом.

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

switch-if допустимы (даже необходимы) в абстрактных фабриках и фабричных методах.

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Если в дочернем классе неиспользуются методы/данные родительского — значит что-то не так. Обычно это происходит, если наследование используется только для переиспользования кода, а не отражения отношения "является". В таком случае следует заменить наследование композицией.

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

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Если в проекте существует два класса, которые делают одно и тоже, но имеют разные интерфейс — беда.

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

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Если для небольшлого изменения поведения требуется внести много правок в код — что-то пошло не так.

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

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Очень распространенная проблема — параллельные иерархии наследования.

Скорее всего, эта проблема — ошибка на этапе проектирования. Вполне вероятно, что можно свети это к одной иерархии. Если нет — подумать и найти решение.

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Если в приложении есть мертвый код — его нужно удалить.

Мертвый код может быть просто неспользуемым, или закомментированным. В любом случае от него нужно избавиться как можно скорее. Он вводит в заблуждение.

Такой код появляется или когда приложение развивалось, а чистка кода не проводилась, или когда программисты решали будущие проблемы.

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

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

Хорошая идея хранить данные и операции над ними в одном месте.

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Мудрость из книги

Один из самых опасных запахов плохого кода — знание одного класса интимных подробностей о другом.

Если вызывающий код знает не только о внешнем интерфейсе, но и о внутреннем устройстве вызываемого кода — беда. Такие структуры невозможно развивать и поддерживать.

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

Конспект интерактивного курса "Рефакторинг.Гуру".

#рефакторинг
Онлайн-курс

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

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

#рефакторинг
Массово выкидываем старый код

Aviasales уже 13 лет, в проекте много такого кода, который когда-то был написан, но сейчас уже не нужен. Последние три недели я большую часть времени занимаюсь тем, что выкидываю старый код.

Это сложная задача, в первую очередь из-за хрупкости системы. Любое твое действие может привести к поломке вообще всего. Но удаление лишнего кода — первый шаг к развязыванию зависимостей и улучшению архитектуры.

Вообще, наша глобальная цель — сделать так, чтобы в репозитории не было кода, которые не «видят» пользователи. Думаю, это достойная цель для любого проекта.

#кейс #рефакторинг