Инструменты анализа сложности кода за пределами циклической сложности

Question

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

Какие еще инструменты доступны для идентификации проблемного Java-кода?

Обратите внимание: мы уже используем PMD и FindBugs, которые, как я считаю, отлично подходят для идентификации уровня метода.

Answer 1

Мой опыт показывает, что наиболее важные показатели при просмотре кода ремонтопригодности являются:

• цикломатическая Сложность, чтобы определить большие куски кода, которые, вероятно, трудно понять/изменить.
• Глубина гнездования, чтобы найти похожие точки (высокая глубина гнездования автоматически высокая CC, но не обязательно наоборот, так что оценка на обоих важна для просмотра).
• Включение/выключение вентилятора, чтобы лучше понять отношения между методами/классами и актуальную важность отдельных методов.

При изучении кода, написанного другими, часто бывает полезно включать динамические методы.Просто запустите общие сценарии использования с помощью инструмента покрытия/кода профайлера, чтобы обнаружить:

• Код, который фактически выполняется много (профайлер отлично подходит для этого, просто игнорировать информацию о времени и посмотреть на хит подсчетов, а).
• Кодовое покрытие отлично подходит для поиска (почти) мертвого кода. Чтобы вы не тратили время на реорганизацию кода, который редко выполняется в любом случае.

Обычные подозреваемые, такие как любой инструмент профилирования, охвата кода и показателей, как правило, помогут вам получить данные, необходимые для проведения этих оценок.

Answer 2

Статические инструменты анализа, которые вы уже используете, довольно стандартны. Если вы используете Eclipse, попробуйте посмотреть here для получения дополнительных инструментов анализа кода.

Emma обеспечивает анализ покрытия кода, хотя это действительно для тестирования.

Answer 3

Google Testability Explorer проверяет, например, на однотонные и другие статические вещи, которые являются плохими запахами в дизайне. Metrics - это плагин Eclipse, который измеряет почти все метрики кода, известные человечеству. Я использовал и могу легко рекомендовать оба.

Answer 4

Я никогда не использовал его, но я нашел это довольно интересный и перспективно:

http://erik.doernenburg.com/2008/11/how-toxic-is-your-code/

И я использовал этот и нашел, что это очень полезно, потому что хорошая визуализация зависимостей

http://www.headwaysoftware.com/products/structure101/index.php

Answer 5

Sonar пытается идентифицировать «горячие точки» сложности и ремонтопригодности, сочетая результаты различных инструментов с открытым исходным кодом (включая PMD и Findbugs). Он хорошо интегрируется с серверами Maven и CI (особенно с Hudson).

EDIT по extraneon

Существует сайт available Sonar, где анализируются много проектов с открытым исходным кодом. Я думаю, что это показывает, насколько хороши правила, и как далеко продвинулся процесс. Разумеется, вы также можете отключить правила, которые вы не найдете в этом интересном.

Here - это объяснение показателей.

Answer 6

Инструмент NDepend для кода .NET позволит вам проанализировать многие аспекты сложности коды, включая метрики коды, такие как: цикломатической сложность, глубину вложенности, отсутствие согласованности методов, покрытие тестов ...

. ... включая анализ зависимостей и в том числе Code Rules over LINQ Queries (CQLinq), посвященный спросить, что сложного в моем коде, и написать правило. Предусмотрено около 200 default Code Rules. Они касаются антишаблоны как Singleton, обнаружение threading problems, обнаружение проблем сцепных как UI layer shouldn't use directly DB types ...

Некоторое время назад я написал статью резюмировать несколько аспектов сложности кода: Fighting Fabricated Complexity