Как хорошо статический анализ кода работает с Spring и другими абстракциями?

Раньше я работал в Coverity над продуктом статического анализа Java.

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

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

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

И я сомневаюсь, что наличие мертвого кода стоит дороже этой суммы.

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

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

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

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

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

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

Однако во многих случаях «мертвый код» действительно просто код, который просто не может вызвать его («деактивный код» на языке FAA). То есть, пока X определен, прямо или косвенно в системе просто нет обращений к X (или обращений, если X является элементом данных). Их легче обнаружить инструментам статического анализа из-за беспорядочного усложнения в Java, связанного с загрузкой и отражением динамических классов (что делает невозможным деактивный анализ кода перед лицом неизвестных, но загружаемых классов).

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

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

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