Запах кода
В компьютерном программировании запах кода - это любая характеристика в исходном коде программы, которая, возможно, указывает на более глубокую проблему. Определение того, что является и не является запахом кода, субъективно и зависит от языка, разработчика и методологии разработки.
Термин был популяризирован Кентом Беком в WardsWiki в конце 1990-х годов.[3] Использование термина увеличилось после того, как он был показан в книге 1999 года "Рефакторинг: улучшение дизайна существующего кода" Мартина Фаулера.[4] Это также термин, используемый гибкими программистами.
Определение[править]
Один из способов взглянуть на запахи с точки зрения принципов и качества: "Запахи - это определенные структуры в коде, которые указывают на нарушение фундаментальных принципов дизайна и негативно влияют на качество дизайна". Запахи кода обычно не являются ошибками; они не являются технически неправильными и не мешают работе программы. Вместо этого они указывают на слабые места в дизайне, которые могут замедлить разработку или увеличить риск ошибок или сбоев в будущем. Плохой запах кода может быть индикатором факторов, которые способствуют техническому долгу. Роберт С. Мартин называет список запахов кода "системой ценностей" для мастерства программного обеспечения.
Часто более глубокая проблема, на которую намекает запах кода, может быть обнаружена, когда код подвергается короткому циклу обратной связи, где он реорганизуется небольшими контролируемыми шагами, и результирующий дизайн проверяется, чтобы увидеть, есть ли какие-либо дополнительные запахи кода, которые, в свою очередь, указывают на необходимость большего рефакторинга. С точки зрения программиста, которому поручено выполнять рефакторинг, запахи кода - это эвристика, указывающая, когда рефакторинговать и какие конкретные методы рефакторинга использовать. Таким образом, запах кода является драйвером для рефакторинга.
Исследование 2015 года[1], в котором использовался автоматический анализ полумиллиона коммитов исходного кода и ручная проверка 9,164 коммитов, обнаруживших "запах кода", показало, что:
- Существуют эмпирические данные о последствиях "технического долга", но существуют только анекдотические данные о том, как, когда и почему это происходит.
- Здравый смысл предполагает, что срочные действия по техническому обслуживанию и давление на поставку функций при приоритете времени выхода на рынок над качеством кода часто являются причинами таких запахов.
Такие инструменты, как Checkstyle, PMD, FindBugs и SonarQube, могут автоматически идентифицировать запах кода.
Общие запахи кода[править]
Запахи прикладного уровня[править]
[оригинальное исследование?]
- Таинственное имя: функции, модули, переменные или классы, которые названы таким образом, что не сообщают, что они делают или как их использовать.
- Дублированный код: идентичный или очень похожий код, который существует более чем в одном месте.
- Надуманная сложность: принудительное использование чрезмерно сложных шаблонов проектирования, где достаточно более простых шаблонов проектирования.
- Хирургия дробовика: одно изменение, которое должно быть применено к нескольким классам одновременно.
- Неконтролируемые побочные эффекты: побочные эффекты кодирования, которые обычно вызывают исключения во время выполнения, когда модульные тесты не могут определить точную причину проблемы.
- Переменные мутации: мутации, которые варьируются достаточно широко, что рефакторинг кода становится все более трудным, из-за статуса фактического значения как непредсказуемого и трудно рассуждать.
- Логическая слепота: легко утверждать противоположное значение и по-прежнему проверять тип.
Запахи класса[править]
[оригинальное исследование?]
- Большой класс: класс, который стал слишком большим. См. Объект Бога.
- Feature envy: класс, который чрезмерно использует методы другого класса.
- Неуместная близость: класс, который зависит от деталей реализации другого класса. См. Оргия объектов.
- Отказ от завещания: класс, который переопределяет метод базового класса таким образом, что контракт базового класса не выполняется производным классом. См. Принцип подстановки Лискова.
- Ленивый класс / freeloader: класс, который делает слишком мало.
- Чрезмерное использование литералов: они должны быть закодированы как именованные константы, чтобы улучшить читаемость и избежать ошибок программирования. Кроме того, литералы могут и должны быть экстернализированы в файлы ресурсов / скрипты или другие хранилища данных, такие как базы данных, где это возможно, чтобы облегчить локализацию программного обеспечения, если оно предназначено для развертывания в разных регионах.
- Цикломатическая сложность: слишком много ветвей или циклов; это может указывать на то, что функцию необходимо разбить на более мелкие функции или что она имеет потенциал для упрощения / рефакторинга.
- Даункастинг: приведение типа, которое нарушает модель абстракции; абстракцию, возможно, придется реорганизовать или устранить.
- Класс Orphan variable or constant : класс, который обычно имеет коллекцию констант, которые принадлежат в другом месте, где эти константы должны принадлежать одному из других классов-членов.
- Сгусток данных: возникает, когда группа переменных передается вместе в разных частях программы. В общем, это говорит о том, что было бы более уместно формально сгруппировать различные переменные вместе в один объект и вместо этого передать только новый объект.
Запахи на уровне метода[править]
[оригинальное исследование?]
- Слишком много параметров: длинный список параметров трудно читать и усложняет вызов и тестирование функции. Это может указывать на то, что назначение функции непродуманно и что код должен быть реорганизован, чтобы ответственность была распределена более четким образом].
- Длинный метод: метод, функция или процедура, которая стала слишком большой.
- Чрезмерно длинные идентификаторы: в частности, использование соглашений об именах для обеспечения неоднозначности, которая должна быть неявной в архитектуре программного обеспечения.
- Чрезмерно короткие идентификаторы: имя переменной должно отражать ее функцию, если функция не очевидна.
- Чрезмерный возврат данных: функция или метод, который возвращает больше, чем нужно каждому из его вызывающих.
- Чрезмерные комментарии: класс, функция или метод имеют нерелевантные или тривиальные комментарии. Хорошим примером является комментарий к сеттеру / геттеру атрибутов.
- Чрезмерно длинная строка кода (или Строка Бога): слишком длинная строка кода, затрудняющая чтение, понимание, отладку, рефакторинг или даже определение возможностей повторного использования программного обеспечения.
См. Также[править]
- Анти-паттерн
- Запах дизайна
- Список инструментов для статического анализа кода
- Гниль программного обеспечения
Читать[править]
Garousi, Vahid; Küçük, Barış (2018). "Запахи в тестовом коде программного обеспечения: обзор знаний в промышленности и научных кругах". Журнал систем и программного обеспечения.