Когда прекратить следовать совету статического анализа кода?
Я действительно использую статический анализ кода проекта больше чем с 100 000 строк кода Java долгое время теперь. Я запустил с Findbugs, который дал мне приблизительно 1 500 проблем вначале. Я фиксировал самое серьезное со временем и начинал использовать дополнительные инструменты как PMD, Lint4J, JNorm и теперь Enerjy.
Так как более серьезные проблемы устраняются, существует огромное количество проблем низкой степени серьезности. Как Вы обрабатываете эти низкоприоритетные проблемы?
- Вы пытаетесь фиксировать всех их?
- Или только в недавно написанном коде?
- Вы регулярно отключаете определенные правила? (Я нашел, что делаю почти на любом из доступных инструментов).
И если Вы игнорируете или отключаете правила, действительно ли Вы документируете их? Что Ваши менеджеры говорят об "отъезде некоторой тысячи низкоприоритетных проблем, не устраненных"? Вы используете (несколько) инструмент определенные комментарии в коде или есть ли какой-либо лучший путь?
6 ответов
Имейте в виду, что статический анализ предназначен для генерации большого количества ложных срабатываний; это цена, которую вы обычно платите за то, чтобы избежать ложных негативов. То есть они предполагают, что вам бы скорее сказали неправильно, что что-то выглядит подозрительно (ложное срабатывание), вместо того, чтобы сказать, что что-то, что на самом деле является проблемой, совершенно нормально (ложноотрицательный).
В общем, вы должны настраивать эти инструменты, а не принимать стандартные значения по умолчанию, которые создают много шума.
Пытаетесь ли вы исправить их все?
В проектах, над которыми у меня есть технический контроль, мой стандартный метод работы - поощрять культуру, в которой люди проверяют все новые дефекты статического анализа в нашей системе CI . Если мы отказываемся исправлять достаточное количество дефектов определенного типа в течение определенного периода времени, мы отключаем это правило, поскольку оно становится просто шумом. Время от времени мы будем проверять отключенные правила, чтобы убедиться, что они по-прежнему актуальны.
Но как только мы отключим менее эффективные правила, да, мы исправим все дефекты. Если вы считаете, что что-то является проблемой, вы должны исправить это, если приоритет не превышает приоритета других дел, которые вам нужно сделать. Игнорирование этого вредит культуре вашей команды и посылает неверный сигнал.
И если вы игнорируете или отключаете правила, вы их документируете?
Файл правил является частью нашего проекта, поэтому достаточно сообщения фиксации, чтобы задокументировать тот факт, что такие-то правила были отключены в этой фиксации .
Что ваши менеджеры говорят о том, что «несколько тысяч низкоприоритетных проблем не решены»?
Ничего. Мы следим за тем, чтобы они понимали, что мы делаем и почему, но обычно (справедливо) сосредоточены на показателях более высокого уровня, таких как скорость и общее состояние проекта.
Лично я считаю, что анализ кода полезен, но переоценен.
Я не могу сказать о Java, но в C # есть еще такая вещь, как анализ кода. Я согласен, что это дает вам много умных идей, как сделать что-то лучше, но иногда рекомендации просто раздражают. Некоторые предложения не основаны на здравом смысле, а касаются только стиля. Поигравшись с анализом кода, я перестал его использовать. Причина в том, что я не соглашался со многими предупреждениями и не хотел следовать предложениям.
В общем, я бы рекомендовал делать то, что говорит анализ кода. Но до определенного момента. Все, что кажется вопросом личного стиля того, кто пишет определения правил, можно легко проигнорировать. Вы можете добавить исключения для правила 1, затем 2, затем три ... пока оно не устареет. Затем вы просто деактивируете эту функцию.
Что ваши менеджеры говорят о том, что «несколько тысяч низкоприоритетных проблем не решены»?
Я ожидаю, что менеджеры расставят приоритеты: чтобы решить (или получить ответ), является ли какая-либо задача высокой- или низкоприоритетные, и радоваться тому, что люди тратят время на высокоприоритетные, а не на низкоприоритетные задачи.
Ключевой момент, на мой взгляд, заключается в том, чтобы по крайней мере рассмотреть все проблемы, даже если в итоге вы решите не исправлять их. Причина в том, что ошибки, как и несчастья, любят компанию. Я не могу перечислить, сколько раз я находил всевозможные неприятные ошибки, о которых findbugs не сообщал, но находил их, глядя на, казалось бы, неважные ошибки, о которых он сообщал.
Решите, каким правилам вы хотите следовать в своей компании, и отключите остальные. Многие правил, которые вы можете установить с помощью этих инструментов, представляют собой проблемы субъективного стиля, и их можно безопасно игнорировать. Вы должны задокументировать, каким правилам вы следуете один раз в руководстве по стилю компании (чтобы вы не загромождали свой код этой информацией).
Я бы не стал вносить изменения в старый код только по рекомендации инструмента статического анализа. Этот код уже протестирован и предположительно работает. Если мне нужно войти в код и внести изменения по какой-либо другой причине, , затем я проведу анализ и внесу любые изменения, которые он рекомендует.
Если вы посмотрите на аналогию с вашей базой данных отслеживания ошибок, то большая часть из них - это ошибки с низким приоритетом, до которых вы, вероятно, никогда не доберетесь. Конечно, это настоящие ошибки, и вы хотели бы их исправить, но большинство программистов работают с очень реальными ограничениями, и у них нет времени для решения всех проблем. Недавно я написал статью о особой природе дефектов статического анализа .
Одно из важных отличий в устранении ошибок статического анализа состоит в том, что с ними обычно гораздо легче бороться, чем с регулярно сообщаемой ошибкой. Таким образом, может быть полезно быстрое сканирование дефектов, чтобы определить не только элементы с высоким приоритетом, которые необходимо исправить, но и те, которые легче всего исправить.В конце концов, дефекты статического анализа обнаруживаются очень рано в процессе разработки, и конкретные части рассматриваемого кода очень четко прописаны. Таким образом, вы, вероятно, поймаете довольно много низко висящих фруктов на фруктах с более низким приоритетом.
Различные стратегии, которые я видел, чтобы добиться успеха, включают: * Прежде всего, убедитесь, что анализ настроен правильно. Статический анализ идет «из коробки» с заводскими настройками и не может понять весь код. Если вы не можете настроить его самостоятельно, обратитесь за помощью (отказ от ответственности, мы предоставляем некоторую помощь такого рода). Вы снизите количество ложных срабатываний и найдете больше хороших ошибок. * Определите характеристики, которые по большей части определяют приоритет дефектов (это могут быть определенные категории, определенные области кода, встроенная оценка приоритета, предоставляемая инструментом статического анализа, и т. Д.). * Определите, какой уровень порога важен, и, возможно, сделайте его критерием приемлемости (например, все высокие и критические потребности должны быть устранены) * Удостоверьтесь, что каждый дефект, который блокирует критерии приемки, исправлен (устранен, что означает, что его, по крайней мере, необходимо рассмотреть, потому что некоторые из них могут быть ложными срабатываниями) * Убедитесь, что те, которые помечены как ложные срабатывания, проверены либо с помощью процесса проверки партнерского кода, либо с помощью процесса конечного аудита, чтобы у вас не возникло никаких проблем с неправильной маркировкой.
Итог: выберите, на чем сосредоточить внимание, проанализируйте то, что необходимо, не исправляйте все, если вас не требуют бизнес-требования