Иногда люди задают вопрос, который, на первый взгляд, про одно, а на самом деле про другое. Как говорится, грамотно поставленный вопрос содержит половину ответа.На днях я вернулся с конференции JPoint, на которой впервые был представлен наш новый анализатор PVS-Studio для Java. Интерес к статическому анализу сильно растет в последние несколько лет, поэтому аудитория восприняла PVS-Studio на ура. Кроме положительных откликов, естественно, пришлось и поработать с возражениями. Самое частое возражение на предложение попробовать PVS-Studio звучит так: «Да ладно, зачем нам пробовать PVS-Studio? Мы используем IntelliJ IDEA, ReSharper, SonarLint и SonarQube. Вот мы запустили недавно PVS-Studio, и он нашел ошибки, которые и так подсвечивает IntelliJ IDEA!»
Я просто не могу не написать небольшую заметку-ответ на этот комментарий. Точнее, у меня даже два ответа на это возражение. И да, я специально указал здесь ReSharper, так как к нашему анализатору для C# такие вопросы тоже имеют место. Что ж, с радостью отвечу.
Во-первых, мы НЕ делаем PVS-Studio, копируя диагностики конкурентов. Слепое копирование без понимания сути ведет в никуда. Ценность статического анализа кода, ценность его диагностик не в том, где выдавать ошибку. А в том, где ее НЕ выдавать. На каждую из наших диагностик у нас есть 10, 20, а то и больше исключений, когда срабатывать не надо. Копировать диагностики из других продуктов только по их описанию в документации — это как пытаться построить такое же здание по одной фотографии. Сильно фото Колизея поможет вам, если вдруг «боги заставят» вас построить такой же?
Поэтому мы никогда не копируем. «Но ведь у вас есть одинаковые диагностики!» — скажете вы. Конечно есть. Идеи многих ошибок лежат на поверхности. Это абсолютно очевидно. Но часто диагностики с одинаковым описанием даже ведут себя по-разному.
Другими словами, если вы используете какой-то из указанных в заголовке продуктов, то при запуске PVS-Studio очень может быть, что вы найдете кучу НОВЫХ ошибок, которые не обнаруживались другими продуктами. Опыт наших клиентов и опыт проверки открытых проектов это подтверждает.
Во-вторых, даже если вы используете IntelliJ IDEA, ReSharper и SonarLint/SonarQube, и они находят в вашем коде такие же ошибки, что и PVS-Studio, то у меня для вас плохие новости. Вы используете инструменты, которые находят ошибки, OK. Но почему PVS-Studio находит ошибки в вашем коде, которые, вроде как, находятся всеми этими инструментами? Почему при использовании инструментов, которые «точно так же, как и PVS-Studio все найдут», ошибки не исправлены? Может быть эти инструменты ПОЗВОЛЯЮТ их не править?
И IntelliJ IDEA, и ReSharper и SonarLint с SonarQube очень хорошие инструменты. Их делают высококвалифицированные команды. И если вы их используете — вы все делаете правильно. Чем выше уровень инженерной культуры на проекте, тем лучше для бизнеса.
Но если все эти инструменты «находят те же ошибки, что и PVS-Studio», и ошибки все еще в коде, то вы что-то делаете не так. Внедрите в команде такую практику, как регулярное использование PVS-Studio. И тогда ошибки будут не только находиться, но и исправляться. Внедрение PVS-Studio ЗАСТАВИТ разработчиков исправлять ошибки. А не только находить их.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Evgeniy Ryzhkov. IntelliJ IDEA, ReSharper, SonarLint and SonarQube find the same errors, as PVS-Studio — so why do we need PVS-Studio?
Комментарии (24)
lany
24.04.2019 06:35+1Ценность статического анализа кода, ценность его диагностик не в том, где выдавать ошибку. А в том, где ее НЕ выдавать. На каждую из наших диагностик у нас есть 10, 20, а то и больше исключений, когда срабатывать не надо.
Звучит так будто конкуренты этого не делают. А это, разумеется, не так. И насчёт 10 исключений в каждой диагностике вы, конечно, привираете. Есть простые кейсы, где пара граничных случаев всё описывает.
EvgeniyRyzhkov Автор
24.04.2019 06:38-1Этот параграф вообще не про конкурентов. Увы, пользователи инструментов анализа кода не понимают важности исключений зачастую.
anprs
24.04.2019 09:55А существует какая-нибудь PVS-Studio Community Edition?
Andrey2008
24.04.2019 10:02
technic93
24.04.2019 11:08Только гитхаб и битбакет, а гитлаб.ком можно?
Andrey2008
24.04.2019 11:40Нет.
technic93
24.04.2019 12:38Жаль, а почему не расскажете? Потому что гитлаб легко перенести потом на приватный хостинг? Спасибо за ответ.
aamonster
Э… Если команда не исправила ошибку, найденную другим инструментом – почему «регулярное использование PVS-Studio» заставит её исправить? (а не введение правила «исправлять всё, что найдено использующимся инструментом»)
EvgeniyRyzhkov Автор
Потому что мы помогаем построить процессы разработки при внедрении инструмента так, чтобы такой ситуации не возникало.
aamonster
Ну то есть основным всё-таки является не конкретный инструмент (и может использоваться и один из перечисленных в статье или ещё какой-то), а процесс (когда все подозрительные места кода изолируются, проверяются и исправляются или помечаются)?
И преимуществ вашего инструмента (а не отдельного от него процесса) вы в этой статье не раскрыли?
(прошу не воспринимать как критику инструмента, насколько я могу судить – он хорош, да и ваши разборы ошибок на Хабре очень радуют)
EvgeniyRyzhkov Автор
Да, за 10+ лет мы поняли, что процесс важнее, чем инструмент. Мы видели кучу неудачных внедрений PVS-Studio, когда компании теряли деньги в итоге. Поэтому поняли, что нельзя пускать это на самотек и ждать, что компании сами разберуться как правильно использовать инструмент.
Плохой инструмент плюс хороший процесс намного лучше, чем хороший инструмент, но плохой процесс.
j8kin
Переведу:
SonarQube тоже можно встроить в процесс CI, что мешает НЕ встраивать ваш PVS-Studio в этот процесс и продолжать забивать болт на найденные ошибки и ли тупо откладывать их в долгий ящик считая, что все ок, надо накидать функциональность.
Если команда/компания не готова, то хоть тресни — не поможет нужен драйвер этого процесса в команде, если его нет, то «кина не будет».
EvgeniyRyzhkov Автор
Самая распространенная ошибка — кто-то где-то на сервере установил SonarQube или еще что-то и теперь в компании думают, что у них налажен статический анализ кода.
А то, что никто не смотрит на ошибки, не поддерживает SonarQube, не следит за результатами проверок — как-то выпадает…
j8kin
Если не давать мерджить если Сонар Падает с Major ошибками в ветке, то люди будут вынуждены их исправлять.
Я выше написал, что нужен тот, кто будет вести этот процесс и не важно какая именно тула будет использоваться.
EvgeniyRyzhkov Автор
Мы настоятельно НЕ рекомендуем блокировать коммиты по результатам анализа кода. Однажды возникнет ситуация, когда НАДО закоммитить, но анализатор будет блокировать это. И тогда возникнет соблазн его отключить. И не включать потом. Должны быть другие меры для того, чтобы существование ошибок анализатора было некомфортным в команде.
SirEdvin
Эм… а вы уверены? Каждое срабатывание анализа кода — это потенциальный пахнущий код или даже бага. Это звучит как предложение не блокировать коммиты по результам тестов.
Или вы имеете ввиду разницу между «коммит» и «влить код в dev ветку»?
EvgeniyRyzhkov Автор
Давайте я отвечу так. Мы настоятельно рекомендуем не маньячить. Как это реализовать технически — бывают разные варианты.
Причина в том, что если маньячить, то рано или поздно инструмент отключать «на минуточку» и потом не включат.
leotsarev
Но ведь можно всегда подавить кокнретный варнинг в конкретном коммите комментарием с объяснением?
EvgeniyRyzhkov Автор
Тут надо понимать контекст ситуации.
Я говорю о сценарии, когда в компании несколько десятков или сотен человек используют статический анализ (лично или на билд-сервере). Если при таком количестве людей мы говорим о том, что «можно легко подавить и пропихнуть свои правки», то велик соблазн у людей не разбираться с сообщениями анализатора, а просто «давить их».
Вы не представляете как часто письма нам начинаются со слов «у вас тут ложное срабатывание», а заканчиваются «ой, круто, действительно оказывается ошибка!». Вы скажете: «Плохой анализатор значит!»? Да, не идеальный. Как и вся наша жизнь.
alexesDev
Думаю ответ где-то рядом с «цена на порядок или два больше».
EvgeniyRyzhkov Автор
Хорошая попытка, но нет. :)
Увы, решения за миллионы часто также оказываются выброшенными на помойку из-за того, что их неправильно внедряют. Я без конкретики какой-то это пишу, а в целом.
alexesDev
У меня же хитрый комент. Цена попыше часто значит лучшую поддержку, а не «держите тул за 130 и доку» =) А по ответу… если команда будет упорно сопротивляеться, то вы откажитесь от затеи и вернёте $?
Я проверял c++ opensource с помощью PVS-studio, понимаю, что оно на раз два заезжает в ci и уже ней уйти, но все же, мало ли бывает.
EvgeniyRyzhkov Автор
> А по ответу… если команда будет упорно сопротивляеться, то вы откажитесь от затеи и вернёте $?
«Вернете $» — это отказ от работы. Мы делаем так, чтобы возвращать было не надо.
SirEdvin
На самом деле — ничего. Как мне кажется, реально нет никакого смысла не вводить правило «исправлять всё, что найдено использующимся инструментом» прямо на месте, отключая ложные срабатывания.