В компьютерном программировании , код запах любая характеристика в исходном коде в виде программы , которая , возможно , указывает на более глубокую проблему. [1] [2] Определение того, что является запахом кода, а что нет, является субъективным и зависит от языка, разработчика и методологии разработки.
Термин был популяризирован Кентом Беком на WardsWiki в конце 1990-х годов. [3] Использование этого термина увеличилось после того, как он был описан в книге Мартина Фаулера « Рефакторинг: улучшение дизайна существующего кода » в 1999 году . [4] Это также термин, используемый гибкими программистами. [5]
Определение
Один из способов взглянуть на запахи - с точки зрения принципов и качества: «Запахи - это определенные структуры в коде, которые указывают на нарушение фундаментальных принципов проектирования и отрицательно влияют на качество дизайна». [6] Запахи кода обычно не являются ошибками ; они не являются технически некорректными и не препятствуют работе программы. Вместо этого они указывают на недостатки в дизайне, которые могут замедлить разработку или увеличить риск ошибок или сбоев в будущем. Запах плохого кода может быть индикатором факторов, способствующих возникновению технического долга . [1] Роберт К. Мартин называет список кода «системой ценностей» для разработки программного обеспечения. [7]
Часто более глубокая проблема, на которую намекает запах кода, может быть обнаружена, когда код подвергается короткому циклу обратной связи , когда он подвергается рефакторингу небольшими контролируемыми шагами, а полученный дизайн исследуется, чтобы увидеть, есть ли какие-либо другие запахи кода, в свою очередь указывают на необходимость дальнейшего рефакторинга. С точки зрения программиста, которому поручено выполнение рефакторинга, запахи кода - это эвристика, указывающая, когда проводить рефакторинг и какие конкретные методы рефакторинга использовать. Таким образом, запах кода - это стимул для рефакторинга.
2015 исследование [1] с использованием автоматизированного анализа полмиллиона исходного кода фиксаций и ручного обследования 9,164 фиксаций определяется выставляться «код запахами» установлено , что:
- Существуют эмпирические свидетельства последствий «технического долга», но существуют лишь отдельные свидетельства того , как , когда и почему это происходит.
- Здравый смысл подсказывает, что неотложные действия по техническому обслуживанию и необходимость предоставления функций с упором на время вывода на рынок, а не на качество кода, часто являются причинами таких неприятных запахов.
Такие инструменты, как Checkstyle , PMD , FindBugs и SonarQube, могут автоматически определять запахи кода.
Общие запахи кода
Запахи на уровне приложений: [ оригинальное исследование? ]
- Загадочное имя : функции, модули, переменные или классы названы так, чтобы не сообщать, что они делают или как их использовать.
- Дублированный код : идентичный или очень похожий код существует более чем в одном месте.
- Надуманная сложность : принудительное использование чрезмерно усложненных шаблонов проектирования там, где было бы достаточно более простого дизайна.
- Операция с дробовиком : одно изменение нужно применить к нескольким классам одновременно.
- Неконтролируемые побочные эффекты : очень легко вызвать исключения во время выполнения, а модульные тесты не могут их зафиксировать.
- Изменения переменных : очень сложно реорганизовать код, так как фактическое значение непредсказуемо, и его трудно осмыслить.
- Логическая слепота : легко утверждать противоположное значение и все равно проверять тип.
Запахи на уровне класса: [ оригинальное исследование? ]
- Большой класс : класс , который стал слишком большим. Смотрите, Бог возражает .
- Зависть к особенностям : класс, чрезмерно использующий методы другого класса.
- Несоответствующая близость : класс, который зависит от деталей реализации другого класса. См. Объектная оргия .
- Отказался завещание : класс , который переопределяет это метод базового класса таким образом , что контракт на базовый классе не почитаются производным классом . См. Принцип подстановки Лискова .
- Ленивый класс / халявщик : класс, который делает слишком мало.
- Чрезмерное использование литералов : они должны быть закодированы как именованные константы, чтобы улучшить читаемость и избежать ошибок программирования. Кроме того, литералы могут и должны быть экстернализованы в файлы ресурсов / сценарии или другие хранилища данных, такие как базы данных, где это возможно, для облегчения локализации программного обеспечения, если оно предназначено для развертывания в разных регионах. [8]
- Цикломатическая сложность : слишком много ветвей или петель; это может указывать на то, что функцию необходимо разбить на более мелкие функции или что у нее есть потенциал для упрощения / рефакторинга.
- Нисходящее приведение : приведение типа, нарушающее модель абстракции; абстракцию, возможно, придется реорганизовать или исключить. [9]
- Сиротская переменная или константный класс : класс, который обычно имеет набор констант, принадлежащих другому месту, где эти константы должны принадлежать одному из других классов-членов.
- Группа данных : возникает, когда группа переменных передается вместе в различных частях программы. В общем, это говорит о том, что было бы более подходящим формально сгруппировать различные переменные в один объект и вместо этого передавать только новый объект. [10] [11]
Запах на уровне метода: [ оригинальное исследование? ]
- Слишком много параметров : длинный список параметров трудно читать, что затрудняет вызов и тестирование функции. Это может указывать на то, что цель функции плохо продумана и что код следует реорганизовать, чтобы ответственность распределялась более четко. [12]
- Длинный метод : метод , функция или процедура, которые стали слишком большими.
- Чрезмерно длинные идентификаторы : в частности, использование соглашений об именах для устранения неоднозначности, которая должна быть неявной в архитектуре программного обеспечения .
- Чрезмерно короткие идентификаторы : имя переменной должно отражать ее функцию, если функция не очевидна.
- Чрезмерный возврат данных : функция или метод, возвращающий больше, чем нужно каждому из вызывающих.
- Чрезмерные комментарии : у класса, функции или метода есть несущественные или тривиальные комментарии. Комментарий к установщику / получателю атрибута - хороший пример.
- Бог-объекты : класс, у которого много обязанностей и низкий уровень сплоченности.
- Чрезмерно длинная строка кода (или God Line): слишком длинная строка кода, затрудняющая чтение, понимание, отладку, рефакторинг или даже определение возможностей повторного использования программного обеспечения. Пример:
новый XYZ (s) .doSomething (buildParam1 (x), buildParam2 (x), buildParam3 (x), a + Math.sin (x) * Math.tan (x * y + z)). doAnythingElse (). build ( ).послать запрос();
Смотрите также
- Анти-шаблон
- Запах дизайна
- Список инструментов для статического анализа кода
- Программная гниль
Рекомендации
- ^ a b c Туфано, Микеле; Паломба, Фабио; Бавота, Габриэле; Оливето, Рокко; Ди Пента, Массимилиано; Де Люсия, Андреа; Пошиваник, Денис (2015). «Когда и почему ваш код начинает плохо пахнуть» (PDF) . 2015 IEEE / ACM 37-я Международная конференция IEEE по разработке программного обеспечения . С. 403–414. CiteSeerX 10.1.1.709.6783 . DOI : 10.1109 / ICSE.2015.59 . ISBN 978-1-4799-1934-5. S2CID 59100195 .
- ^ Фаулер, Мартин. «CodeSmell» . martinfowler.com/ . Проверено 19 ноября 2014 .
- ^ Бек, Кент. «Кодовые запахи» . WikiWikiWeb . Уорд Каннингем . Проверено 8 апреля 2020 .
- ^ Фаулер, Мартин (1999). Рефакторинг. Улучшение дизайна существующего кода . Эддисон-Уэсли. ISBN 978-0-201-48567-7.
- ^ Бинсток, Эндрю (27.06.2011). «В честь небольшого кода» . Информационная неделя . Проверено 27 июня 2011 .
- ^ Сурьянараяна, Гириш (ноябрь 2014 г.). Рефакторинг для разработки программного обеспечения . Морган Кауфманн. п. 258. ISBN 978-0128013977.
- ^ Мартин, Роберт С. (2009). «17: запахи и эвристика». Чистый код: руководство по созданию гибкого программного обеспечения . Прентис Холл. ISBN 978-0-13-235088-4.
- ^ «Константы и магические числа» . Проверено 3 ноября 2020 .
- ^ Миллер, Джереми. «Понижение - это запах кода» . Архивировано из оригинального 16 февраля 2019 года . Проверено 4 декабря 2014 .
- ^ Фаулер, Мартин. «DataClump» . Проверено 3 февраля 2017 .
- ^ «Паттерны проектирования и рефакторинг» . sourcemaking.com . Проверено 4 февраля 2017 .
- ^ https://mcsee.hashnode.dev/code-smell-10-too-many-arguments
дальнейшее чтение
- Гаруси, Вахид; Кучук, Барыш (2018). «Запахи в коде тестирования программного обеспечения: обзор знаний в промышленности и академических кругах». Журнал систем и программного обеспечения . 138 : 52–81. DOI : 10.1016 / j.jss.2017.12.013 .
- Шарма, Тушар; Спинеллис, Диомидис (2018). «Обзор программных запахов» . Журнал систем и программного обеспечения . 138 : 158–173. DOI : 10.1016 / j.jss.2017.12.034 .
Внешние ссылки
- CodeSmell на c2.com
- Таксономия кодовых запахов
- Обзор множества запахов кода
- CodeSmell
- Баунди, Дэвид, Рак программного обеспечения: семь ранних предупреждающих знаков или сюда , ACM SIGSOFT Software Engineering Notes, Vol. 18 № 2 (апрель 1993 г.), Ассоциация вычислительной техники, Нью-Йорк, Нью-Йорк, США