Когда перестать следовать советам статического анализа кода?

Question

Я уже довольно давно использую статический анализ кода в проекте с более чем 100 000 строк кода Java. Я начал с Findbugs, который дал мне около 1500 вопросов в начале. Я исправил наиболее серьезные проблемы с течением времени и начал использовать дополнительные инструменты, такие как PMD, Lint4J, JNorm и теперь Enerjy.

С устранением более серьезных проблем возникает огромное количество проблем с низким уровнем серьезности. Как вы решаете эти проблемы с низким приоритетом?

• Вы пытаетесь исправить их все?
• Или только во вновь написанном коде?
• Вы регулярно отключаете определенные правила? (Я обнаружил, что я использую почти любой из доступных инструментов).

А если вы игнорируете или отключаете правила, документируете ли вы их? Что ваши менеджеры говорят о том, что «некоторые тысячи проблем с низким приоритетом остаются нерешенными»? Используете ли вы (несколько) специальные комментарии к инструменту в коде или есть какой-то лучший способ?

Answer 1

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

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

Вы пытаетесь исправить все из них?

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

Но как только мы отключим менее эффективные правила, да, мы исправим все недостатки. Если вы считаете, что что-то является проблемой, вы должны исправить это, если приоритет не превышает приоритет других вещей, которые вы должны сделать. Игнорирование этого вредит культуре вашей команды и посылает неверное сообщение.

А если вы игнорируете или отключаете правила, документируете ли вы их?

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

Что ваши менеджеры говорят о том, что «некоторые тысячи низкоприоритетных проблем не были устранены»?

Ничего. Мы уверены, что они понимают, что мы делаем и почему, но обычно (справедливо) они сосредоточены на метриках более высокого уровня, таких как скорость и общее состояние проекта.

Answer 2

Что ваши менеджеры говорят о том, что «оставление нескольких тысяч проблем с низкими приоритетами не решенными»?

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

Answer 3

Если вы посмотрите на аналогию с вашей базой данных по отслеживанию ошибок, большое количество из них - это ошибки с низким приоритетом, к которым вы, вероятно, никогда не попадете. Конечно, это настоящие ошибки, и вы хотели бы их исправить, но большинство программистов работают с очень реальными ограничениями и не имеют времени для решения всех проблем. Недавно я написал статью о особой природе дефектов статического анализа .

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

Различные стратегии, которые я видел, использовались для достижения успеха: * Прежде всего, убедитесь, что анализ настроен правильно. Статический анализ поставляется «из коробки» с заводскими настройками и не может понять весь код. Если вы не можете настроить его самостоятельно, обратитесь за помощью (отказ от ответственности, мы предоставляем такую ​​помощь). Вы снизите уровень ложных срабатываний и найдете больше хороших ошибок. * Определите характеристики, которые по большей части определяют приоритеты дефектов (это могут быть конкретные категории, конкретные области кода, встроенная оценка приоритетов, предоставляемая инструментом статического анализа и т. Д.). * Определите, какой уровень порога важен, и, возможно, сделайте его критерием приемлемости (например, необходимо учитывать все высокие и критические значения) * Удостоверьтесь, что каждый дефект, который блокирует критерии приемлемости, адресован (обращен, означая, что по крайней мере он должен быть рассмотрен, потому что некоторые могут быть ложными срабатываниями) * Убедитесь, что помеченные как ложноположительные проверены либо с помощью процесса проверки кода коллег, либо с помощью процесса конечного аудита, чтобы у вас не возникало проблем с неправильной маркировкой.

Итог: выберите, на чем сосредоточиться, рассмотрите, что необходимо, не исправляйте все, если ваши бизнес-требования не заставят вас

Answer 4

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

Answer 5

Решите, какие правила вы хотите соблюдать в вашей компании, и отключите остальные. lot правил, которые вы можете установить с помощью этих инструментов, являются субъективными проблемами стиля и могут безопасно игнорироваться.Вы должны задокументировать, какие правила вы следуете один раз в руководстве по стилю компании (чтобы не загромождать свой код этой информацией).

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

Answer 6

Я лично нахожу анализ кода хоть и полезным, но переоцененным.

Я не могу сказать, что для Java, но в C # также есть такая вещь, как анализ кода. Я согласен, что это дает вам много умных идей, как сделать что-то лучше, но иногда рекомендации просто раздражают Некоторые предложения не основаны на здравом смысле, а только вопрос стиля. Через некоторое время поиграв с анализом кода, я перестал его использовать. Причина в том, что я не согласен со многими предупреждениями и не хотел следовать предложениям.

В общем, я бы рекомендовал делать то, что говорит анализ кода. Но до определенного момента. Что бы ни казалось личным стилем того, кто пишет правила, можно легко проигнорировать. Вы можете добавить исключения для правила 1, затем 2, затем три ... пока оно не устареет. Тогда вы просто деактивируете функцию.