Как правило, разработчики учатся следить за логическими ошибками, случайно вносимыми в код, и защищаться от них. Такие ошибки могут варьироваться от необработанных частных случаев, до логических ошибок, которые приводят к сбою целых систем. Но меньшее внимание уделяется более тонким вопросам, которые не влияют на работу системы. Например, проблемы проектирования, которые усложняют поддержку системы и увеличивают вероятность ошибок в будущем.
Код с запашком — это сигнал о том, что код должен быть подвергнут рефакторингу для улучшения расширяемости, читаемости и поддержки. [1]
Ниже описаны некоторые наиболее распространенные запахи кода, которые при раннем обнаружении не должны вызвать трудностей при устранении:
- Длинные методы
Большая часть времени программиста тратится на чтение, а не на написание кода. Помимо того, что при чтении таких методов приходится держать много сложной логики в голове, обычно это признак того, что у метода слишком много обязанностей. Длинные методы затрудняют поддержку и отладку кода. Если невозможно просмотреть весь метод на экране смартфона, следует рассмотреть его разделение на несколько более мелких методов, каждый из которых выполняет одну конкретную функцию.
- Отказ от наследства
Если класс наследуется от базового класса, но не использует ни одного из унаследованных полей или методов, необходимо подумать, действительно ли здесь нужно наследование. Признаками этого запаха кода может быть то, что унаследованные методы остаются неиспользованными или переопределяются с пустыми телами методов.
- Группы данных
Если несколько вызовов методов принимают один и тот же набор аргументов, это может быть признаком того, что эти аргументы связаны между собой. Для повышения организации кода группу аргументов можно объединить в одном классе.
- Дублирование кода
Распространена ситуация, когда исправленная ошибка появляется в другой части системы. Это может быть результатом дублирования кода, когда ошибка была исправлена не во всех продублированных фрагментах кода. Это создает накладные расходы с точки зрения обслуживания. Разработчики при исправлении ошибки в одном из дублей могут не знать о существовании других.
- Посредник
Когда класс существует только для делегирования вызовов другому классу, разработчик должен спросить себя, какова его реальная цель. Иногда это результат рефакторинга, при котором логика постепенно удаляется из класса, оставляя почти пустую оболочку.
- Одержимость примитивными типами
Примитивные типы дают мало с точки зрения контекста предметной области. Поле id может в конечном итоге содержать любое значение. Если у примитивов есть доменное значение, можно обернуть их в небольшой класс. В последствии этот класс может быть расширен дополнительными методами.
- Комментарии
Можно ли доверять комментариям? Там, где комментарии повторяют то, что можно прочитать из кода, они не несут пользы, особенно если они потеряли актуальность и больше не соответствуют коду.
Вместо того, чтобы добавлять комментарий для пояснения фрагмента кода, нужно подумать, как организовать этот код, чтобы он был понятен без комментария. Может быть возможно предоставить более описательное имя, которое обеспечивает ту же ясность, что и комментарий.
- Расходящиеся модификации
Проблем возникает, когда класс имеет множество причин для изменения. В идеале должна быть прямая связь между общими изменениями и классами.
- Стрельба дробью
В основном, при выполнении любых доработок приходится вносить много небольших изменений во множество различных классов. Проблема в том, что когда изменения повсюду, их трудно найти, и легко пропустить важные изменения.
- Завистливые функции
Это когда метод не использует данные или методы из класса, к которому он принадлежит. Вместо этого он часто обращается к другому классу.
- Ленивый класс
Класс, затраты на существование которого не окупаются выполняемыми им функциями, должен быть ликвидирован.
- Имя метода, включающее тип
Необходимо избегать размещения типов в именах методов; это не только избыточно, но и заставляет менять имя в случае изменения типа.
- Название метода, включающее тип
Необходимо избегать размещения типов в именах методов; это не только избыточно, но и заставляет менять имя в случае изменения типа.
- Невнятное название
Название метода должно лаконично описывать, что делает этот метод. Признаком правильного названия является то, что другой разработчик только по нему может определить назначение метода.
- Мертвый код
Неиспользуемый код должен быть удален.
Вывод
При разработке программного продукта необходимо постоянно следить за появлением запахов кода и устранять их на ранних этапах, чтобы избежать более серьезных проблем в будущем.
В этой статье были перечислены наиболее распространенные запахи кода, но ими список не ограничивается. [2]
Литература:
- Фаулер М. Рефакторинг: улучшение существующего кода. — СПб.: Символ-Плюс, 2003. — 432 с.
- Код с запашком // Википедия. URL: https://ru.wikipedia.org/wiki/Код_с_запашком (дата обращения: 8.01.2019).
