Работая в Thoughtworks, я познакомился с концепцией Code Smells. Я нашел эту концепцию очень интересной и начал читать о ней больше. Меня больше интересовало, почему запахи кода вызывают проблемы.
В этой серии сообщений в блоге я планирую поделиться своим пониманием различных типов запахов кода, почему именно мы должны их рефакторить, какие более глубокие проблемы связаны с каждым запахом кода и как их реорганизовать на примере.
Что такое запах кода?
Этот термин был впервые введен Кентом Беком в 1990 году. Запахи кода — это поверхностные признаки, которые соответствуют более глубоким проблемам в системе. Согласно определению Мартина Фаулера, эти запахи кода не являются ошибками в программных системах, но они указывают на плохой дизайн или выбор реализации системы.
Запахи кода можно разделить на следующие категории:
- вздутия живота
- Объектно-ориентированные насильники
- расходные материалы
- Муфты
- Препятствующие изменениям
В этом посте мы обсудим один из неприятных запахов кода.
Раздутия
Все мы, возможно, сталкивались с тем, что по мере разработки программного обеспечения наш код начинает раздуваться. Раздувание — это очень большие классы, методы или фрагменты кода, с которыми трудно работать. Одним из примеров раздувания является длинный метод.
1. Длинный метод
Как следует из названия, любой метод, содержащий слишком много строк кода, является длинным методом. Но как определить это — «слишком много» строк?
Общие рекомендации говорят, что если метод выходит за пределы 10 строк, нам нужно проверить, можно ли его сократить. Я знаю, что это всего лишь рекомендация, и у разных людей могут быть разные взгляды на это. Но вместо того, чтобы вдаваться в эти дебаты, я думаю, что любой метод, который не следует принципу единой ответственности, можно назвать длинным методом.
Какую более глубокую проблему указывает метод Long?
Прежде всего, мы должны спросить себя «почему»? Почему длинный метод является проблемой? Только тогда мы поймем важность решения.
Поставляя программные решения, мы часто сталкиваемся с дилеммой: расставить приоритеты в задачах рефакторинга или просто сосредоточиться на функциональных историях, чтобы ускорить доставку. Чтобы принять лучшее решение, нам нужно понять, почему необходим конкретный рефакторинг и на какие более глубокие проблемы указывает тот или иной запах кода.
В нашем случае длинные методы указывают на нарушение принципа единой ответственности (SRP).
- Если SRP не работает, значит, метод может измениться по нескольким причинам.
- Чем длиннее метод, тем сложнее его читать и поддерживать.
- Методы с несколькими обязанностями легко сломать.
- Раздутые методы привлекают больше кода, что означает, что он имеет тенденцию раздуваться еще больше. Многие разработчики в одной команде будут работать над каким-то методом и продолжать добавлять к нему код, и постепенно метод станет слишком длинным для понимания.
Так много теории… Пришло время заняться практикой
Давайте рассмотрим пример следующего длинного метода:
Этот метод, безусловно, имеет много обязанностей. Он получает цены всех товаров, суммирует их, затем добавляет стоимость доставки, а затем применяет скидку, если таковая имеется. Наконец, он возвращает общую стоимость заказа.
На этот единственный метод может влиять несколько причин, например, всякий раз, когда изменяется бизнес-логика стоимости доставки, когда изменяется логика предложения и скидки и т. д.
Проведем рефакторинг
В 99% случаев длинный метод может быть рефакторинг с использованием техники «Извлечение метода». Мы будем использовать то же самое здесь следующим образом:
Некоторые могут спорить о результате этого рефакторинга. Чего именно мы достигли? Мы только что переместили логику из одного места в другое?
- Нет. Теперь у нас есть более короткие методы с хорошими именами. Легко назвать метод, который имеет одну ответственность.
- Кроме того, перед рефакторингом у нас было много комментариев к нашему методу, объясняющих, что делает тот или иной фрагмент логики. Теперь нам не нужны эти комментарии, потому что имена наших методов говорят сами за себя.
- Читая метод getOrderTotal, нам действительно не нужно проверять тело методов, которые он вызывает внутри,поскольку их названия объясняют цель, которой они служат.
- Короче говоря, наш код стал более читабельным и удобным в сопровождении.
Это все для этого поста. Я знаю, что отрефакторенный код может иметь некоторые другие запахи кода, которые мы еще не устранили. Кроме того, один запах можно преобразовать с помощью нескольких методов. Но обсуждать это будет слишком много для одного поста.
Я надеюсь, что это было полезно. Вы можете использовать эти знания для обнаружения и рефакторинга длинных методов в любом проекте, над которым вы работаете.
В следующем блоге мы рассмотрим другие запахи кода с примерами. Мы также попытаемся понять взаимосвязь между различными запахами кода, где это возможно.
Наслаждайтесь рефакторингом!!!
