Если вы считаете себя хорошим программистом, ну, скажем так, вы оцениваете свой уровень выше среднего, прошу не читать эту статью. Эта статья предназначена для менеджеров программных проектов. С ними я хочу обсудить хотя и важные, но скучные для программистов вопросы, связанные с методологией статического анализа кода.
Надеюсь, введение отпугнуло от чтения хотя бы некоторых программистов. Кто-то, наверное, из принципа продолжил чтение, но что ж, это их добровольный выбор. Мы поговорим о вещах, которые неприятны программистам.
Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.
Любому менеджеру, да и самим программистам понятно, что качественный код лучше, чем некачественный. Понятно и то, что чем реже в программе проявляются глюки, тем лучше.
Самое интересное начинается дальше. Хотя все признают важность качественного кода, некоторые программисты приходят просто в негодование, когда им предлагают использовать статический анализ кода. Такое впечатление, что их оскорбили, усомнившись в их профессионализме, и они спешат ответить всем арсеналом своей негативной критики. За годы мы услышали огромное количество нелестных отзывов, приблизительно следующего содержания:
- «это инструмент для Макдональдса, а в нашей команде работают эксперты, и если у нас и бывают ошибки, то они связаны только с синхронизацией потоков»
- «мы не используем статический анализ кода, так как набираем только профессионалов выше среднего»
Думаю, если бы в момент таких дискуссий рядом присутствовал менеджер проекта, то немало программистов получило от него щелбан за гордыню. Каждый руководитель может вспомнить, как несколько дней искали ошибку, которая потом оказалась какой-то глупой опечаткой. Или менеджера может начать одолевать скепсис: если все так всё хорошо, почему приложение продолжает падать время от времени? Менеджеры не так радужно, как программисты, относятся к процессу разработки проекта и возникающим проблемам.
Рисунок 1. Программисты часто слишком оптимистичны, будучи уверенными, что всё прекрасно.
Поэтому я хочу раскрыть менеджерам тайну, которая на самом деле, конечно, никакой тайной не является. У программистов есть проблема с переоценкой своего уровня. Про это хорошо написано в статье "Программисты 'выше среднего'" (en). Процитирую отрывок:
Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?
Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».
Очевидно, это не может быть правдой. В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего. Этот эффект известен как иллюзия превосходства. Он описан во многих областях, но даже если вы об этом слышали, вы всё равно, вероятно, ответите «выше среднего».
Это проблема, которая мешает программистам осваивать новые технологии и методологии. В нашем случае, она мешает положительно отнестись к статическому анализу кода. Программисту неприятно осознавать, что какая-то программа будет учить его, как лучше писать код. И уж совсем неприятно, когда анализатор выявляет в его идеальном коде глупые ошибки, и делает их всеобщим достоянием. Нужна большая сила воли и мудрость, чтобы заметить и принять свои недостатки и недоработки. Намного проще дать негативный отзыв об инструменте или в целом о какой-то технологии, и оставаться жить в своем уютном замкнутом мире.
Анализатор PVS-Studio находит ошибки в коде таких проектов как Qt, MSBuild, LLVM, GCC, GDB, Chromium. Разработчиков этих проектов никак нельзя оценить ниже среднего. Однако, это не мешает все новым и новым программистам отвечать, что их код качественен и для них анализ кода не актуален. Я в таких случаях люблю спрашивать: раз все кругом так хорошо и все такие профессионалы, то кто сделал вот эти 11000 ошибок? Вопрос, конечно, риторический, и я не жду ответа.
Думаю, менеджеры понимают к чему я клоню. Статический анализ крайне важен и полезен при разработке средних и больших проектов. Он помогает бороться со многими ошибками и позволяет контролировать качество процесса разработки в целом. Регулярные проверки позволят вовремя выявить аномальный рост количества ошибок, связанный, например, с тем, что кто-то собрался увольняться и говнокодит, так как ему уже все равно, но надо создавать видимость работы. Эту ситуацию я, конечно, придумал, но действительно полезно иметь инструмент, который может оценить насколько с проектом всё хорошо, и количество предупреждений анализатора — одна из лучших для этого метрик.
Кстати, на эту тему расскажу кое-что интересное. Недавно коллега проверял проект CryEngine V. Баг на баге. Коллега даже не досмотрел предупреждения уровня High, уж очень их много. А потом мы вдруг узнаем, что в последнее время у компании Crytek проблемы и некоторые программисты уже 3 месяца не получают зарплату. Нездоровая ситуация в компании отразилась на качестве кода. Интересно было увидеть такую явную взаимосвязь.
В общем, надо не стесняться заставлять программистов использовать статический анализ кода. Пусть даже не PVS-Studio, пусть это будет хотя бы Cppcheck (выполняет простые проверки, но зато бесплатен). Это уже будет большим хорошим делом. Программист, конечно, может капризничать, поэтому стоит проявить твердость.
Часто программисты ссылаются на то, что работа с анализатором отнимает время, заставляя просматривать ложные предупреждения.
Здесь я не сдержусь от сарказма: Да, да… Потратить один день на настройку анализатора, чтобы сократить количество ложных срабатываний, это много. А сидеть и неделю искать ошибку, это в самый раз, это нормально.
Proof: ошибка, на обнаружение которой было безуспешно потрачено около 50 часов, при помощи однократного запуска анализатора была обнаружена и исправлена менее чем за час.
Кстати, если нет нужды начать с поиска ошибок в старом коде, то интегрировать в процесс разработки статический анализатор очень просто. PVS-Studio может показывать ошибки, относящиеся только к новому или измененному коду (см. массовое подавление сообщений анализатора).
Следует скептически относиться к возражениям программистов на тему того, почему им не нужен статический анализатор. Им-то, может, он действительно не нужен. Он нужен проекту. Эта одна из методологий, такая же как, например, юнит-тесты, которая позволяет повысить надежность программы и, тем самым, сократить траты на её сопровождение. Чем быстрее какие-то ошибки будут найдены, тем лучше. Статические анализаторы позволяют выявлять ошибки на самом раннем этапе, т.е. сразу, как только они появятся в коде.
Рисунок 2. Учтите, некоторые программисты используют статический анализ неправильно.
Ещё один важный момент. Некоторые программисты могут заявить, что при тестовом прогоне ошибок найдено мало, поэтому внедрение анализатора кода нецелесообразно. Не дайте им себя запутать. Конечно, ошибок в отлаженном и работающем коде будет немного, иначе бы программа не работала. Однако, поиск и устранение ошибок может обходиться очень дорого. Часто многие жалобы пользователей и часы медитации программистов в отладчике могли бы просто исчезнуть, благодаря одному запуску анализатора кода. Вся суть и польза статического анализа в его регулярном применении, а не разовых запусках.
Несколько раз я сам слышал, что некоторые программисты запускают статические анализаторы при подготовке к релизу. Если кто-то так делает и утверждает, что это нормально, то он профнепригоден. Это самый неправильный способ использования статических анализаторов. Это то же самое, что включать перед релизом предупреждения компилятора, а все остальное время работать над проектом, полностью их отключив.
Спасибо за внимание. Приглашаю всех, кто заинтересовался методологией статического анализа в целом и анализатором PVS-Studio в частности, написать нам. Мы поможем проверить ваш проект, настроить анализатор, и подскажем, как разобраться с выданными предупреждениями.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. A post about static analysis for project managers, not recommended for the programmers
Комментарии (146)
yurror
14.04.2017 17:56+2А что в этой статье может не понравиться программистам?
rkfg
14.04.2017 18:53+9Мне вот тоже непонятно. Если есть инструмент, который за тебя прошерстит код и укажет на подозрительные или очевидно ошибочные места, это же круто. Конечно, искать и исправлять ошибки бывает интересно, но если программист не нашёл их сразу, видимо, они неочевидные или редко срабатывающие, что повышает их опасность в разы. А не ошибается, как известно, только тот, кто ничего не делает.
Странно, что среди разработчиков есть такие самоуверенные люди, которые думают, что пишут идеальный код. Они вообще ни одной популярной большой программой не пользовались, что ли? Везде полно багов и дыр, и в ОС, и в браузерах, и в прочем прикладном софте. Считать себя на голову круче всех тех, кто пишет операционки и браузеры, могут разве что совсем неопытные программисты. Ну и эффект Даннинга-Крюгера забывать не стоит. Я вот свой уровень оценил бы как средний или ниже среднего, и чем больше узнаю, тем ниже этот уровень оцениваю.
Andrey2008
15.04.2017 16:32+5Странно, что среди разработчиков есть такие самоуверенные люди, которые думают, что пишут идеальный код.
Добро пожаловать в реальный мир программирования. :) Думаю, дискуссия которая разворачивается, будет Вам необычно и интересна.
kloppspb
15.04.2017 16:41+1Добро пожаловать в реальный мир программирования.
В соседних темах люди жалуются на то, что их приглашают на собеседование программистом. И, ужас — просят пузырёк(!) на бумажке карандашиком изобразить(!). Какая нафиг «алгоритмическая база», они-то получили сертификат FOO и хотят творить мир в сооветствии с BAR :-)
Не говоря уж о том, что в их IDE есть кнопка «Debug» не догадываются вовсе…
mirrr
16.04.2017 07:34Ну а какая практическая польза в такой задаче на собеседовании?
kloppspb
16.04.2017 15:55Вы не поверите, но очень даже практическая: отсеять тех, кто решил что имеет какое-то отношение к профессии.
mirrr
19.04.2017 09:15На практике же — 90% из тех, кто помнит метод пузырька, его и будут использовать при необходимости написать сортировку. Прикола ради задали вопрос по пузырьку студенту стажеру. Нарисовал правильно. А он, на минуточку, человек, который пишет код уровня:
if (x === true) { toggle(true); } else if (x === false) { toggle(false); }
ainoneko
20.04.2017 19:19А что там помнить-то в этом методе?
Половина алгоритма уже содержится в названии.
webkumo
15.04.2017 11:44+1Они почему-то уверены, что статический анализатор неприятен всем программистам:
Мы поговорим о вещах, которые неприятны программистам.
Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.Andrey2008
15.04.2017 16:17+3Это называется гипербола (стилистическая фигура явного и намеренного преувеличения, с целью усиления выразительности и подчёркивания сказанной мысли). Конечно не всем, но мы видим что это действительно есть, и даже в обсуждении этой статьи. Поэтому и захотелось обратить внимание на этой читателей. И мне кажется, это удалось и завязывается интересная дискуссия.
kloppspb
15.04.2017 16:25Не скажу за плюсы и шарп, ибо не настолько в теме. Но что касается C — использование и таких анализаторов, и valgrind с аналогами, и чего-то вроде ebizzy, это очевидность. Не очень понятная, впрочем, тем, для кого C всего лишь исторический факт :-)
Andrey2008
15.04.2017 16:45+2Я за C++ скажу. По моему субъективному мнение (а в этом вопросе мне можно доверять), разницы между качеством кода C и C++ нет. И там, и там есть опечатки и и.д. Да, в C++ стало лучше с управлением памяти, зато и способов накосить стало больше. Например, можно написать std::unique_ptr p(new A[3]);. Т.е. выделяем массив, а уничтожаем потом как один элемент.
Иногда попадаются очень качественные C++ проекты, написанные на всяких контейнерах, с применением всяких хороших техник и т.п. И там очень сложно найти ошибку (пример). Но так ведь есть и очень качественные C проекты (пример).kloppspb
15.04.2017 17:30Да, в C++ стало лучше с управлением памят
По молодости и глупости :) когда я не смог разобраться с одной утечкой, которая проявлялась в зависимости от фазы луны, и обрушивало приложение, пришлось открыть для себя вот. Потом проблему нашли, выявили, и грубым способом устраняли ещё пару месяцев, потому что затычка — не решение, а оно тянуло за собой ещё много переписывания кода.
(если коротко — возврат локальной переменной где-то в глубине «си с классами», но это столько за собой потянуло, и столько выявило… плюс на это наложилась куча опечаток типа "=" vs "==", что сами фигели как это вообще работало )rkfg
16.04.2017 11:40Лямбды теперь тоже добавляют веселья. У меня вот на днях было: цикл по коллекции, в нём значения из коллекции передаются в лямбду, захват по ссылке, но работает криво — или выдаёт неверные значения, или падает. Потом оказалось, что лямбда выполняется вообще в другое время, а то и в другом потоке, когда переменная цикла уже давно уничтожена. А по виду функции, которая принимает лямбду, не всегда можно сказать, синхронное там выполнение или нет, надо ли учитывать время жизни передаваемых объектов или лучше просто копировать их.
staticlab
15.04.2017 19:50+1Интересно, что в качественной Касабланке всё равно нашлись и опечатка копипаста, и как раз упомянутая некорректная инициализация умного указателя, а также некорректное освобождение умного указателя.
Andrey2008
15.04.2017 16:19+2А что в этой статье может не понравиться программистам?
См. комментарии ниже. :)
Am0ralist
15.04.2017 17:46+3Два хейтера внизу (обратите внимание на карум оных), один даже успел передернуть в подсчетах и некорректно посчитал «упущенную» выгоду строго под свои измышления в качестве «доказательства».
Собственно, на хабре, такое ощущение, уже прям сложилась группа лиц, которые готовы докапываться к чему угодно от оной компании.
NaHCO3
14.04.2017 18:52-7Попробуйте заменить «статический анализ» на «статическая типизация». Ничего не поменяется. Разве что прикрутить к существующему языку статическую типизацию внешними средствами сложнее. А трейдофы практически такие же.
Sild
14.04.2017 22:51+8Интересное мнение. Чем-нибудь подкреплено?
А то для указанных языков типизация то статическая, а анализатор зачем-то используется.NaHCO3
16.04.2017 14:00Так они не пересекаются, вот и используют оба. А с практической точки зрения очень похоже: тебе надо постоянно подсказывать компилятору (статическая типизация) или анализатору (статический анализ), что ты имел в виду. Потому что вывести самостоятельно они это не могут. Это постоянная работа, которая требуется здесь и сейчас. За это возникает вознаграждение когда-нибудь потом, по мере обнаружения ошибок.
Соответственно, все претензии, которые высказываются к статическому анализу — «зачем нам делать лишнюю работу сейчас», можно предъявить и статической типизации.
Jef239
15.04.2017 04:03-8Лучше замените «статический анализ» на «окропление святой водой» или «битье в шаманский бубен». Эффективность на рубль затрат будет примерно та же. Хотя… наверное у каждого айтишника были ситуации, когда помог именно бубен. Кто-то и ракеты перед стартом освящает.
PVS-studio пока не проверял, а CPP-check… Эффективность близкая к нулю. За 3 дня разбора — ничего существенного. При этом варнинги компиляторов — примерно процентов 50 — это реальные ошибки. Хинты компиляторов — процентов 10 указывают на ошибку.
Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
EvgeniyRyzhkov
15.04.2017 06:54+3Вот про это и статья…
Jef239
15.04.2017 14:07-5Увы, весь ваш бог — это антиреклама PVS-studio. Судя по вашему блогу, реальные, мешающие пользователям ошибки PVS-studio помогает исправлять намного реже бубна. ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся. Зато — примеров про полезность бубна — сотни.
Зато — цена статического анализа — намного больше цены бубна. Дело не только в стоимости, но и во времени выполнения и анализа. В основном — анализа. И это касается не только ложных срабатываний. Но и вполне реальных, но десятой степени важности. Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются. Максимум — проверить перед релизом, что мин нет.
Зато — никто не пишет в комментариях «спасибо, мы за этим багом год гонялись». Основная реакция — «извините, у нас есть реально важные вещи. Те мелочи, что вы нарыли — мы когда-нибудь исправим». И это — главная антиреклама статического анализа.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.
Отдельный вопрос про уязвимости. Ну в общем ваш представитель сам признал, что пока что примеров нахождения реальных, эксплуатируемых уязвимостей у вас нет. Но как раз тут вам может повезти.
А основной эффект от статического анализатора — это введение в заблуждение менеджеров. «Раз мы потратили килобаксы — значит наш код будет без ошибок». Это в принципе неверно, потому что большинство ошибок — алгоритмические. Статический анализ, бубен, окропление святой водой — все это плацебо. Да, немного помогает. Но зато — оттягивает время на реально полезные меры. Те, что дают эффекта намного больше стоимости.Lord_Ahriman
15.04.2017 16:29+4основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много
Да неужели?
Зачем вы постоянно выделяете рандомные куски фраз жирным? Такое ощущение, что вы периодически на крик срываетесьJef239
16.04.2017 22:36-1Это смысловое ударение. Жирные слова говорятся с нажимом. А вы знаете более лучший способ их передать? Или вообще против rich-text?
Jef239
16.04.2017 22:39-2Если вы читаете главными баги при кодировании, то советую подумать о том, являются ли баги при кодировании причиной ложных срабатываний PVS-studio. Или почитать соответствующую статью от авторов.
Andrey2008
15.04.2017 17:15+2ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся.
Ну что делать, если нам редко сообщают об интересных найденных ошибках. Да и о большинстве мы всё не можем написать. Почти у всех наших клиентов код закрыт, и они не хотели бы чтобы мы приводили примеры из их кода. Не писать же статью в духе. Компания X нашла ошибку, Y, в коде Z, но X/Y/Z мы не покажем. :)
Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.
Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются.
Запускайте что-то посерьезней и поудобней. Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много. А основной эффект от статического анализатора — это введение в заблуждение менеджеров.
Большое спасибо за ваш комментарий. Благодаря ему моя статья становится что ли более достоверной. А то получается, что я описываю неких абстрактных людей. А Вы как бы воплощаете заблуждения в реальность. :)Jef239
16.04.2017 22:11-2А вы свой код не проверяете разве? Пока что вы дали только антирекламу: "Мы тут проверили свой код и нашли ерунду". И это полностью соответствует моим ощущениям от cppcheck.
Возьмите любое ложное срабатывание. И оцените — сколько процентов — не исправимо в принципе, сколько — отсутствие функциональности, сколько — ошибки алгоритма, сколько — ошибки в коде, не находимые статанализом, и сколько ошибок на самом деле нашел статанализатор во время разработки.
Возьмите статистику по тестированию. У вас в посте рассказано про 7 методик тестирования. Оцените, какой процент ошибок находится именно статанализом.
Сделайте двойное слепое рандомизированное исследование. Насколько статанализ уменьшает количество ошибок? И насколько он лучше плацебо?
Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.
Я рад, что вы тоже читали про жопу Хэнка. В ответ могу сказать, что бубен используется даже на атомных электростанциях, а сбербанк освящает отделения.
Как и любое целование жопы Хэнка, бубен дает как минимум плацебо-эффект. Вопрос лишь в том, что на тысячу рублей затрат эффект от бубна намного больше, чем от статанализа. Если вы знаете условия, при которых эффект от статанализа выше, чем от бубна — то честно опишите их.
Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно
У вас есть способ по номеру строки и имени модуля автоматически найти комит, который внес ошибку? Или вы хотите просто отправлять тому, кто последний раз правил данный кусок? Первое — очень интересно. Особенно, если там не банальный bisect, а что-то умное.
А Вы как бы воплощаете заблуждения в реальность. :)
Если вернее — мои заблуждения совпадают с вашей антирекламой. Если бы вы написали: "У нас тут плагин выпал из станализа, в итоге там было 100500 ошибок, мы выпустили плагин на год позже и он до сих пор глючен как тупайя" может быть я и поверил бы. Но вы написали честно.
А вот и ещё подтверждение. Опять ваша статья о ложных срабатываниях. И вы опять честно говорите, что дело в алгоритмах, а не в багах в коде. И ни один супер-пупер анализатор не поможет вам уменьшить число ложных срабатываний — для этого все равно нужно развивать алгоритмы.
Возможно, есть некоторая узкая область, где статанализатор оправдывает свою цену. Но тогда нужно просто её описать. Как вариант — это веб-проекты, где действительно ошибка может стать уязвимостью.Andrey2008
16.04.2017 23:47+1Вы усиленно ссылаетесь здесь и в других комментариях на статью "Проверяем исходный код плагина PVS-Studio с помощью PVS-Studio" и говорите «ага, я же говорил, что мало находится». Есть 3 момента, о которых Вы не подумали или сознательно не замечаете.
- Плагин для Visual Studio, это маленькая программа, там просто негде взяться сотням ошибкам.
- В маленькой программе и плотность ошибок меньше.
- Суть статического анализа в регулярных запусках. Мы бы возможно сократили время на поиск некоторых ошибок, если использовали анализатор сразу. Но для такой маленькой программы как плагин об этом и рассуждать особенно смысла нет. Можно вполне обходиться без статического анализа, что мы и делали. Эта статья писалась не для рекламы, а исключительно для того, чтобы наконец было отвечать на вопрос, который уже вызывает зубную боль, проверяли ли мы PVS-Studio с помощью PVS-Studio.
Jef239
17.04.2017 01:31-5Да почему же, замечаю. Маленькая — это по вашему сколько строк? То есть с какого размера программы PVS-Studio начинает оправдывать свою цену? Это первый важный вопрос.
По моему мнению, маленькая — это программа, написанная малой группой, где тимлид лично читал весь код и помнит его наизусть. В ней может быть и полмиллиона строк кода — тут дело не в размере. С другой стороны, программа в 10 тысяч строк, которую писал десяток авторов — это большая программа (тот самый верблюд, что создан комитетом вместо лошади) и в ней багов будет порядочно. Особенно, если куча авторов делали лишь несколько комитов, то есть не разбирались в коде достаточно долго.
Ну вот вам другая ваша же статья. Выбрана ровно потому, что это детище одного автора (или малой группы). Да, что-то нашлось. Но найденное — явно не соразмерно цене PVS-Studio.
А второй вопрос, это не лучше ли вместо покупки статанализатора купить бубны, освятить компы, покрасить стены в зеленый цвет или сделать какие-то ещё плацебо-мероприятия. Потому что любое плацебо — немного помогает. При каких условиях PVS-studio выгодней бубна, если считать на рубль затрат?
А знаете, как работают там, где цена ошибки — 35-40 тысяч долларов? Там премия равна окладу. А снимается премия со всей службы за 3 часа простоя в месяц. Итог - ноль минут простоя за 3 года, что я отслеживал установленную там нашу систему. И опять вопрос — при каких условиях выгоднее платить за PVS-studio вместо премий (той же суммой) разработчикам?
Кстати, примитивный статанализ я там написал, но применять его не стали. А вот динамический анализ хорошо пошел. Динамический анализ по аварийному сигналу определял, срабатывание какого датчика вызвало аварию. Определялось верно в 99.7% случаев, ложных срабатываний — меньше 0.1%. Ну то есть меряли на 1000 сэмплов и не нашли.
Это некоторый намёк — программа (плагин к отладчику), которая при возникновении исключения находит ошибку — может быть безумно популярной при её разумной цене. Ну и ложных срабатываний в ней немного.staticlab
17.04.2017 10:04А знаете, как работают там, где цена ошибки — 35-40 тысяч долларов? Там премия равна окладу.
Не обсуждая то, что это в принципе незаконно, у руководителей этой организации зарплату тоже режут, если сотрудники допустили баг в программе?
SvyatoslavMC
17.04.2017 11:20+4Не вы случайно писали статью о российских ракетах, на которые официально тратится ~130000 рублей на освящение церковью?
Jef239
17.04.2017 15:03Нет, я всего лишь дал на неё ссылку. Сбербанк делает и то и то — и PVS-Studio покупает и отделения освящает. Похоже, что это явления примерно одного порядка полезности.
Lord_Ahriman
18.04.2017 07:40+6Слушайте, я вас не понимаю. Ну не нужен вам их продукт, считаете его слишком дорогим, бесполезным и т.д. — не покупайте, не используйте и вообще всячески игнорируйте. Я постоянно читаю этот блог, и постоянно вижу, как вы бегаете по статьям, чтобы рассказать, как вам PVS-Studio безразличен, что он нафиг не нужен, что вообще вы ненастоящий программист и вот это всё. Какой в этом смысл? Не хотите — не используйте. А то сейчас выглядит так: то ли вы просто хейтер, то ли вы всячески демонстрируете свою «нетаковость» и олдфажность, то ли вам очень хочется юзать PVS, но давит жаба, и поэтому вы компенсируете вот таки странным образом. В заключение цитата из Остера:
А кому смотреть противно —
Тот пускай и не глядит.
Мы же в нос к нему не лезем —
Пусть и он не пристает.
И цитата из ФИДО:
«Отпишись и не читай!»Jef239
18.04.2017 14:53-6Может вы ещё и уголовное дело за оскорбление чувств верующих в PVS-studio возбудите? :-)
Я откомментировал всего 2-3 статьи, то есть меньше 1% статей в блоге PVS-studio. Это вот четко показывает, что ваше отношение к PVS-Studio — религиозно, а критическое мышление у вас отсутствует как класс. В чем-то это даже верно — статанализ надо рассматривать наравне с бубном и другими суевериями. См. замечательную статью про Hype Driven Development
А добился я пока одной честной цифры — меньше 250 KLoc любой статанализ «не обязателен».
Думаю, что добьюсь и остальных цифр, например, с какого размера программы окупается цена PVS-studio, каков экономический эффект и так далее. То есть того, что реально нужно знать до покупки.
Ну а вы — можете и дальше верить, что любая модная технология применима всегда и везде.
Lord_Ahriman
18.04.2017 15:13+4Это очень оригинально — умудриться в моих словах о нелогичности вашего поведения найти религиозную веру и еще кучу вещей, которых там и близко не было. Впрочем, я благодарен вам вот за вот эту фразу:
Статанализ надо рассматривать наравне с бубном и другими суевериями
Таким образом, у вас тут религиозный поход против статанализа, как бы вы не изворачивались, утверждая обратное. Чудно, теперь все встало на свои места. Продолжайте писать ваш супербезгрешный безошибочный код и дальше да считайте статанализ модной фигней, которой при царе Горохе-то не было и ничего, жили как-то.
ЗЫ:
[offrop]
ваш плевок мне в карму воспринимаю исключительно как как ваше бессилие в попытках внятно аргументировать, чего вам так не нравится в PVS и статанализе вообще. Засим откланиваюсь, потому как вести с вами конструктивный диалог явно не выйдет (по причине религиозной веры, таки да, только вот чьей — боооольшооой вопрос).
[/offtop]Jef239
18.04.2017 18:20-2В PVS мне не нравится цена, а в модных технология вообще — попытка выдать очередную модную фишку за панацею. Что и было написано не менее пяти раз.
Любая технология чуть ли не половину эффекта дает до своего реального внедрения. Это собственно плацебо (или почти плацебо). Не важно, красите ли вы стены в зеленый цвет, раздаете сотрудникам бубны, устанавливаете теннисные столы, освящаете кабинеты или внедряете статанализ — какой-то эффект будет всегда.
Есть подозрение, что основной эффект от статанализа — это всего лишь мотивация сотрудников. «Ой. руководство решит, что у меня багов много, буду-ка я писать аккуратней». Беда в том, что замотивировать можно и меньшими деньгами, чем плата за PVS-studio.
Теоретически статанализ полезен, но самые полезные 9% статанализа встроены к компилятор. Все остальное — это гонка за оставшимися 3-5 процентами. Стоит ли платить немалые деньги просто за собственный перфекционизм — это большой вопрос.
Что касается меня, то считайте, что это крестовый поход против любой модной технологии, которую советуют применять всегда и везде, «невзирая на памятник».
Ну должен же быть среди толпы модников хоть один взрослый, понимающий, что это всего лишь мода и она пройдет?
webkumo
18.04.2017 17:47+2Безотносительно от PVS-studio (для java его нет и вряд ли в обозримом времени появится) — стат.анализ помогает даже в условно-мелких проектах. На своём примере знаю, что применение стат. анализа помогло:
- идентифицировать несколько багов, могущих испортить выводимые данные в многопоточном окружении (к сожалению базовая библиотека форматированного вывода даты в Java непригодна к использования в многопоточном окружении, т.к. использует общий объект с внутренним состоянием)
- увидеть несколько опасных мест, которые в ряде случаев могли сработать в виде багов
- увидеть места, которые можно было упростить (чем повышалась читабельность).
Сколько это в деньгах — сказать не смогу, не менеджер. Но в любом случае в цену багов входят не только стоимость работы девов/qa, но и репутационные издержки, а в некоторых случаях — и прямые финансовые потери ($440 000 000, помог ли бы им стат. анализ неизвестно, о таких фейлах наружу инфу стараются не выпускать, но вероятность такого исхода была бы всё же ниже).
PS и да, согласен с Ахриманом — ваше хейтерство PVSов сильно похоже на религозное мракобесие… успокойтесь уже. Не нравятся они вам — забейте и не смотрите их стати.
Jef239
18.04.2017 18:30-3Знаете, при риске в 440 миллионов, я бы не только освятил проект. Но ещё и позвал бы муллу, равина и ламу. Ну и настоящего шамана — это уж само собой.
Но граница выгодности — это как раз самый интересный момент. И когда о нем умалчивают — появляется желание объяснить толпемалолетокмолодежи, что эта граница есть. Благо большая часть хабра годится мне в дети.
А про ваш проект мне интересен другой вопрос. Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?
P.S. Забить не смогу, я обещал проверить свой проект после вычистки cppcheck и clang static anayuzer и написать честный отчет, насколько PVS-studio лучше бесплатных проектов. Рабочая гипотеза примерно совпадает с тем, что вы написали — некая мелочевка нашлась, но времени не окупает.webkumo
19.04.2017 01:42+3Сколько времени вы потеряли на проверку результатов статанализа и сколько бы стоили те фичи, которые бы вы смогли за это время написать? Ну или сколько реально проявляющих багов могли бы за это время найти?
Полдня на настройку автоматического сбора статистики по стат-анализу в рамках CI. Полдня на снятие сливок. Самостоятельный поиск тех самых багов с многопоточностью съел бы вряд ли меньше дня… а мог и больше слопать. При этом когда бы они сыграли — фиг его знает… Но последствия, хоть и только репутационные, но были бы весьма неприятны. Остальные бонусы шли оверхедом и в принципе всё выше минора по оценке стат-анализа было оправдано в разборе и правке.
Jef239
19.04.2017 02:02-5У нас с вами — разные предпосылки. Вы верите, что можете исправить все баги, а я знаю, что могу лишь уменьшить их плотность и увеличить MTBF.
Вы потеряли день на нахождение багов, которые не проявлялись в вашем проекте. Вместо этого вы могли исправить 3-15 багов, которые проявляются и мешают вашим пользователям. Или написать пару позарез нужных фичей.
Правилен ли такой обмен? Стоит ли менять реально полезную работу на лишь потенциально полезную?
Другой случай, если бы у вас в этот момент вообще бы не было никакой полезной работы. Вот тогда обмен правильный. Но подобная ситуация (то есть простой) бывает только на саппорте. У девелоперов она редкость.
Neikist
19.04.2017 12:44+1А давайте теперь еще дружно начнем забивать на рост тех. долга, писать говнокод лишь бы работал, забьем на проектирование, документацию, производительность, написание тестов… Ведь вместо этого можно радостно новые фичи добавлять или мешающие пользователям баги фиксить.
Звучит абсурдно, не правда ли? Исправление косяков найденных стат. анализом это вещь ровно того же порядка. К сожалению в моей сфере деятельности такие инструменты отсутствуют, да что там, даже тесты пишут доли процента и я не в их числе, но сам не раз искал и исправлял ошибки возникшие по причине опечаток и копипаста, при этом времени уходила уйма.
// Не удержался все таки…Jef239
20.04.2017 01:34-1Звучит абсолютно нормально. Именно так и делается MVP, а так же макеты и прототипы.
Про то, что рост технического долга — это не так плохо, есть достаточно много статей на хабре. Например эта или эта.
Ну да, есть люди, которые из принципа не берут кредиты. Точно так же есть люди, которые не делают технический долг. Но разумная стратегия — это использование и кредитов и технического долга для ускорения развития.
К сожалению в моей сфере деятельности такие инструменты отсутствуют
Если вам так хочется написать статанализ на 1С я, наверное, могу поделиться исходниками синтаксического анализатора 1С.
Вам просто было лень поискать. Вот вам статанализатор для 1С. Попробуйте проверить им свои проекты, а потом уже на опыте расскажите нам про его полезность.
Neikist
20.04.2017 06:59Хм, действительно, посыпаю голову пеплом что умудрился такую штуку проморгать, хотя когда впервые про pvs услышал поискал на тему 1с, в то время почему то не нашел. Пока что не имею возможности приобрести, но в течении нескольких месяцев возможно сподоблюсь и отпишусь.
Про MVP слышал конечно, и не считаю что тех. долг нужно тут же исправлять как только появится, но ведь до маразма доходит же что функциональность пишется вообще без проектирования, с дикими костылями и говнокодом, и в таком виде и замораживается, ибо трогать страшно — развалится. Впрочем даже если и не трогать — ошибки лезут из всех щелей, приходится на каждом проекте их заново править. В итоге дорабатывать нашу систему под каждого заказчика это такая боль… Особенно если это правки в существующем функционале.Jef239
20.04.2017 07:20-1До маразма может и в обратную сторону доходить. Товарищ не пишет нужную функциональность, потому что в ней при сильной нагрузке может быть ситуация из которой он не придумал, как выбираться.
Сильная нагрузка — это в сотню раз больше планируемого максимума.
ainoneko
21.04.2017 06:13Это то, что у Джоэла называется «огонь и движение»?
(И пятилетней давности новость про патент танка, стреляющего экскрементами.)
lany
15.04.2017 17:48+4Качественный статический анализатор может найти и ошибки в сложных алгоритмах. Если у вас программа перебирает сложный набор состояний нескольких переменных в цепочке условий, статический анализ легко предупредит вас, например, что вы одно и то же состояние проверяете дважды или что две проверки взаимоисключающие.
Jef239
16.04.2017 19:20-3Да, разумеется, об этом классе ошибок и бесплатный gcc предупреждает (если писать через switch). Вопрос в том, стоит ли за платить за это немерянные килобаксы.
По личному опыту использование cppcheck не оправдалось. То есть время, потраченное на разбор — не оправдывается тем, что он нашел.
Типичный баг, найденный cppcheckУгу, если пираты захватят корабль, вскроют наш ящик, спаяют кабель, зайдут с консоли и вместо rm -rf / начнут вводить очень длинные параметры командной строки — будет плохо. Но это не те проблемы. которые есть смысл исправлять. Потому как пиратам проще пристрелить капитана. Ну раз уж они все равно на судне.staticlab
16.04.2017 22:22Вы экстраполируете опыт использования cppcheck — весьма примитивного анализатора — на коммерческий продукт, который умеет детектить в разы больше ошибок?
Jef239
16.04.2017 22:34-4В общем, надо не стесняться заставлять программистов использовать статический анализ кода. Пусть даже не PVS-Studio, пусть это будет хотя бы Cppcheck (выполняет простые проверки, но зато бесплатен). Это уже будет большим хорошим делом. Программист, конечно, может капризничать, поэтому стоит проявить твердость.
Как видите, это не я, это команда PVS-Studio.
Лично я экстраполирую их опыт проверки их собственного кода. Как видите — найденное вряд ли стоит потраченного времени.staticlab
16.04.2017 22:45+1Очевидно же, что проверка их собственного кода находит минимум реальных проблем, потому что они и так постоянно им пользуются и исправляют дефекты по мере появления. Поэтому авторы и советуют постоянно пользоваться анализатором. Что же касается потраченного времени, то сколько в среднем человеко-часов в вашей команде стоит устранение бага, который мог был быть выловлен анализатором?
Jef239
16.04.2017 23:15Очевидно, что вы не читали их статью
Из-за недосмотра C# код плагина для Visual Studio не был добавлен в ежедневные ночные проверки, которые мы проводим. И, соответственно, в отличие от ядра анализатора, ошибки в нем не замечались на протяжении всего развития C# PVS-Studio.
Увы, я тоже автор статанализатора. Для очень простых языков, но тем не менее. И к сожалению я знаю, что может найти статанализ, а что не может. Устранение бага, который мог быть пойман анализатором, как правило, не стоит потраченного на него времени.
Возможно, есть исключение для софта, баги в котором являются уязвимостями. Но на софт к такому не относится. Если уж ящик открыли — то проще сжечь процессор пьезозажигалкой, чем искать уязвимости в софте.
lany
17.04.2017 03:39+2Через switch вы переберёте конкретные состояния одной переменной. Анализатор может больше. Скажем, такой код, чисто для примера:
int a = getA(); int b = getB(); if(a >= 0 && b <= 0) { ... } else if(a <= 0 && b >= 0) { ... } else if(a < 0) { ... ... if(b == 1) {...} // анализатор: это у вас тут всегда ложно }
Не знаю, может ли такое cppcheck.
Jef239
17.04.2017 04:17-3— Я духов вызывать могу из бездны!
— И я могу, и всякий это может. Вопрос лишь, явятся ль они на зов.
То есть этот код — только переписывать.
Начнем с того, что PVS-Studio прежде всего ругнется на int a = getA(); чем-нибудь типа V707. Потом так же на int b = getB();, потом — на if(a <= 0 && b >= 0) — ибо ситуация a=0, b=0 проверена раньше.
Если… обозначает код того же уровня, то вы получите предупреждений — примерно столько же, сколько строк в коде. И сумеете ли вы найти в этой каше то, что важно лично вам — это большой вопрос.
Есть лишь один случай, когда нужно писать такую лапшу- когда она описана в ГОСТ или РД. Ну как пример — РД 50-25645.325-89.
.
Вот тут и однобуквенные переменные и куча других странностей. Но хочешь результат, совместимый с другими — значит делаешь по ГОСТ.staticlab
17.04.2017 10:14Вы передёргиваете. Разумеется, тут синтетический пример, оттого и переменные однобуквенные. Но в реальном коде анализатор во всём будет прав. И если он выдаёт столько предупреждений, значит действительно с кодом что-то не в порядке. Другой момент, что если
if (b == 1)было внесено позже, то анализатор намного быстрее заметит это, чем вычитка автором, код-ревью командой или проверка QA. Или их время не важно и легче действовать тоталитарными методами?Jef239
17.04.2017 15:26-1Да, заметит быстрее. Но будет ли это дешевле? Личный вертолет — быстрее велосипеда. Вы себе вертолет уже купили?
Один из авторов PVS-Studio дал нижнюю оценку эффективности в 250КLoc. Вы с этим согласны?
lany
17.04.2017 10:58прежде всего ругнется на int a = getA(); чем-нибудь типа V707
Кто вам сказал, что это глобальные переменные? Да и суть не в именах.
потом — на if(a <= 0 && b >= 0) — ибо ситуация a=0, b=0 проверена раньше.
Почему вы считаете, что на это условие нужно ругаться? Я хочу, чтобы (a, b) = (-1, 0) и (0, 1) заходили в эту ветку. Как вы напишете второе условие?
webkumo
17.04.2017 11:22Почему вы считаете, что на это условие нужно ругаться? Я хочу, чтобы (a, b) = (-1, 0) и (0, 1) заходили в эту ветку. Как вы напишете второе условие?
Там первое условия
if(a >= 0 && b <= 0)съест этот случайlany
17.04.2017 11:29Возможно, я плохо выразился или вы плохо подумали. При a = -1, b = 0 мы не зайдём в первую ветку. При a = 0, b = 1 мы тоже не зайдём в первую ветку.
webkumo
17.04.2017 17:35Скорее всего вы пропустили нюанс: в условие
a <= 0 && b >= 0входит в том числе случайa,b=0, который проверен условием выше, а потому статический анализатор на него должен агриться.
Но выполнение такого требования будет работать в ущерб читабельности второго условия — его нужно будет расширять, например до(a == 0 && a != b || a < 0) && b >=0.lany
17.04.2017 18:30Почему вы решили, что я пропустил нюанс? Этот нюанс был специально добавлен моими заботливыми руками в код, чтобы показать, что код бывает непростым. Если статический анализатор будет на такие нюансы ругаться, будет очень много ложных сработок.
Andrey2008
19.04.2017 11:35Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много.
Некоторые мысли про это.
staticlab
15.04.2017 12:37+2Ваш компилятор детектит опечатки вроде V501?
Jef239
15.04.2017 14:17-6Не было таких ошибок в коде, так что не проверял.
staticlab
15.04.2017 15:12+3А откуда вы знаете, что в ваших проектах нет таких ошибок?
Jef239
16.04.2017 19:31-7[SARCASM ON]
А откуда вы знаете, что вы не шпион гондураса? Может быть вас во сне завербовали? А давайте вы купите нашу программу за полмиллиона, мы тогда вас проверим и скажем, шпион вы или нет. Да, мы умеем проверять не только на Гондурас. Ещё Гватемала и 50 других стран. Из европейский, правда, только Монако, Люксембург и Андорра, но этого тоже не мало,
[SARCASM OFF]
Неужели вы думаете, что я не знаю наизусть код своего проекта? Проекты до 100 тысяч строк помнятся целиком.
А в помните каждый час своей жизни, чтобы утверждать, что вас не завербовали в шпионы?staticlab
16.04.2017 21:20+4Я думаю, что у вас завышенное ЧСВ. Впрочем, статья как раз об этом, и о том что таким заявлениям программистов верить нельзя. Вы можете быть уверены, что закодировали всё правильно, но досадные опечатки могут быть у каждого. Анализатор сразу об этом скажет, и ни QA, ни менеджер, ни заказчик об этом даже не узнают, так что самооценка не пострадает.
Jef239
16.04.2017 22:17-6Думаю, что вы все-таки шпион Гондураса. Просто платить не хотите. :-)
ЧСВ у меня скорее заниженное, компилятор мне об ошибках рапортует ежедневно. Не в этом дело. А в том, что ошибки, найденные станализатором — не стоят времени, потраченного на анализ. Вот вам пример от PVS-Studio.
Скажите, сколько своих денег вы готовы заплатить за продукт, который находит такое количество ошибок? Мне вот жалко времени, потраченного на анализ выдачи.
Andrey2008
15.04.2017 17:21+5О, Евгений предсказал это.
Для тех, кто не понял юмор. V501 есть у всех (FreeBSD, Clang, Far, Blender, GCC, Unreal Engine, Chromium, Qt, TortoiseSVN, ...)Jef239
16.04.2017 19:45-4Это типичная ошибка мышления. Вы перечисляете верблюдов, созданных комитетом. И уверены, что у всех животных — есть один-два горба. Но не понимаете, что у кенгуру — все иначе. Два члена, переменный срок беременности, если голодает — беременность рассасывается, есть сумка, горбов почему-то нет и так далее…
Вы бы хоть глянули, есть ли эта ошибка в той версии FAR, которую писал Евгений Рошаль лично.
Oxoron
15.04.2017 14:55Ок, предположим что не детектит (я не в курсе что это за ошибка). Попробуем посчитать ценность детекта.
Возьмем команду в 6 человек, лид, аналитик, 2 дева, 2 QA. 100 евро в час каждый. Цикл разработки: аналитик сидит на клиенте, девы пилят по аналитике, QA тестируют (перед продом и на проде), лид вмешивается при багах.
На проде возникает ошибка из-за V501.
Лид тратит час на косяк (откат\разбор\новый релиз), дев час на анализ\фикс, QA два часа на тесты (один раз когда заметил баг, другой раза когда тестировал фикс).
Итого — потеря в 400 евро. Сценарий пессимистичный.
Оптимистичный сценарий: разраб + QA найдут этот косяк уже на тестовом стенде и пофиксят его в обычном режиме. Потери — 0.
Вероятность пессимистичного сценария — 5%. Оптимистичного — 95%. Мат. ожидание потерь от V501 — 20 евро. А теперь вопрос: сколько V501 случаются в рядовом проекте?
Цифры выше взяты с потолка.
Я видел много статей от PVS-Studio. Видел очень даже неплохие статьи для разработчиков (типа «топ самых популярных ошибок»), но пока еще не видел хорошей статьи с подсчетом выгоды от детектов. Ребята, у вас куча чекнутых проектов. Соберите статистику по частотам ошибок («V123 встречается 0.55 раз в 1000 строк кода»), и у вас появятся хоть какие-то цифры для разговора с менеджерами.Andrey2008
15.04.2017 17:41+3Всё просто. Если ошибка стоит 20$, то этому проекту не нужен статический анализатор. Впрочем, это какой-то волшебный проект. В настоящем проекте цена ошибки на порядке выше.
В любом случае, если картина такая, как Вы описали, действительно продать анализатор невозможно. Однако есть другой класс проектов, где ошибка или простой программы выливается в большие деньги. Я, например, знаю случай, когда анализатор PVS-Studio нашел ошибку возрастом в 2 года (там было что-то в духе x*(10/3) из-за которой клиентам автоматически выставлялась неправильная заниженная цена не некоторую группу товаров. Причем, программист рассказал мне по секрету, что побоялись даже доложить начальству об этой ошибке и просто решили втихомолку её исправить.
Еще я знаю случай, когда команду разработчиков несколько раз катали на самолёте на другую сторону земного шара, чтобы они сидели и ждали, когда система опять упадёт, чтобы на месте найти наконец и исправить злосчастный баг, который проявляет себя, как только программисты улетают домой. Оказался неинициализированный член класса.
Я к тому, что ошибки бывают очень дорогие, но при этом до безобразия простые и могли быть легко выявлены анализатором кода. И кстати, менеджеров таких проектов, в отличии от программистов, как-то даже не надо убеждать, что ошибки, это плохо и надо постараться сразу найти их как можно больше.Jef239
16.04.2017 23:21-2Вот в двух описанных вами ситуациях — согласен, статнализ полезен. Вот только цифры бы — насколько часто встречаются именно такие ошибки? Точнее насколько часто по сравнению с другими… Пока что сколько вы не искали в открытых проектах — таких багов вы не нашли.
Что касается второго случая — то это баг архитектуры. Правильно сделанная система АСУТП поднимается после любого бага. То есть она изначально рассчитана на падения.
Jef239
16.04.2017 23:30-6Кстати, на подобных проектах наверное и компы освящают и ещё много чего делают. Стоит недорого, а вдруг поможет?
Примерно так же 100 лет назад в деревнях сначала шли с подарками к батюшке, а потом к колдуну. Не то, чтобы верили, но вдруг кто-то из них и вправду поможет?
Jef239
16.04.2017 23:38+1Кстати, gcc репортит неинициализированные члены класса. Так что этим людям статанализатор не помог бы.
Andrey2008
16.04.2017 23:53+1Помог, не помог… С удовольствием пользуются несколько лет PVS-Studio. Огромный проект на Visual C++ и никакой речи даже нет о возможностях там попробовать GCC или что-то ещё.
Jef239
17.04.2017 00:21-2И сколько вы нашли важных багов, которые иным путем искали бы очень долго? Ну так, примерно, какая от него реальная польза?
Am0ralist
15.04.2017 20:15+3С учетом вашей кармы я даже знаю, чем указанием на ваши ошибки закончатся.
Однако неадекватность требует ответа на нее
На проде возникает ошибка из-за V501.
То есть статическим анализатором в команде пользоваться не умеют, окей.
ошибки компилятора вы тоже только на проде замечаете?
Сценарий пессимистичный
Вы хотели сказать, что сценарий — упоротый?
Лид тратит час на косяк (откат\разбор\новый релиз)
Ну да, дурная голова ногам покоя не дает.
QA два часа на тесты (один раз когда заметил баг, другой раза когда тестировал фикс).
Возвращаемся к исходному, что в статический анализ вы вообще никак.
QA у вас ищут ошибки с помощью компиляции проекта? И проверяют ошибки, которые выдает компилятор? Серьезно? Если нет, то как они увидят ошибки стат.анализа?
Итого — потеря в 400 евро
Итого, из-за того, что вы не понимаете, как пользоваться инструментом — в вашем воображении возникают такие вот фантастические сценарии с воображаемыми же потерями.
А теперь примерно как должно быть в реальности:
2 дева сразу после написания новых куском кода проверяют его стат.анализом. Исправляют ошибки компилятора и стат.анализатора, если они есть, после чего отправляют написанное на тест QA. Лид вмешивается не на предупреждения стат.анализа, а на реальных багах. То есть именно то, что вы описали в «пессимистичном сценарии», только у разрабов появляется дополнительный инструмент проверки только что написанного кода до того, как все это уйдет в QA вообще, а не приходится искать всякие опечатки и неверные куски кода по описанию, что в новом модуле все падает если сделать то-то и то-то.Oxoron
15.04.2017 23:21+1С учетом вашей кармы я даже знаю, чем указанием на ваши ошибки закончатся.
Вообще говоря, некто Am0ralist мною плюсанут.
То есть статическим анализатором в команде пользоваться не умеют, окей.
В нашей команде им не пользуются, ибо другой язык. В одной из предыдущих в свое время не удалось показать выгоду менеджеру.
Соответственно, оба сценария из предыдущего комментария рассматриваются в контексте отсутствия стат-ана.
Вывод прост: при использовании статического анализатора удастся сэкономить условные 20 евро на каждой V501. Цифра условная, взята с потолка.
Затраты на обучение персонала — 1100 евро (по часу девам и лиду на ознакомление + 8 часов дева на внедрение в CI и первичную очистку проекта). Цифра условная, взята с потолка.
Итог: ради одной только V501 закупать PVS-Studio невыгодно, штука евро минуса.
Andrey2008 в комментарии выше приводит примеры в духе «Я, например, знаю случай,». С таким бесполезно подходить к менеджеру. Состоится диалог вроде
– От судьбы не застрахуешься, – упорствовал Епишко. – Я вот знаю случай: в грозу человека в чистом поле убило.
– А не лезь в грозу в чисто поле! – обозлился Звягин. – А влез – так держись по низинкам.
Если проект связан с космосом\медициной\серьезными_деньгами\серьезными_исследованиями — там слова «надежность» может и хватить. Если на проект выделены миллионы — просто впишут анализатор как необходимый софт по слову лида. В рядовом проекте задумаются о цене, времени затраченном на внедрение, и поинтересуются выгодой. И менеджеру выгоду проще всего показать в сэкономленных человеко-часах.
Andrey2008
15.04.2017 16:56+3Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
Не отпугивайте народ :). Наши цены очень даже скромные по сравнению с Coverity, Klocwork. Мы сознательно выбрали среднюю ценовую нишу и живём в ней. Мы тем, кому PC-Lint уже кажется устаревшим/простоватым/неудобным/не умеющий C++14 (а новый они вот уже 3 года делают на основе Clang, но пока всё никак), а цены на Coverity/Xyz уже перебор.
Причем, в плане диагностик мы уже наступаем на пятки Coverity/Klocwork. Так что соотношение результат/цена весьма привлекательно. Покупайте наших слонов!Jef239
16.04.2017 22:31-5Вы случайно самолеты не продавали? А то ну очень аргументация похожа. Ну или антивирусы?
Мне не важно, насколько вы дешевле Coverity. Мне важно, насколько вы лучше бубна и всех остальных плацебо. Причем не просто «мы нашли багов в десять раз больше, чем пляски с бубном». А разница в количестве багов на рубль затрат. Бубен-то я и за 200 рублей купить смогу.
А эффективность доказывается двойным слепым рандомизованным исследованием. Которого у вас нет.
P.S. У меня и резидентный антивирус не стоит (но стоял firewall). И за последние лет 10-15 я отослал в Dr.Web и Касперского немало зверушек. Сказки про то, что без резидентного антивируса сразу комп обрастет вирусами — верны для домохозяйки. Но не верны лично для меня.
Вот и вам совет — узнайте своего пользователя и опишите его. Может и действительно есть такие области, где статанализ выгоднее бубна.
andvgal
15.04.2017 12:12+2Если честно, то не сталкивался с людьми, возражающими против инструментов статического анализа, проверки/исправления стиля и в принципе строгой проверки ошибок и предупреждений.
Это наверно какой-то пещерный вид для зоопарка и гнать их нужно в шею, т.к. за такой вершиной айсберга скрывается ещё больший пласт проблем: ручные сборки в особо настроенной среде, "секретные знания", собственничество с припадками, удручающее качество кода и отсутствие целостной архитектуры в принципе.
Jef239
15.04.2017 14:22-8А с людьми возражающими против окропления святой водой, вы сталкивались?
«За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.
И не путайте божий дар с яичницей. Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.
Кстати, авторы PVS-Studio считают, что в любом проекте при -Wall -Wextra вылезает сотня предупреждений. Если надо — найду вам цитату. У нас почему-то наоборот — ни предупреждений, ни хинтов.Andrey2008
15.04.2017 18:03+3«За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.
Не берусь конечно утверждать и не хочу никого обидеть, однако выскажу своё мнение. Когда заходит речь о системах, которые работают 10 лет подряд, то потом выясняется, что речь идёт о весьма и весьма простых программах, которые действительно можно написать без ошибок. Ведь закон экспоненциального роста глючности никто не отменял. А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы. В них часто часто память выделяется только один раз при запуске. Нет выделений памяти и уже нет массы проблем и ошибок.
Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.
Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
- Far — 50%
- PascalABC.NET — 70%
Jef239
16.04.2017 17:50-5Согласен. Любая надежная система, является простой. Даже если в ней 10 миллионов строк кода и тысяча человек. И наоборот, любая глючная система — сложна, даже если в ней всего пара тысяч строк кода. Вам не кажется, что это аксиома? Более того, мастерство программиста в том и состоит, чтобы сделать максимально простой код.
Глюки, баги (ошибки) и надежность системы — это разные вещи. Глюки — это почти не воспроизводимые ошибки, например — состояние гонки. Статический анализ не помогает их искать. А баги…
Представьте себе, что у вас дом рушится из-за трещины в одном кирпиче. Как нравится? Хочется жить в таком доме? Вот так и мне не нравится пользоваться программами, автор которых решил, что самое главное — устранить все баги. Потому что основное — это обеспечить работу программы независимо от наличия в ней багов.
А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы
Ну как пример — OS/360. Там порядка миллиона строк кода и тысяча человеко-лет. При этом она вполне выполнялась на машинах с 200 тысяч операций в секунду и 256 килобайт памяти. Вы считаете, что это небольшая программа? Там только компиляторов пяток был.
Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
Far — 50%
Что-то надо сделать с любым сообщением. То есть потратить время, проанализировать код и принять какое-то решение. Реальные показатели этого проекта «плотность будет равна 0.464 ошибки на 1000 строк кода». Это означает, что в FAR остались баги типа «если залезть на шкаф и высунуть в окно телескоп то в коне дома за 3 километра мы увидим голую задницу», А если на шкаф не залезать — не увидим.
И это означает, что правильное решение менеджмента — направить силы не на исправление багов, а на то, что нужно пользователям. То есть на развитие проекта. Или на исправление реальных (проявляющихся у пользователей) багов. Потому что основные баги — они не в кодировании, а в алгоритмах.
Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет. В серверной част работает два десятка нитей. Теоретическая плотность ошибок — 2-4 ошибки на тысячу строк. Время на комплексную отладку — ноль. Теоретически у нас было два часа в месяц, но мы их не использовали. Количество багрепортов за время промышленной эксплуатации (15 лет) — ноль. Что не означает, что багов там нету. Просто система сделана так, что она надежна несмотря на баги.Andrey2008
17.04.2017 09:51+3Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.
Теперь всё понятно. У вас очень маленький проект. И да, в таком проекте использование статического анализатора не является по настоящему нужным: низкая плотность ошибок, возможность обозреть весь проект и осознавать, как он работает.
Числа для сравнения. Весь проекте PVS-Studio мы считаем небольшим. А ядро C++ анализатора PVS-Studio вообще маленьким. Так вот, маленькое C++ ядро PVS-Studio содержит 225884 строк кода.
Это, пожалуй, пограничный размер, когда ещё можно обходиться без статического анализа кода. Мы используем инструменты для анализа своего кода (было бы странно для нас не использовать :). Но повторюсь, процесс развития проекта и его качество ещё можно контролировать вручную. Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.Jef239
17.04.2017 15:21+1Ну так об этом и надо было писать в статье! То есть о том, что речь идет о проекта больше 250KLoc.
И все-таки, проверьте гипотезу, что дело не в строках кода, а в количестве девелоперов. FAR 1.65 производства Рошаля не сильно отличается по возможностям от FAR 3.0 (сделанного сообществом). Интересно, насколько он отличается по плотности ошибок.
Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.
Зато инструменты динамического анализа полезны при любом размере. Например, у меня там был собственный анализатор утечек памяти. Заодно — они более-менее кроссплатформенны. Тот проект все равно PVS-Studio не проверит, он на Delphi (Object Pascal) был написал.
Нынешний, проверку которого я вам обещал — на С с элементами С++. Но он меньше 50KLoc,
Ну я рад, что мы сошлись. И даже поставил плюс в карму.
Andrey2008
15.04.2017 17:44+5Если честно, то не сталкивался с людьми, возражающими против инструментов статического анализа,
Вот сейчас Вы с ними и познакомитесь. :)Jef239
17.04.2017 04:32-2Просьба не передергивать, я не против статического анализа вообще. Тот статанализ, что встроен в gcc и clang — более, чем полезен. А вот цена PVS-studio — не оправдывается той мелочью, что он находит. По крайне мере, если судить об этом по блогу самой PVS-studio. Ну а cppcheck — просто не стоит времени, потраченного на разбор того, что он выдал.
И еще раз повторюсь. Причина ложных срабатывай — отнюдь не баги в коде. Это проблемы алгоритмов. У других проектов — ситуация примерно такая же. Поэтому, если есть лишние деньги — разумней их тратить на развитие.
Признайтесь честно, вы же не купили себе coverity? Хотя некоторое количество багов он бы вам нашел. Вот и другие не хотят покупать примерно по тем же причинам.
rkosolapov
17.04.2017 11:51+2Мне показалось, что говоря «против инструментов статанализа» автор имеет в виду «против ПВС-студии». Это сильно разные вещи таки.
koronabora
15.04.2017 15:04+3Прогнал свой личный проект, из 13к более-менее осмысленного кода, реальных ошибок было 3 штуки, ложных срабатываний — около 15 штук. Использовал бесплатную версию. Программистом себя считаю ниже среднего уровня. Тулза особенно полезна на огромных проектах, как я вижу из статей.
lany
15.04.2017 18:01+1Тут ещё штука, смотря что считать ложным срабатыванием. Некоторые называют ложным срабатыванием любой код, который не приводит к реальному багу. К примеру, повторное условие в цепочке OR, которое уже было в той же цепочке. Однако это не ложное срабатывание. Такой код — мина замедленного действия. Завтра надо будет расширять это условие и новый разработчик будет не уверен, действительно ли ветка лишняя и её надо убрать или имелось в виду что-то другое, и её надо оставить. Он потратит время, чтобы разобраться, и может прийти к неверным выводам, внеся новый баг.
SvyatoslavMC
15.04.2017 19:14+2В подтверждение ваших слов приведу пример из моего недавнего общения с разработчиком открытого проекта:
Код с ошибкой (бессмысленный код, мина… трактуйте как хотите):
DiscriminantChecks makeDiscriminantChecks(....) { .... bool shouldIncludeStructInit = kind == FieldKind::STRUCT || kind == FieldKind::BRAND_PARAMETER; bool shouldIncludeSizedInit = kind != FieldKind::STRUCT || kind == FieldKind::BRAND_PARAMETER; // <= .... }
Комментарий разработчика:
Thanks for the report.
While it's true that the right-hand side of the expression is redundant, the logic is in fact correct. This happened because when BRAND_PARAMETER was added, all of these booleans needed to be true for it, so || kind == FieldKind::BRAND_PARAMETER was appended to all of them.
Ну нет, так нет. Путь будетложным срабатываниемжить вечно в коде.Jef239
17.04.2017 04:41-1Думаю, что дело в поиске. Если автор кода часто использует поиск — ему удобнее писать именно так, чем
bool shouldIncludeSizedInit = shouldIncludeStructInit;
По этим же причинам используются две переменные вместо одной. gcc все равно оптимизирует общие выражения и сделает замену переменных. А вот при поиске по shouldIncludeSizedInit покажутся куски кода, связанные именно с этой функциональностью.
Jef239
17.04.2017 04:54-1Тьфу, я неправ, там != во второй строке.
Так что вообще не вижу причин удивляться такому коду. Логика простая. Птицы — это не звери. Но и те и те теплокровные.lany
17.04.2017 11:05+1Тьфу, я неправ
Вот, вот оно! Вы видите! Вы сами можете проморгать в коде существенное отличие в двух строчках! Глаз замыливается. Как же вы можете гарантировать, что никогда не проморгаете такое отличие в своём коде?
Тут как раз статанализ и приходит на помощь. Если б две подряд идущих переменных были бы инициализированы точно одинаковыми условиями, он бы ругнулся на это, а иначе ругается на другое. А варнинги gcc здесь не помогают.SvyatoslavMC
17.04.2017 11:26Отличный пост, будем на него ссылаться теперь, особенно при общении с Jef239. :D
Jef239
17.04.2017 15:40-2Свой код я все-таки пишу, а не только читаю. Опечаток у меня много, но вот такого типа — не припомню. Зато «точка хрения» бывает регулярно.
Методик, которые помогают — много. Вопрос в том, какие из них оправдывают свою цену. В конце концов предупреждения компилятора — это тоже статический анализ. Просто разработчики gcc выбрали набор предупреждений с низким числом ложных срабатываний.
Andrey2008
15.04.2017 18:08+4Тулза особенно полезна на огромных проектах, как я вижу из статей.
Да, анализатор становится всё полезнее с ростом проекта. Чем больше проект, тем больше плотность ошибок. 13k — это очень маленький проект.
Таблица. Книга Стива Макконнелла «Совершенный код». Размер проекта и типичная плотность ошибок. В книге указаны источники данных: «Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).
Таким образом, есть шанс, что в таком проекте вообще не будет ошибок. :)
edogs
15.04.2017 16:14+3За что в свое время выбрали зенд студию как пхп-иде — так это за встроенный (хотя и простой) статический анализатор кода. Штука полезная. Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего
Вот точно, статья для менеджеров. Программист или математик сразу увидит неточность (или даже ложность) этого утверждения.
Объяснение для менеджеров: если уборщица получает 5 рублей, ее менеджер получает 25рублей, управляющий ее менеджера получает 30р и программист получает 30р, то среднее (арифметическое) будет 22.5, при этом 75% персонала будет получать зарплату выше средней. А отнюдь не 50%.Andrey2008
15.04.2017 18:13+2Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
Статический анализатор используется неправильно. Они не должны накапливаться! Полная аналогия с предупреждениями компилятора — их не должно быть. Иначе вступает в силу теория разбитых окон.edogs
15.04.2017 18:37Анализатор используется правильно. То что они не должны накапливаться — никто не спорит, но это проблема анализатора и его ложных срабатываний. Наличие которых в анализаторе даже авторы pvs не отрицают.
Andrey2008
15.04.2017 18:43+3Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.
Для этого есть масса способов. Например, можно изменить код. При этом как правило он становится проще и понятней, причем не только анализатору, но и коллегам. Очень часто анализатор выдаёт предупреждения на код, который написан в стиле «смотрите, как я могу».
Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа, если там сгенерированный код или какие-то тесты, аномальные с точки зрения анализатора: if (A == A) для проверки реализации оператора ==.edogs
15.04.2017 20:00+2Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.
Э.
Во-первых, мы говорили о зенд-студию когда говорили что их накапливается слишком много.
Во-вторых, мы говорили о пхп и об отсутствии проблем с ложными срабатываниями в pvs студию в пхп можно будет говорить не раньше чем pvs студию научится с пхп работать. Кстати, непонятно почему не работает — рынок достаточно большой, задача сравнительно (с уже реализованными) простая.
И если все же выйти из контекста — выше тоже достаточно жалоб на ложные срабатывания именно в pvs студии.
нет никакой проблему убирать: можно изменить код, Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа
Навеяло: «нет никакой проблемы забивать гвозди микроскопом — можно изменить гвозди, можно усилить микроскоп в местах сочленения, можно разметить направление ударов что бы микроскоп не ломался, можно некоторые гвозди не забивать».
Понимаете какая штука, инструмент должен экономить время и работать. А когда разработчик инструмента говорит что «инструмент кривоват конечно, но можно же и самому доработать», то это навязывание обязанностей по принципу «ну тебе че сложно что-ли» совсем не радует. До определённой степени дорабатывать можно, но рано или поздно количество доработок и время на них потраченное начинает превышать выгоду от использования инструмента. Это все же не опен-сорц где получаешь удовольствие от доработки и контрибьюта получив его бесплатно, а платный продукт который должен работать на покупателя, а не наоборот.
Возьмем чуть пример в сторону. Вот есть куча коде-бьютифайеров. Каждый разраб свой нахваливает и говорит что мол «даже если что не так можно настроить», а вот в зенд-студии (вторая причина почему она нам нравится) «коде бьютифайер» работает из коробки без косяков. И? И всё.Am0ralist
15.04.2017 21:27+1Понимаете какая штука, инструмент должен экономить время и работать. А когда разработчик инструмента говорит что «инструмент кривоват конечно, но можно же и самому доработать», то это навязывание обязанностей по принципу «ну тебе че сложно что-ли» совсем не радует
То есть код сомнительный пишет разработчик, а кривоват инструмент, который это видит?
Вообще-то ситуация ровно обратная: инструмент показывает, что у вас тут немного кривовато, а разработчик ему может сказать: «забей и так сойдет» и этим экономит время.
А так то и компиляторы можно обвинять в то, что они выводят предупреждение на то, что переменная инициализирована была, но ни разу не использовалась. Я так захотел, чего он мне постоянно это напоминает? Или что переменная используется без инициализации, хотя я точно знаю, что в эту ветку кода никогда исполнение не попадет, не пройдя изначально другую ветку, где переменная инициализируется, просто мне влом переписывать.
Говорит ли это о том, что инструмент плохой, что он не догадался самостоятельно о том, что все ровно так, как я и хотел?edogs
15.04.2017 21:55+1То есть код сомнительный пишет разработчик, а кривоват инструмент, который это видит?
От оно чё, михалычь.
Т.е. «ложных срабатываний» не бывает, бывает только «код сомнительный».
При чем «сомнительный» по мнению стороннего инструмента (для этого кода и проекта), но инструмент разумеется умнее разработчика, ему лучше знать, сомнительный код или нет.Andrey2008
15.04.2017 23:50+1Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)
Например, мы недавно проверяли проект PascalABC.NET с помощью SonarC# и PVS-Studio. И по нашему мнению, дело обстоит так:
Не будем точно считать проценты ложных срабатываний, так как мнение может быть предвзятым. Но все равно понятно, что осилить 700 сообщений проще, чем 1800. И ясно, что 1800 может сильно утомить и испортить аппетит к статическим анализаторам.edogs
16.04.2017 16:57Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)
Может, спорить не будем. Подскажете нормальный?:)
lany
17.04.2017 11:09+1Конечно же PhpStorm!* Не знаю насчёт зенд-студии, но в PhpStorm в пару кликов можно подавить, настроить или отключить диагностику, которая вам не по душе.
* Дисклеймер: я аффилирован с компанием-производителем, и моё мнение может быть небеспристрастным.
staticlab
15.04.2017 22:09+1А в Зенд-студии нельзя подавить ложные срабатывания анализатора или гибко его настроить? К слову, есть мнение, что контроль качества кода должен производиться независимо от используемой IDE. У нас это делается проверкой при коммите (невалидный код просто не будет закоммичен). В C++ можно использовать проверку ветки на CI-сервере.
Кроме того
Штука полезная. Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
рано или поздно количество доработок и время на них потраченное начинает превышать выгоду от использования инструмента
платный продукт который должен работать на покупателя, а не наоборот.То есть анализатором в платной IDE вы пользуетесь ровно до того момента, пока он вам не надоедает своими придирками. При этом настроить его, чтобы он удовлетворял вашим потребностям, вы не можете или не хотите. Ну и какой тогда прок от него?
edogs
16.04.2017 17:05А в Зенд-студии нельзя подавить ложные срабатывания анализатора или гибко его настроить?
Можно, но о том и речь, что на определенной стадии количество настроек и подавлений становится выше некоей критической точки.
И если для проекта разрабатываемого «с нуля», это еще куда ни шло (у нас пет проект у зендовского анализатора вопросов не вызывает), то когда входишь в новый проект и надо неделю потратить на настройку — это уже малоинтересно.
При чем очень много логичных, но необычных придирок. Например, перманентно ругается на if(a=5), ему видишь ли надо что бы if(5=a) было, что бы замечания не выдал. Да, мы понимаем причины, но во многих проектах так пишут?
Ну и какой тогда прок от него?
Ну определенная польза есть. Просто обидно что для использования на 100% нужно прилагать несоразмерное количество усилий по тюнингу.webkumo
16.04.2017 18:42Зенд-студия не умеет
Можно подавлять точечно, используя комментарии.
?
Ну попробуйте php storm… Конкретно с этой IDE не работал, но по идее должно работать так же как и в главной IDE линейки — Idea.
staticlab
17.04.2017 10:25+1Просто обидно что для использования на 100% нужно прилагать несоразмерное количество усилий по тюнингу.
Не знаю, как там в Зенде настраивается, но в ESLint при подобной ошибке, если такие предупреждения нам действительно неинтересны, то достаточно добавить одну строку в конфиг, чтобы выключить ошибку сразу во всём проекте. И такие микрооптимизации линтинга проще делать по мере поступления проблем.
Am0ralist
15.04.2017 19:26+1Штука про то как 90% людей уверено, что их IQ выше среднего.
Программист или математик сразу увидит неточность (или даже ложность) этого утверждения.
Объяснение для менеджеров:
Математик, скорей всего, скучно заметит вам, что распределение зарплат в организации явно не подчиняется нормальному распределению, а вот способности программистов не ограниченных рамками одной организации — скорей всего будет ближе.
И ваш пример — это вообще расчет средней температуры больных по больнице с учетом морга. И вот он не просто не точен, а явно ложен.edogs
15.04.2017 20:10+1Штука про то как 90% людей уверено, что их IQ выше среднего.
А интернет-опрос показал что 90% респондентов пользуются интернетом.
И ваш пример — явно ложен.
Ошибаетесь.
Задача примера была показать что утверждение «В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего»© не является абсолютом, он это показал.
Математик, скорей всего, скучно заметит вам, что распределение зарплат в организации явно не подчиняется нормальному распределению, а вот способности программистов не ограниченных рамками одной организации
Ага, так и запишем, распределение способностей программистов ограниченных рамками одного опроса подчиняется нормальному распределению и в опросе «из 100 человек 50 всегда будут выше и 50 — ниже среднего»©Am0ralist
15.04.2017 21:08А интернет-опрос показал что 90% респондентов пользуются интернетом.
Вы в аналогии вообще никак. Особенно с мат.статом, не ваше это.
В моей (не)шутке базис не ограничен, что указывает именно на проблемы восприятия действительности и реальной оценки своих возможностей людьми.
У вас же шутка о некорректных условиях опроса.
Окей, шутка для реальных математиков и физиков: «90% молекул газа считает свою скорость выше средней»
Задача примера была показать что утверждение «В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего»© не является абсолютом, он это показал.
Некорректным «доказательством» не получится ничего показать. Это — логика.
Более того, некорректным приемом вообще являлся довод о том, что «программисты и математики сразу увидят неточность» — это недоказуемый аргумент с аппеляция к публике и «авторитету» групп программистов и математиков. Но на самом деле это было исключительно ваше мнение, которое вы не рискнули выдвинуть от своего имени из-за недостаточности вашего авторитета, пусть и не осознанно.
так и запишем, распределение способностей программистов ограниченных рамками одного опроса
Вы серьезно? Вообще-то статистику собирают именно так, стараясь, что бы участники опроса подчинялись общему для всех правилу. В противном случае это будет то, что описали вы в своей шутке про пользованием интернетом. Так что, если вы не отбирали специально 100 самых умных людей на планете на основе предыдущих глобальных исследований IQ, то в среднем скорей всего именно так и получится.
То есть еще раз: в отдельном конкретном случае спец.выборки может быть не так, да, но в среднем утверждение будет верно. С учетом, что большинство наук изучает именно «среднее» поведение и по сути являются статистическими (как та же физика), то по сути вы сейчас пытаетесь доказать истинность моей шутки про молекулы:
Теоретически можно отобрать 100 молекул газа так, что бы их распределение было не по максвеллу (взять 10 самых медленных молекул и 90 самых быстрых), однако это никак не опровергнет физику.
Вот если бы вы усомнились в том, что распределение — обязательно нормальное, тогда да. Но вы изначально взяли заведомо неверную выборку и этим что-то пытались показать. И я как раз с точки зрения математики на это указал.edogs
15.04.2017 22:00+1Вы в аналогии вообще никак. Особенно с мат.статом, не ваше это.
Если Вы не понимаете аналогию, это не значит что «она никак», это значит что Вы ее не понимаете.
Некорректным «доказательством» не получится ничего показать. Это — логика.
Естественно. Именно поэтому был приведен корректный контр-пример, показывающий что есть как минимум одна ситуация, когда заявленное правило не работает. Вы правда этого не поняли?
Вы серьезно? Вообще-то статистику собирают именно так, стараясь, что бы участники опроса подчинялись общему для всех правилу.
Вы серьезно? Вообще-то статистику по опросам достаточно редко стараются так собирать (по маркетинговым причинам), а даже когда собирают с прицелом на это то все равно это редко получается — т.к. идеальные условия миф.
Вот если бы вы усомнились в том, что распределение — обязательно нормальное, тогда да.
Вообще-то об этом сообщение и было. Жаль что Вы этого не поняли.
Andrey2008
16.04.2017 00:22+1Сейчас случайно наткнулся на просторах интернета на интересное обсуждение. В общем, количество предупреждений, выдаваемых PVS-Studio постепенно растет и один неравнодушный замечает, что "It seems that bugfixing is going wrong..." :)
Это я просто на примере хочу ещё раз продемонстрировать, что анализатор может показывать менеджеру о некоторых процессах, происходящих в проекте. Как я писал в статье, анализатор кода это не только инструмент для поиска ошибок, но и один из инструментов для контроля и слежения за происходящим. Он позволяет держать менеджеру руку на пульсе проекта.
PapaPadlo
17.04.2017 01:53Видимо, разработчиков этой студии стоит поздравить со взятием еще одной вершины: они так задолбали программистское сообщество своей рекламой (оно реально из каждого утюга сейчас), что когда приходят в любую компанию натыкаются лишь на раздражение. Теперь им приходится аппелировать к менеджерам прямо оскорбляя программистов, утверждая, что 90% их — обладатели синдрома Даннинга-Крюгера, а сами они хорошие. Сам я не программист ни разу (пишу немного на питоне), но даже меня, админа, это задолбаоло.
Jef239
17.04.2017 05:08-2Основная причина задалбывания — эти люди считают, что исправление мелких ошибок — это самое главное. В квартире кроватей нет, вместо пола — бетонные стяжки. Сантехника стоит, но дверь в туалет ещё не поставили. И тут эти «заплатите нам и мы втридорога помоем окна». :-)
Deosis
17.04.2017 06:52Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?
Настоящий программист спросил бы сначала, как считается среднее?
Среднее среди всех людей?
Среднее среди программистов?
Среднее среди участников конференции по высоконагруженным проектам?
irepetitor_ru
17.04.2017 08:36Может быть есть какая-то sensitivity-specificity статистика анализатора в зависимости от настроек?
Или это слишком глубоко?Andrey2008
17.04.2017 08:36Не понял вопрос. Прошу уточнить.
lany
17.04.2017 11:13sensitivity-specificity — это про ошибки первого и второго рода; про false-positive и false-negative. Всякие статистики-биологи строят ROC-кривые и считают AUC.
Andrey2008
17.04.2017 11:48+2Не знаю, что здесь ответить. Не занимались какой-то такой статистикой.
P.S. Желающие могут брать SonarSource, прицепить наш анализатор и настроить графиков и зависимостей на любой вкус.
irepetitor_ru
18.04.2017 12:17+1почему именно статистики-биологи, а не статистики-радио-физики или статистики-экономисты?
lany
18.04.2017 12:39+2Особенно популярны ROC-кривые у статистиков-зануд.
irepetitor_ru
18.04.2017 12:47-3Моя задача набирать комментарии в разных новых постингах, а не в одном треде у самых злобных троллей хабра. Как вас только сюда вахтёр пропустил…
AnROm
17.04.2017 14:16+3Статья точно для менеджеров, так как не содержит ни одного единорога )) У меня знакомый есть, который почти уговорил менеджеров использовать в проектах PVS Studio, как те зашли на ваш сайт и сказали, что какие-то несерьезные ребята
Andrey2008
19.04.2017 11:32В продолжении этой темы: Простая ошибка при кодировании — не значит нестрашная ошибка.
Lauren
По моему опыту, те программисты которые не любят статический анализатор в основном банально редко его запускают из-за чего возникает множество ложных срабатываний.
EvgeniyRyzhkov
Есть еще такие, которые не любят, хотя и ни разу не запускали :-).
Andrey2008
Так оно и есть. К сожалению, для индустрии, многие никак не могут осознать, что вывод анализатора нужно держать чистым. А ведь это уже давно описано, разобрано и обсуждено для предупреждений компилятора. Когда накапливаются предупреждения компилятора, люди перестают их читать, они перестают помогать, а только мешают. Именно отсюда растут ноги у ключей компилятора, заставляющих интерпретировать предупреждения как ошибки.
Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию. Используя административные рычаги, он может заставить не оставлять варнинги и внедрять анализаторы. Вот так и живём.
webkumo
Обычно как раз менеджер и является причиной