Пользователь
0,0
рейтинг
9 декабря 2013 в 17:34

Разработка → Что такое качество кода и зачем его измерять


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

В первую очередь надо выяснить по каким метрикам надо определять качество кода и для чего это нам вообще нужно. В программировании нам повезло и, в большинстве случаев, для определении метрики нам достаточно определить важную для нас характеристику:
  • соответствие правилам;
  • сложность кода;
  • дубликаты;
  • комментирование;
  • покрытие тестами.

Сейчас рассмотрим каждую из них.

Соответствие правилам


Под этот пункт подпадают ситуации когда код компилируется и, в большинстве случаев, делает свое дело, при чем делает это правильно. Это интересная характеристика в большей степени от того, что в компании сначала должны существовать правила написания кода. Можно поступить проще и взять труд других (Java Code Conventions, GCC Coding Conventions, Zends Coding Standard), а можно поработать и дополнить их своими, наиболее подходящими для специфики вашей компании.
Но зачем нам правила написания кода, если код делает свое дело? Чтобы ответить на вопрос выделим несколько типов правил:
  • синтаксические правила — одни из наиболее бесполезных правил (но только первый взгляд), поскольку совсем никоим образом не виляют на исполнение программы. К ним можно отнести стиль именования переменных (camelCase, через подчеркивание), констант (uppercase), методов, стиль написания фигурных скобок и нужны ли они если в блоке только одна строка кода. Этот список можно продолжить. Когда программист пишет код, он его легко читает, потому что он знает свой собственный стиль. Но стоит ему дать код где используется венгерская нотация и скобки с новой строки, ему придется тратить дополнительное внимание на восприятие нового стиля. Особенно веселит ситуация когда несколько совсем разных стилей используются в одном проекте или даже модуле.
  • правила поддержки кода — правила, которые должны сигнализировать что код слишком сложный и его будет трудно сопровождать. К примеру, индекс сложности (подробнее о нем ниже) метода или класса слишком большой или слишком много строк кода в методе, наличие дубликатов в коде или “magic numders”. Думаю суть ясна, все они указывают нам на узкие места которые сложно будет сопровождать. Но нельзя забывать что именно мы можем решить какой индекс сложности для нас большой, а какой приемлемый.
  • очистка и оптимизация кода — самые простые правила в том смысле, что редко кто-то будет утверждать что выражения очень нужны, даже когда они нигде не используются. Сюда можно отнести лишние импорты, переменные и методы которые уже не используются, но по какой-то причине их оставили в наследство.

Метрика здесь очевидная: соответствие правилам должно стремится к 100%, то есть чем меньше нарушений правил тем лучше.

Цикломатическая сложность кода


Характеристика, от которой напрямую зависит сложность поддержки кода. Здесь выделить метрику посложнее чем в предыдущей характеристике. Если по простому, оно зависит от количества вложенных операторов ветвления и циклов. Кому интересно более подробное описания, можно почитать на вики. Чем индекс ниже тем лучше, и тем легче в будущем будет менять структуру кода. Стоит мерить сложность метода, класса, файла. Значение этой метрики надо ограничить некоим предельным числом. К примеру цикломатическая сложность метода не должна превышать 10, иначе нужно упростить или разбить его.

Дубликаты


Важная характеристика, которая отображает насколько легко в будущем (или настоящим) можно будет вносить изменения в код. Метрику можно означить в процентах как соотношение строк дубликатов к всем строкам кода. Чем меньше дубликатов тем легче будет жить с этим кодом.

Комментирование


