Иван, как и писал выше, прокомментирую три момента из статьи. Те, что не комментирую – я с ними согласен значит.
Стандартная последовательность этапов этого конвейера выглядит так
Я не согласен, что первый шаг – это статический анализ, а только второй компиляция. Я считаю, что проверка компиляции в среднем быстрее и логичнее, чем сразу гонять «более тяжелый» статический анализ. Можем подискутировать, если думаете иначе.
Мне не довелось работать в PVS-studio, что касается моего опыта с Codacy, то основная их проблема заключается в том, что определение что есть «старая», а что «новая» ошибка — довольно сложный и не всегда правильно работающий алгоритм, особенно если файлы сильно изменяются или переименовываются.
В PVS-Studio это сделано офигенно удобно. Это одна из киллер-фич продукта, про которую, к сожалению, трудно писать статьи, поэтому ее мало знают. Мы сохраняем в базу информацию о имеющихся ошибках. Причем не просто «имя файла и строка», но и дополнительную информацию (хеши трех строк – текущая, предыдущая, следующая), чтобы в случае сдвига фрагмента кода мы его все-равно могли найти. Таким образом при незначительных модификациях мы все-равно понимаем, что это старая ошибка. И не ругаемся на нее. И теперь кто-то может сказать: «Ага, а если код сильно изменился, то значит это не сработает, и вы на него ругаетесь как на новый?» Да. Ругаемся. Но это и есть новый код. Если код сильно изменился, то это новый код, а не старый.
Благодаря этой фиче мы лично участвовали во внедрении в проект с 10 млн строк C++ кода, который каждый день «трогает» куча программистов. Все без проблем прошло.
Так что мы рекомендуем использовать эту фичу в PVS-Studio всем, кто внедряет статический анализ в свой процесс.
Вариант с фиксацией количества срабатываний относительно релиза – мне он намного менее симпатичен…
каким бы образом вы бы ни внедряли анализ в ваш конвейер поставки, версия анализатора должна быть фиксирована.
Не могу согласится. Категорический противник этого подхода. Я рекомендую всем обновляться на анализатор в автоматическом режиме. Так как мы добавляем новые диагностики и улучшаем старые. Почему? Во-первых, вы получите срабатывания на новые реальные ошибки. Во-вторых, часть старых срабатываний возможно пропадет, если мы их побороли.
Не обновлять анализатор – это как не обновлять антивирусные базы («А вдруг начнут про вирусы писать»). Не будем правда здесь обсуждать целесообразность антивирусов в целом.
Если после обновления версии анализатора у вас много новых срабатываний – подавите их, как я писал выше через эту функцию. Но не обновлять версию… Как правило, такие клиенты (они конечно есть) не обновляют версию годами. Им все некогда. Они ПЛАТЯТ за продление лицензии, но не пользуются новыми версиями. Почему? Потому что когда-то они решили зафиксировать версию. Но продукт сегодня и продукт три года назад – это небо и земля. А так получается «куплю билет, но не поеду».
Иван, спасибо за статью и за то, что помогаете нам делать нашу работу – популяризовать технологию статического анализа кода.
Вы абсолютно правы, что статьи из блога PVS-Studio действуя на неокрепшие умы могут привести именно к таким выводам, что «проверю разок, исправлю ошибки и будет хорошо».
Это моя личная боль, которую я не знаю как победить уже несколько лет. Дело в том, что статьи про проверку проектов:
Вызывают вау-эффект у людей. Людям нравится читать как косячат разработчики в Google, Epic Games, Microsoft и других компаниях. Людям приятно думать, что не только они сами ошибаются, но и лидеры индустрии делают ошибки. Люди любят читать такие статьи.
Можно писать на потоке, к тому же не сильно думая. Я не хочу оскорбить конечно же наших ребят, которые пишут эти статьи. Но придумывать каждый раз принципиально новую статью намного сложнее, чем написать статью о проверке проекта (десяток ошибок, пару шуток, разбавить картинками единорогов).
Вы написали очень хорошую статью. У меня тоже есть парочка статей на эту тему. И у других коллег. Более того, я езжу с докладом по компаниям с темой «Философия статического анализа кода», где рассказываю именно про процесс, а не конкретные найденные ошибки.
Но не возможно написать 10 статей про процесс. А нам для популяризации продукта надо писать регулярно и много.
Прокомментирую еще несколько моментов из статьи отдельным комментариев, чтобы удобнее дискуссию вести было.
Комментарий для сторонних читаталей, Тагир сам это и так знает конечно.
Вообще все сообщения анализатора следует воспринимать как «Здесь что-то подозрительное, кажется вот это, но не уверен. Проверьте.» Очень нередки ситуации, когда анализатора об ошибке говорит не теми словами, которыми хотелось бы. Но он говорит все же об ошибке.
Когда меня спрашивают о том, не сошли ли мы с ума делая статический анализатор кода для Java, я как никогда спокоен и уверен в себе. Да, IDEA – the best (ни капли сарказма), а разработчики из JetBrains – элита индустрии. В этом нет сомнений и мы не претендуем на это.
Но статический анализ кода – это не только собственно технологии анализа кода. Как построить дерево разбора и как по нему пробежаться знают многие. В конце концов это описано в книгах!
Статический анализ кода – это еще и инфраструктура, то есть куча вспомогательных инструментов. Это и методология использования, и, главное, методология внедрения. Философия статического анализа кода – это как потратить деньги на статический анализ с пользой.
Многие думают, что статический анализ – это вот статьи моих коллег про «смотрите какую ошибку мы нашли в Chrome». Это все прикольно, вызывает интерес аудитории, но это вишенка на торте. Сам же торт намного больше и вкуснее.
Этой темой мы занимаемся более 10 лет. И мы в ней сильны. Поэтому нет, я не боюсь конкуренции ни с JetBrains, ни с SonarQube, ни с кем-либо еще. В этой области у нас есть крутейшая экспертиза. Это знаю я, знает команда и знают те клиенты, которые из года в год продлевают лицензии на PVS-Studio.
Про это я кстати подробно буду рассказывать на конференциях по Java в 2019 году. Приходите на наши доклады!
И, Тагир, огромное спасибо за участие в бета-тестировании! Ребята до сих пор разбирают кучу комментариев и рекомендаций, до релиза не все успели проработать разумеется.
Как правило нет цели «сравнивать отчеты». Есть цель видеть новые ошибки. Этот механизм существует. Чтобы дать конкретные ссылки опишите свой сценарий использования.
Хотя этот комментарий относится видимо к двум упомянутым анализаторам, все-таки не могу пройти мимо. Так как кто-то может подумать, что все «линтеры» такие. А между тем коллега недавно опубликовал статью с как раз таким текстом:
Существуют заблуждения, что статические анализаторы кода — это достаточно простые программы, в основе которых лежит поиск паттернов кода с помощью регулярных выражений. Это далеко от истины. Более того, выявление подавляющего большинства ошибок с помощью регулярных выражений просто невозможно.
> Основная проблема в том, что они не понимают, зачем MISRA вообще нужна!
Расскажите нам, что мы должны реализовать, чтобы вы стали нашим клиентом? Как я писал выше, намного продуктивнее делать что-то под конкретного клиента.
> В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта.
Давайте напишем совместную статью про это? Ваш взляд и наш? Можно в форме интервью. Все пользая будет!
Я не согласен, что первый шаг – это статический анализ, а только второй компиляция. Я считаю, что проверка компиляции в среднем быстрее и логичнее, чем сразу гонять «более тяжелый» статический анализ. Можем подискутировать, если думаете иначе.
В PVS-Studio это сделано офигенно удобно. Это одна из киллер-фич продукта, про которую, к сожалению, трудно писать статьи, поэтому ее мало знают. Мы сохраняем в базу информацию о имеющихся ошибках. Причем не просто «имя файла и строка», но и дополнительную информацию (хеши трех строк – текущая, предыдущая, следующая), чтобы в случае сдвига фрагмента кода мы его все-равно могли найти. Таким образом при незначительных модификациях мы все-равно понимаем, что это старая ошибка. И не ругаемся на нее. И теперь кто-то может сказать: «Ага, а если код сильно изменился, то значит это не сработает, и вы на него ругаетесь как на новый?» Да. Ругаемся. Но это и есть новый код. Если код сильно изменился, то это новый код, а не старый.
Благодаря этой фиче мы лично участвовали во внедрении в проект с 10 млн строк C++ кода, который каждый день «трогает» куча программистов. Все без проблем прошло.
Так что мы рекомендуем использовать эту фичу в PVS-Studio всем, кто внедряет статический анализ в свой процесс.
Вариант с фиксацией количества срабатываний относительно релиза – мне он намного менее симпатичен…
Не могу согласится. Категорический противник этого подхода. Я рекомендую всем обновляться на анализатор в автоматическом режиме. Так как мы добавляем новые диагностики и улучшаем старые. Почему? Во-первых, вы получите срабатывания на новые реальные ошибки. Во-вторых, часть старых срабатываний возможно пропадет, если мы их побороли.
Не обновлять анализатор – это как не обновлять антивирусные базы («А вдруг начнут про вирусы писать»). Не будем правда здесь обсуждать целесообразность антивирусов в целом.
Если после обновления версии анализатора у вас много новых срабатываний – подавите их, как я писал выше через эту функцию. Но не обновлять версию… Как правило, такие клиенты (они конечно есть) не обновляют версию годами. Им все некогда. Они ПЛАТЯТ за продление лицензии, но не пользуются новыми версиями. Почему? Потому что когда-то они решили зафиксировать версию. Но продукт сегодня и продукт три года назад – это небо и земля. А так получается «куплю билет, но не поеду».
Вы абсолютно правы, что статьи из блога PVS-Studio действуя на неокрепшие умы могут привести именно к таким выводам, что «проверю разок, исправлю ошибки и будет хорошо».
Это моя личная боль, которую я не знаю как победить уже несколько лет. Дело в том, что статьи про проверку проектов:
Вы написали очень хорошую статью. У меня тоже есть парочка статей на эту тему. И у других коллег. Более того, я езжу с докладом по компаниям с темой «Философия статического анализа кода», где рассказываю именно про процесс, а не конкретные найденные ошибки.
Но не возможно написать 10 статей про процесс. А нам для популяризации продукта надо писать регулярно и много.
Прокомментирую еще несколько моментов из статьи отдельным комментариев, чтобы удобнее дискуссию вести было.
Вообще все сообщения анализатора следует воспринимать как «Здесь что-то подозрительное, кажется вот это, но не уверен. Проверьте.» Очень нередки ситуации, когда анализатора об ошибке говорит не теми словами, которыми хотелось бы. Но он говорит все же об ошибке.
Когда меня спрашивают о том, не сошли ли мы с ума делая статический анализатор кода для Java, я как никогда спокоен и уверен в себе. Да, IDEA – the best (ни капли сарказма), а разработчики из JetBrains – элита индустрии. В этом нет сомнений и мы не претендуем на это.
Но статический анализ кода – это не только собственно технологии анализа кода. Как построить дерево разбора и как по нему пробежаться знают многие. В конце концов это описано в книгах!
Статический анализ кода – это еще и инфраструктура, то есть куча вспомогательных инструментов. Это и методология использования, и, главное, методология внедрения. Философия статического анализа кода – это как потратить деньги на статический анализ с пользой.
Многие думают, что статический анализ – это вот статьи моих коллег про «смотрите какую ошибку мы нашли в Chrome». Это все прикольно, вызывает интерес аудитории, но это вишенка на торте. Сам же торт намного больше и вкуснее.
Этой темой мы занимаемся более 10 лет. И мы в ней сильны. Поэтому нет, я не боюсь конкуренции ни с JetBrains, ни с SonarQube, ни с кем-либо еще. В этой области у нас есть крутейшая экспертиза. Это знаю я, знает команда и знают те клиенты, которые из года в год продлевают лицензии на PVS-Studio.
Про это я кстати подробно буду рассказывать на конференциях по Java в 2019 году. Приходите на наши доклады!
И, Тагир, огромное спасибо за участие в бета-тестировании! Ребята до сих пор разбирают кучу комментариев и рекомендаций, до релиза не все успели проработать разумеется.
Да уж, и правда «намного проще»…
в коде ошибка.
Похоже взята новая планка уровня статей про проверку кода. Кто готов хотя бы повторить?
> Основная проблема в том, что они не понимают, зачем MISRA вообще нужна!
Расскажите нам, что мы должны реализовать, чтобы вы стали нашим клиентом? Как я писал выше, намного продуктивнее делать что-то под конкретного клиента.
> В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта.
Давайте напишем совместную статью про это? Ваш взляд и наш? Можно в форме интервью. Все пользая будет!