Comments 24
Э… Если команда не исправила ошибку, найденную другим инструментом – почему «регулярное использование PVS-Studio» заставит её исправить? (а не введение правила «исправлять всё, что найдено использующимся инструментом»)
Потому что мы помогаем построить процессы разработки при внедрении инструмента так, чтобы такой ситуации не возникало.
Ну то есть основным всё-таки является не конкретный инструмент (и может использоваться и один из перечисленных в статье или ещё какой-то), а процесс (когда все подозрительные места кода изолируются, проверяются и исправляются или помечаются)?
И преимуществ вашего инструмента (а не отдельного от него процесса) вы в этой статье не раскрыли?
(прошу не воспринимать как критику инструмента, насколько я могу судить – он хорош, да и ваши разборы ошибок на Хабре очень радуют)
И преимуществ вашего инструмента (а не отдельного от него процесса) вы в этой статье не раскрыли?
(прошу не воспринимать как критику инструмента, насколько я могу судить – он хорош, да и ваши разборы ошибок на Хабре очень радуют)
Да, за 10+ лет мы поняли, что процесс важнее, чем инструмент. Мы видели кучу неудачных внедрений PVS-Studio, когда компании теряли деньги в итоге. Поэтому поняли, что нельзя пускать это на самотек и ждать, что компании сами разберуться как правильно использовать инструмент.
Плохой инструмент плюс хороший процесс намного лучше, чем хороший инструмент, но плохой процесс.
Плохой инструмент плюс хороший процесс намного лучше, чем хороший инструмент, но плохой процесс.
Переведу:
SonarQube тоже можно встроить в процесс CI, что мешает НЕ встраивать ваш PVS-Studio в этот процесс и продолжать забивать болт на найденные ошибки и ли тупо откладывать их в долгий ящик считая, что все ок, надо накидать функциональность.
Если команда/компания не готова, то хоть тресни — не поможет нужен драйвер этого процесса в команде, если его нет, то «кина не будет».
SonarQube тоже можно встроить в процесс CI, что мешает НЕ встраивать ваш PVS-Studio в этот процесс и продолжать забивать болт на найденные ошибки и ли тупо откладывать их в долгий ящик считая, что все ок, надо накидать функциональность.
Если команда/компания не готова, то хоть тресни — не поможет нужен драйвер этого процесса в команде, если его нет, то «кина не будет».
Самая распространенная ошибка — кто-то где-то на сервере установил SonarQube или еще что-то и теперь в компании думают, что у них налажен статический анализ кода.
А то, что никто не смотрит на ошибки, не поддерживает SonarQube, не следит за результатами проверок — как-то выпадает…
А то, что никто не смотрит на ошибки, не поддерживает SonarQube, не следит за результатами проверок — как-то выпадает…
Если не давать мерджить если Сонар Падает с Major ошибками в ветке, то люди будут вынуждены их исправлять.
Я выше написал, что нужен тот, кто будет вести этот процесс и не важно какая именно тула будет использоваться.
Я выше написал, что нужен тот, кто будет вести этот процесс и не важно какая именно тула будет использоваться.
Мы настоятельно НЕ рекомендуем блокировать коммиты по результатам анализа кода. Однажды возникнет ситуация, когда НАДО закоммитить, но анализатор будет блокировать это. И тогда возникнет соблазн его отключить. И не включать потом. Должны быть другие меры для того, чтобы существование ошибок анализатора было некомфортным в команде.
Эм… а вы уверены? Каждое срабатывание анализа кода — это потенциальный пахнущий код или даже бага. Это звучит как предложение не блокировать коммиты по результам тестов.
Или вы имеете ввиду разницу между «коммит» и «влить код в dev ветку»?
Или вы имеете ввиду разницу между «коммит» и «влить код в dev ветку»?
Но ведь можно всегда подавить кокнретный варнинг в конкретном коммите комментарием с объяснением?
Тут надо понимать контекст ситуации.
Я говорю о сценарии, когда в компании несколько десятков или сотен человек используют статический анализ (лично или на билд-сервере). Если при таком количестве людей мы говорим о том, что «можно легко подавить и пропихнуть свои правки», то велик соблазн у людей не разбираться с сообщениями анализатора, а просто «давить их».
Вы не представляете как часто письма нам начинаются со слов «у вас тут ложное срабатывание», а заканчиваются «ой, круто, действительно оказывается ошибка!». Вы скажете: «Плохой анализатор значит!»? Да, не идеальный. Как и вся наша жизнь.
Я говорю о сценарии, когда в компании несколько десятков или сотен человек используют статический анализ (лично или на билд-сервере). Если при таком количестве людей мы говорим о том, что «можно легко подавить и пропихнуть свои правки», то велик соблазн у людей не разбираться с сообщениями анализатора, а просто «давить их».
Вы не представляете как часто письма нам начинаются со слов «у вас тут ложное срабатывание», а заканчиваются «ой, круто, действительно оказывается ошибка!». Вы скажете: «Плохой анализатор значит!»? Да, не идеальный. Как и вся наша жизнь.
Думаю ответ где-то рядом с «цена на порядок или два больше».
Хорошая попытка, но нет. :)
Увы, решения за миллионы часто также оказываются выброшенными на помойку из-за того, что их неправильно внедряют. Я без конкретики какой-то это пишу, а в целом.
Увы, решения за миллионы часто также оказываются выброшенными на помойку из-за того, что их неправильно внедряют. Я без конкретики какой-то это пишу, а в целом.
У меня же хитрый комент. Цена попыше часто значит лучшую поддержку, а не «держите тул за 130 и доку» =) А по ответу… если команда будет упорно сопротивляеться, то вы откажитесь от затеи и вернёте $?
Я проверял c++ opensource с помощью PVS-studio, понимаю, что оно на раз два заезжает в ci и уже ней уйти, но все же, мало ли бывает.
Я проверял c++ opensource с помощью PVS-studio, понимаю, что оно на раз два заезжает в ci и уже ней уйти, но все же, мало ли бывает.
На самом деле — ничего. Как мне кажется, реально нет никакого смысла не вводить правило «исправлять всё, что найдено использующимся инструментом» прямо на месте, отключая ложные срабатывания.
Ценность статического анализа кода, ценность его диагностик не в том, где выдавать ошибку. А в том, где ее НЕ выдавать. На каждую из наших диагностик у нас есть 10, 20, а то и больше исключений, когда срабатывать не надо.
Звучит так будто конкуренты этого не делают. А это, разумеется, не так. И насчёт 10 исключений в каждой диагностике вы, конечно, привираете. Есть простые кейсы, где пара граничных случаев всё описывает.
А существует какая-нибудь PVS-Studio Community Edition?
Sign up to leave a comment.
IntelliJ IDEA, ReSharper, SonarLint и SonarQube находят те же ошибки, что и PVS-Studio — ну и зачем нам PVS-Studio?