Одна из самых холиварных и больных тем среди программистов: “Комментировать или не комментировать?”. Всем знаком диалог из книги Стива Макконнелла, он уже публиковался на хабре. Из этого можно сделать вывод что к характеристике нужно подходить очень индивидуально, исходя от специфики компании и продуктов с которыми компания работает: для маленьких проектов комментирование не столь необходимо, для больших же хорошо проработанные правила очень облегчат сопровождение. Для комментирования можно выделить две важные метрики:
  • отношение комментариев ко всему коду — из этой метрики можно сделать вывод насколько детальные комментарии и насколько они могут быть полезными. Конечно, из этой метрики нельзя сказать есть ли комментарии “цикл” перед циклом, но это нужно исправлять когда проводится ревю.
  • комментирование публичных методов — отношение комментированных публичных методов к общему их количеству. Так как публичные методы используются вне пределов класса или пакета, то лучше прокомментировать что этот метод должен делать и на что может повлиять. Количество публичных методов без комментария должно стремится к нулю.

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

Покрытие тестами


Не надо описывать необходимость и роль автоматических тестов для проекта, потому что это тема отдельной статьи. Но это очень важная характеристика качества кода. Уровень покрытия считывается как отношение количества покрытых тестами элементов кода к количеству всех существующих. В зависимости от того что означить как элемент кода, часто выделяют следующие типы покрытия:
  • покрытие файлов — здесь нужно определить как понять что файл покрыт тестами: зачастую файл покрыт если тест попал в файл и исполнил хотя бы одну строку кода из файла. Поэтому такая метрика используется крайне редко, но она все же имеет право на существование.
  • покрытие классов — аналогично с покрытием файлов, только покрытие классов :). Также редко используется.
  • покрытие методов — тот же способ исчисления метрики. Правда покрытие методов может найти более широкое распространение: если у вас на проекте существует правило покрывать каждый метод хотя бы одним тестом, тогда с помощью этой метрики можно быстро найти код не соответствующий правилам.
  • покрытие строк — одна из наиболее используемых метрик по покрытию. Тот же способ исчисления, только за об’эк берется строка.
  • покрытие ветвлений — то же, соответственно за элемент берется ветвление. Добиться хорошего показателя по этой метрики стоит наибольших усилий. По этой метрике можно судить насколько совестно программист подошел к покрытию тестами.
  • суммарное покрытие — метрика покрытия при которой в расчетах принимается во внимание не один элемент а несколько. Наиболее часто используют суммарное покрытие строк и ветвлений.

Чем выше покрытие кода тестами тем меньше риск поломать часть системы и оставить это незамеченным.

Вместо заключения


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

Дмитро @WingeD
карма
7,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (6)

  • 0
    > К примеру цикломатическая сложность метода не должна превышать 10, иначе нужно упростить или разбить его.
    Есть такое исключение (например в соглашениях для кода ядра линукса), что чем проще метод, тем длиннее может быть его код. Например:
    if (...) { ... } else if (...) { ... } ... else { ... }
    само собой цикломатическая сложность у данного метода растет очень быстро.

    Аналогично при использовании Fluent Builders в ООП.

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

    В статье, мало внимания уделено соглашениям, все же интереснее какие именно правила позволяют сделать код чище. Вот, например, для C#, частично как адаптированный конспект по Clean Code: csharpguidelines.codeplex.com/
    • 0
      В статье я не хотел описывать как нужно кодить а как нельзя, а просто выделить список характеристик за которыми стоит следить. Честно говоря соглашения — хорошая тема для отдельной статьи. Так же я указал что правила очень завысят от проекта и специфики компании, а 10 указал только в качестве примера.
      Конечно проводить ревю кода незаменимо, но автоматизированный анализ кода тоже очень полезная вещь :)
  • 0
    синтаксические правила — на самом деле чёткие стилистические правила написания кода позволяют намного быстрее искать что-то в коде и из этого вытекает много плюсов для командной работы.
    Если имена переменных пишутся разными стилями, да еще и с синтаксическими ошибками, такие переменные не найдешь.
    • 0
      Полностью согласен, тем не менее если компания не уделяет этому должного внимания такое может встречаться.
  • 0
    Если кому-то интересно — вот онлай анализатор JavaScript кода. Выводит, например, цикломатическую сложность кода, покрытие комментариями… Или вот еще — jscomplexity.org/
  • НЛО прилетело и опубликовало эту надпись здесь

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