Насколько хорошо работает анализ статического кода с помощью Spring и других абстракций?

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

Я веб-разработчик, работающий над системой Java EE. Предпочтительным инструментом для анализа является Coverity Prevent, хотя я, вероятно, мог бы отстаивать что-то еще, если бы мог сделать убедительное доказательство того, что было бы более целесообразно технологии, с которой мы развиваемся.

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

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

Каков опыт работы с этим сценарием? Удалось ли вам получить ценность из инструмента анализа статического кода, когда в вашей архитектуре было много абстракций? Было ли что-то, что вам нужно было сделать, чтобы заставить его работать с минимальными ложными срабатываниями?

4 ответа

Ранее я работал в Coverity, на статическом анализе Java.

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

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


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

Инструмент для тестирования Java, который может собирать эти данные для вас, можно найти здесь.

Если вы хотите свести к минимуму ложные срабатывания, вы можете попробовать запустить инструмент статического анализа и охват тестирования, а также пересечь границу.

В общем, обнаружение мертвого кода X требует подтверждения того, что нет условия, при котором будет вызываться X. Это трудно (теоретически невозможно) при столкновении с машиной Тьюринга и операторами IF формы

if (Turing(..)) then call X();

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

Во многих случаях, однако, "мертвый код" - это действительно просто код, который просто не имеет возможности вызвать его ( "deactive code" на языке FAA). То есть, в то время как X определен, просто нет никаких вызовов X (или обращается, если X является элементом данных) в любом месте системы, прямо или косвенно. Это проще для инструментов статического анализа для обнаружения с беспорядочным усложнением в Java динамической загрузки и отражения класса (что делает проблему анализа деактивированного кода невозможной перед неизвестными, но загружаемыми классами).

Игнорируя эти сложности, можно найти инструменты статического анализа, которые обнаруживают деактивированный код в больших Java-системах и сообщают об этом. Такой инструмент должен обрабатывать всю систему Java сразу, потому что иначе ссылка может существовать в одном модуле, не включенном в анализ. Мы создали "деактивирующий" детектор кода и средство для удаления, даже могут вернуть ваш исходный код с полностью удаленным автоматически удаленным кодом, а также отчет о том, что не указано. Вы проверяете отчет и решаете, хотите ли вы использовать очищенный код или добавить доступ к неприемлемому неиспользуемому объекту.


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

И я сомневаюсь, что присутствие мертвого кода стоит больше, чем это.


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

Значение статического анализатора кода не является просмотром кода. Чтобы устранить мертвый код, я бы использовал покрытие кода для его профилирования. - В вашем случае - вы упоминали много абстракций... Я почти догадываюсь, что статический анализ кода будет недостаточным.

licensed under cc by-sa 3.0 with attribution.