Введение
Метрика программного обеспечения (англ. Software metric) – это некая мера определенного свойства программного обеспечения или же его спецификаций. Как известно, мера – это средство измерения. Важно понять, что мера - это числовое значение. Таким образом, метрика программного обеспечения будет показывать некое числовое значение определенного свойства ПО.
Мы не будем углубляться в теорию, так как ее можно найти в свободном доступе довольно легко. Мы займемся практической частью данного вопроса. А именно: как нам использовать метрики для улучшения кода?
Метрики в Visual Studio
Стоит заметить сразу, что метрики подвергаются критике. Это, как минимум, поверхностно и неточно. Мы вернемся к этому после того, как поймем о чем речь. Рассматривать мы будет все на примере Visual Studio 2015 RC. Сперва, откроем проект для изучения.
Далее, мы можем видеть вкладку Analyze
В этой вкладке мы видим Calculate Code Metrics for ...
Это нам и нужно. Разница лишь в том, что будет анализироваться. Или же выбранные проекты в Solution Explorer, или же сразу весь Solution. После нажатия придется немного подождать. Время зависит от конфигурации Вашего компьютера. Когда анализ будет завершен, Вы увидите внизу окно
Здесь будет видна иерархия всего Solution. В моем случае это отдельная dll библиотека и проект. Когда развернем библиотеку, мы увидим следующий уровень иерархии, и так далее
Теперь давайте разберемся со столбцами дальше.
1. Maintainability Index – это комплексный показатель качества кода. Эта метрика рассчитывается по следующей формуле:
MI = MAX(0, (171 — 5.2 * ln(HV) — 0.23 * CC — 16.2 * ln(LoC)) * 100 / 171)
- HV – Halstead Volume, вычислительная сложность. Чем больше операторов, тем больше значение этой метрики;
- CC – Cyclomatic Complexity (Эта метрика описана ниже);
- LoC – количество строк кода (Эта метрика описана ниже).
2. Cyclomatic Complexity – показывает структурную сложность кода. Иными словами, количество различных ветвей кода. Считается на основе операторов в Вашем коде, строя графы переходов от одного оператора к другому. К примеру, оператор if-else увеличит эту метрику, потому что здесь будут разные ветви выполнения.
3. Depth of Inheritance – глубина наследования. Для каждого класса эта метрика показывает, насколько глубоко он в цепочке наследования.
4. Class Coupling – указывает на зависимость классов друг от друга. Проект с множеством зависимостей очень трудно и дорого поддерживать.
5. Lines of Code – количество строк кода. Напрямую используется редко. В наши дни, с множеством разнообразных как подходов к программированию, так и языков, эта метрика дает нам мало полезной информации. Если брать во внимание отдельный метод, то можно разбить его на несколько методов поменьше.
Відео курси за схожою тематикою:
Использования метрик
Изначально стоит обращать внимание на Maintainability Index. Старайтесь придерживать его около 70-90. Это значительно облегчит сопровождения кода как Вами, так и другими программистами. Иногда стоит оставить его на уровне 50-60, так как переписать некоторые участки кода бывает очень затратным. Оценивайте здраво как код, так и Ваши возможности с затратами.
Стоит также уделить много внимания Class Coupling. Эта метрика должна быть как можно меньшей. Ведь она так же способствует поддержке кода. Для оптимизации возможно придется пересматривать дизайн проекта и некоторые архитектурные решения.
Теперь стоит уделить внимание Cyclomatic Complexity. Эта метрика показывает сложность кода, а это так же влияет на поддержку кода в будущем. Иногда приходится переписывать куски кода, которые писали до Вас другие люди, так как Вы просто не можете понять, что, как и зачем в этом методе. Конечно, этому еще способствует стиль кода и идея, но не забывайте о Cyclomatic Complexity при рефакторинге.
Критика
А теперь вернемся к критике. Вы, наверняка, заметили, что мы использовали на практике не все метрики, но они могут быть частью остальных, как в случае с Maintainability Index. Но стоит понимать, что оценивать качество работы программиста, исходя из метрик, нельзя. Это очень неточно и поверхностно. Иногда просто нет другого способа решения задачи, а иногда это бывает затратным. Также есть человеческий фактор, о котором не стоит забывать. Метрики бывают искаженными, ведь программист может стремится написать не эффективное и правильно решение, а оптимизировать показатели этих же метрик.
Вывод
С таким инструментом в руках Вы можете быстро и относительно легко сделать review проекта и найти его уязвимые места. Также можно постоянно мониторить метрики и делать даже некие выводы об усталости работника или его отношении к работе. Более того, можно увидеть динамику роста качества кода каждого программиста. Но здесь стоит отчетливо понимать все детали так, как мы говорили об этом в критике.
Безкоштовні вебінари за схожою тематикою:
Ну и одно из самых важных, следить за недопустимыми значениями, при которых хорошо было бы провести рефакторинг кода.
Статті за схожою тематикою
