Философия статического анализа кода очень проста. Чем раньше будет найдена ошибка, тем дешевле ее исправление. Инструменты статического анализа реализуют эту философию в три шага.Шаг первый. Для начала используйте статический анализ хоть как-нибудь. Если вы не использовали статический анализ ранее, то запускайте его хоть раз в месяц. Но запускайте. Ошибка, которую найдёте вы сами, стоит дешевле, чем ошибка, которую найдёт ваш клиент.
Шаг второй. Затем начните использовать статический анализ на билд-сервере во время ночных сборок. Если вы будете находить ошибки не время от времени, а каждый день — то цена их исправления будет меньше.
Шаг третий. Пусть статический анализ будет не только на билд-сервере, но и на машинах разработчиков. Исправлять ошибки после ночного прогона на следующий день это конечно хорошо. А что если разработчики смогут исправлять ошибки ещё до того, как их код оказался в системе хранения? Используйте анализатор во время написания кода, чтобы сразу же проверять только те файлы, которые были модифицированы во время последней сборки.
У вас очень большой проект? И при первом прогоне анализатор выдает просто гору сообщений? Просто игнорируйте их! Пометьте эти сообщения как неинтересные и при следующем прогоне анализатор не будет их выдавать. Это позволяет сразу же с первого дня использования анализатора начать получать от него пользу. Ведь новые сообщения будут выдаваться только на новый или модифицированный код.
Стоит ли использовать статический анализ вместо других методологий? Статический анализ — это не панацея от всех бед! Его нельзя начать использовать вместо юнит-тестов или code review. Статический анализ — это ответ на вопрос: «А что ещё мы можем сделать, чтобы наш код был лучше?». Что значит лучше? Легче поддерживать, проще развивать, быстрее устранять проблемы. Если ваша компания зарабатывает деньги используя программный код вы просто не можете не использовать статический анализ кода.
