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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лично я считаю анализ кода хоть и полезным, но переоцененным.

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

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