IntelliJ IDEA, ReSharper, SonarLint и SonarQube находят те же ошибки, что и PVS-Studio — ну и зачем нам PVS-Studio?

    Picture 1Иногда люди задают вопрос, который, на первый взгляд, про одно, а на самом деле про другое. Как говорится, грамотно поставленный вопрос содержит половину ответа.

    На днях я вернулся с конференции 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?
    PVS-Studio
    346,00
    Static Code Analysis for C, C++, C# and Java
    Поделиться публикацией

    Похожие публикации

    Комментарии 24

      +4
      Э… Если команда не исправила ошибку, найденную другим инструментом – почему «регулярное использование PVS-Studio» заставит её исправить? (а не введение правила «исправлять всё, что найдено использующимся инструментом»)
        0
        Потому что мы помогаем построить процессы разработки при внедрении инструмента так, чтобы такой ситуации не возникало.
          +5
          Ну то есть основным всё-таки является не конкретный инструмент (и может использоваться и один из перечисленных в статье или ещё какой-то), а процесс (когда все подозрительные места кода изолируются, проверяются и исправляются или помечаются)?
          И преимуществ вашего инструмента (а не отдельного от него процесса) вы в этой статье не раскрыли?

          (прошу не воспринимать как критику инструмента, насколько я могу судить – он хорош, да и ваши разборы ошибок на Хабре очень радуют)
            +2
            Да, за 10+ лет мы поняли, что процесс важнее, чем инструмент. Мы видели кучу неудачных внедрений PVS-Studio, когда компании теряли деньги в итоге. Поэтому поняли, что нельзя пускать это на самотек и ждать, что компании сами разберуться как правильно использовать инструмент.

            Плохой инструмент плюс хороший процесс намного лучше, чем хороший инструмент, но плохой процесс.
            +2
            Переведу:
            SonarQube тоже можно встроить в процесс CI, что мешает НЕ встраивать ваш PVS-Studio в этот процесс и продолжать забивать болт на найденные ошибки и ли тупо откладывать их в долгий ящик считая, что все ок, надо накидать функциональность.
            Если команда/компания не готова, то хоть тресни — не поможет нужен драйвер этого процесса в команде, если его нет, то «кина не будет».
              +1
              Самая распространенная ошибка — кто-то где-то на сервере установил SonarQube или еще что-то и теперь в компании думают, что у них налажен статический анализ кода.

              А то, что никто не смотрит на ошибки, не поддерживает SonarQube, не следит за результатами проверок — как-то выпадает…
                +2
                Если не давать мерджить если Сонар Падает с Major ошибками в ветке, то люди будут вынуждены их исправлять.
                Я выше написал, что нужен тот, кто будет вести этот процесс и не важно какая именно тула будет использоваться.
                  0
                  Мы настоятельно НЕ рекомендуем блокировать коммиты по результатам анализа кода. Однажды возникнет ситуация, когда НАДО закоммитить, но анализатор будет блокировать это. И тогда возникнет соблазн его отключить. И не включать потом. Должны быть другие меры для того, чтобы существование ошибок анализатора было некомфортным в команде.
                    +1
                    Эм… а вы уверены? Каждое срабатывание анализа кода — это потенциальный пахнущий код или даже бага. Это звучит как предложение не блокировать коммиты по результам тестов.

                    Или вы имеете ввиду разницу между «коммит» и «влить код в dev ветку»?
                      +2
                      Давайте я отвечу так. Мы настоятельно рекомендуем не маньячить. Как это реализовать технически — бывают разные варианты.

                      Причина в том, что если маньячить, то рано или поздно инструмент отключать «на минуточку» и потом не включат.
                      +1

                      Но ведь можно всегда подавить кокнретный варнинг в конкретном коммите комментарием с объяснением?

                        +1
                        Тут надо понимать контекст ситуации.

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

                        Вы не представляете как часто письма нам начинаются со слов «у вас тут ложное срабатывание», а заканчиваются «ой, круто, действительно оказывается ошибка!». Вы скажете: «Плохой анализатор значит!»? Да, не идеальный. Как и вся наша жизнь.
              0
              Думаю ответ где-то рядом с «цена на порядок или два больше».
                0
                Хорошая попытка, но нет. :)

                Увы, решения за миллионы часто также оказываются выброшенными на помойку из-за того, что их неправильно внедряют. Я без конкретики какой-то это пишу, а в целом.
                  0
                  У меня же хитрый комент. Цена попыше часто значит лучшую поддержку, а не «держите тул за 130 и доку» =) А по ответу… если команда будет упорно сопротивляеться, то вы откажитесь от затеи и вернёте $?

                  Я проверял c++ opensource с помощью PVS-studio, понимаю, что оно на раз два заезжает в ci и уже ней уйти, но все же, мало ли бывает.
                    0
                    > А по ответу… если команда будет упорно сопротивляеться, то вы откажитесь от затеи и вернёте $?

                    «Вернете $» — это отказ от работы. Мы делаем так, чтобы возвращать было не надо.
                +2
                На самом деле — ничего. Как мне кажется, реально нет никакого смысла не вводить правило «исправлять всё, что найдено использующимся инструментом» прямо на месте, отключая ложные срабатывания.
                +1
                Ценность статического анализа кода, ценность его диагностик не в том, где выдавать ошибку. А в том, где ее НЕ выдавать. На каждую из наших диагностик у нас есть 10, 20, а то и больше исключений, когда срабатывать не надо.

                Звучит так будто конкуренты этого не делают. А это, разумеется, не так. И насчёт 10 исключений в каждой диагностике вы, конечно, привираете. Есть простые кейсы, где пара граничных случаев всё описывает.

                  0
                  Этот параграф вообще не про конкурентов. Увы, пользователи инструментов анализа кода не понимают важности исключений зачастую.
                  0
                  А существует какая-нибудь PVS-Studio Community Edition?

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое