Методология статического анализа кода [закрыто]
Какую методологию вы бы использовали с инструментом статического анализа кода?
Когда и где вы будете проводить анализ? Насколько часто?
Как бы вы интегрировали его в среду continues build, на ежедневных сборках? только по ночам?
3 ответа:
Если я использую, то на новой кодовой базе я настраиваю их точно так, как я хочу. Если я использую их на существующей кодовой базе, я включаю сообщения поэтапно, чтобы сообщить о конкретной категории проблемы. Как только этот конкретный тип сообщения очищается, я добавляю следующую категорию.
Я отношусь к инструментам статического анализа так, как если бы они были частью компилятора. Каждый разработчик запускает их каждый раз, когда они делают сборку. Если возможно, я бы также относился к ним, как я делаю предупреждения компилятора-как ошибки. Таким образом, код с предупреждениями вообще не попадает на сервер сборки. Это имеет проблемы, если вы не можете отключить предупреждения в определенных случаях... а предупреждения следует отключать только по договоренности.
Мой опыт показывает, что в целом статический анализ следует использовать на ранних стадиях разработки, предпочтительно (или в идеале) перед модульным тестированием и регистрацией кода. Отчеты из статического анализа также можно использовать в процессе проверки кода. Это позволяет разработчику программного обеспечения разрабатывать надежный код и в некоторых случаях писать код, который может быть более точно проанализирован средствами статического анализа.
Проблема раннего использования заключается в том, что разработчики программного обеспечения должны быть надлежащим образом обучены. использовать инструменты статического анализа и способны эффективно сортировать полученные результаты. Таким образом, они могут предпринять конкретные шаги для улучшения качества программного обеспечения. В противном случае использование инструмента уменьшается или отмеченные проблемы игнорируются, а использование статического анализа уменьшается с течением времени.
На практике большинство организаций, занимающихся разработкой, используют статический анализ на поздних стадиях процесса разработки. На этих этапах инструменты статического анализа используются инженерами по качеству или тестированию. Во многих случаях это связано с помощью систем сборки для получения показателей качества и обеспечения руководства по безопасности и надежности программного обеспечения. Однако если выявленные проблемы накапливаются и охватывают несколько компонентов кода, вероятность того, что все проблемы будут исправлены, уменьшается. Поэтому позднее использование статического анализа в целом может потребовать больше времени и ресурсов для решения выявленных проблем.
Также может быть хорошей идеей установить задачу проверки кода (peer code review by another developer) вместе с использованием инструмента статического анализа, поэтому перед проверкой исходного кода на сервере. таким образом, это поможет повысить качество кода и предотвратить бесполезные строки кода, которые однажды станут бесполезным устаревшим кодом.