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

Ответ 1

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

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

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

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

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

И если вы игнорируете или запрещаете правила, вы их документируете?

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

Нижняя строка: выберите, на что сосредоточиться, просмотрите, что необходимо, не исправить все, если ваши бизнес-требования не сделают вас

Ответ 6

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

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

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