Философия статического анализа кода очень проста. Чем раньше будет найдена ошибка, тем дешевле ее исправление. Инструменты статического анализа реализуют эту философию в три шага.Шаг первый. Для начала используйте статический анализ хоть как-нибудь. Если вы не использовали статический анализ ранее, то запускайте его хоть раз в месяц. Но запускайте. Ошибка, которую найдёте вы сами, стоит дешевле, чем ошибка, которую найдёт ваш клиент.
Шаг второй. Затем начните использовать статический анализ на билд-сервере во время ночных сборок. Если вы будете находить ошибки не время от времени, а каждый день — то цена их исправления будет меньше.
Шаг третий. Пусть статический анализ будет не только на билд-сервере, но и на машинах разработчиков. Исправлять ошибки после ночного прогона на следующий день это конечно хорошо. А что если разработчики смогут исправлять ошибки ещё до того, как их код оказался в системе хранения? Используйте анализатор во время написания кода, чтобы сразу же проверять только те файлы, которые были модифицированы во время последней сборки.
У вас очень большой проект? И при первом прогоне анализатор выдает просто гору сообщений? Просто игнорируйте их! Пометьте эти сообщения как неинтересные и при следующем прогоне анализатор не будет их выдавать. Это позволяет сразу же с первого дня использования анализатора начать получать от него пользу. Ведь новые сообщения будут выдаваться только на новый или модифицированный код.
Стоит ли использовать статический анализ вместо других методологий? Статический анализ — это не панацея от всех бед! Его нельзя начать использовать вместо юнит-тестов или code review. Статический анализ — это ответ на вопрос: «А что ещё мы можем сделать, чтобы наш код был лучше?». Что значит лучше? Легче поддерживать, проще развивать, быстрее устранять проблемы. Если ваша компания зарабатывает деньги используя программный код вы просто не можете не использовать статический анализ кода.
SirEdvin
И… все. Это в целом путь в никуда, потому что кто будет эти ошибки исправлять, вести учет и прочее? Тот же человек, который иногда его запускает?
Это если ваш анализатор такое умеет, ну и вдобавок, если просто спрятать гору мусора, какой тогда прок от анализатора?
Andrey2008
Для компромисса, давайте считать, что первый шаг, это знакомство с инструментом. Пусть человеку понравится статический анализ кода, пусть он увидит, что находятся ошибки. Тогда он задумается о необходимости делать это почаще.
Умеет. И не только PVS-Studio. Такая возможность есть в любом серьезном анализаторе.
Никто не говорит, что потом нельзя вернуться к изучению скрытых предупреждений. Это предназначено для облегчения этапа внедрения. Можно начать сразу работать с предупреждениями, выдаваемыми для нового кода, а к старым ошибкам вернуться позже. Как показывает практика, эти старые ошибки менее критичны, иначе приложение бы просто не работало. Т.е. серьезные и явные ошибки уже исправлены и остались те, которые проявляет себя редко или не сильно раздражают пользователей. Эти ошибки конечно тоже стоит править, но с ними пользователи мирятся (возможно годами), а значит они могут и ещё подождать :).
P.S. Другие дело, если стоит задача устранения потенциальных уязвимостей. Здесь не важно, проявляет себя ошибка при нормальном режиме работы или нет. С точки зрения пользователя, ошибки вообще нет и все работает правильно. Но при этом ошибка может эксплуатироваться при подсовывании некорректных входных данных и про это даже никто не догадывается. Поэтому, в этом случае есть смысл изучать сразу все предупреждения, как новые, так и старые.
humbug
Кстати, да. Это серьезно упрощает жизнь разработчику. В 99% старый код отдебажен, стреляет изредка, выполняет свои задачи. А вот чтобы не наступать на новые грабли и упростить себе жизнь, снизить кол-во часов, проведенных в дебаггере, лучше пользоваться статическим анализатором.
dadwin
противоречивые шаги вы предлагаете: сначала «важно найти ошибку как можно раньше», а потом «отключайте все сообщения». начинается всё с характеристик качества продукта — что именно хотите проверять анализатором. предложили бы отключать некоторые классы сообщений, которые минорные с точки зрения уязвимостей. ну например, про дублирование кода. а то так можно сообщение про sql injection отключить, а потом и не вспомнить про него.
SQALE-пирамида, например, как раз один из способов приоритезации сообщений анализатора.
может быть. а может быть проверяемый код до полноценного production'а не дошел, вот и не проявлялись такие ошибки. зависит от момента времени внедрения статического анализа в жизненный цикл продукта.
Andrey2008
Это не противоречие, а невозможность указать один единственный верный способ использования анализатора кода.
Отключать отдельные диагностики можно. Можно исключать определённые папки с каталогами. И так далее. Подробности описаны в документации. Здесь же была сделана дать некое общее видение ситуации.