Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Статья о статическом анализе кода для м…

Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам

14 Апр 2017

Если вы считаете себя хорошим программистом, ну, скажем так, вы оцениваете свой уровень выше среднего, прошу не читать эту статью. Эта статья предназначена для менеджеров программных проектов. С ними я хочу обсудить хотя и важные, но скучные для программистов вопросы, связанные с методологией статического анализа кода.

0498_static_analysis_for_project_managers_ru/image1.png

Надеюсь, введение отпугнуло от чтения хотя бы некоторых программистов. Кто-то, наверное, из принципа продолжил чтение, но что ж, это их добровольный выбор. Мы поговорим о вещах, которые неприятны программистам.

Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.

Любому менеджеру, да и самим программистам понятно, что качественный код лучше, чем некачественный. Понятно и то, что чем реже в программе проявляются глюки, тем лучше.

Самое интересное начинается дальше. Хотя все признают важность качественного кода, некоторые программисты приходят просто в негодование, когда им предлагают использовать статический анализ кода. Такое впечатление, что их оскорбили, усомнившись в их профессионализме, и они спешат ответить всем арсеналом своей негативной критики. За годы мы услышали огромное количество нелестных отзывов, приблизительно следующего содержания:

  • "это инструмент для Макдональдса, а в нашей команде работают эксперты, и если у нас и бывают ошибки, то они связаны только с синхронизацией потоков"
  • "мы не используем статический анализ кода, так как набираем только профессионалов выше среднего"

Думаю, если бы в момент таких дискуссий рядом присутствовал менеджер проекта, то немало программистов получило от него щелбан за гордыню. Каждый руководитель может вспомнить, как несколько дней искали ошибку, которая потом оказалась какой-то глупой опечаткой. Или менеджера может начать одолевать скепсис: если все так хорошо, почему приложение продолжает падать время от времени? Менеджеры не так радужно, как программисты, относятся к процессу разработки проекта и возникающим проблемам.

0498_static_analysis_for_project_managers_ru/image2.png

Рисунок 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 может показывать ошибки, относящиеся только к новому или измененному коду (см. массовое подавление сообщений анализатора).

Следует скептически относиться к возражениям программистов на тему того, почему им не нужен статический анализатор. Им-то, может, он действительно не нужен. Он нужен проекту. Эта одна из методологий, такая же как, например, юнит-тесты, которая позволяет повысить надежность программы и, тем самым, сократить траты на её сопровождение. Чем быстрее какие-то ошибки будут найдены, тем лучше. Статические анализаторы позволяют выявлять ошибки на самом раннем этапе, т.е. сразу, как только они появятся в коде.

0498_static_analysis_for_project_managers_ru/image3.png

Рисунок 2. Учтите, некоторые программисты используют статический анализ неправильно.

Ещё один важный момент. Некоторые программисты могут заявить, что при тестовом прогоне ошибок найдено мало, поэтому внедрение анализатора кода нецелесообразно. Не дайте им себя запутать. Конечно, ошибок в отлаженном и работающем коде будет немного, иначе бы программа не работала. Однако, поиск и устранение ошибок может обходиться очень дорого. Часто многие жалобы пользователей и часы медитации программистов в отладчике могли бы просто исчезнуть, благодаря одному запуску анализатора кода. Вся суть и польза статического анализа в его регулярном применении, а не разовых запусках.

Несколько раз я сам слышал, что некоторые программисты запускают статические анализаторы при подготовке к релизу. Если кто-то так делает и утверждает, что это нормально, то он профнепригоден. Это самый неправильный способ использования статических анализаторов. Это то же самое, что включать перед релизом предупреждения компилятора, а все остальное время работать над проектом, полностью их отключив.

Спасибо за внимание. Приглашаю всех, кто заинтересовался методологией статического анализа в целом и анализатором PVS-Studio в частности, написать нам. Мы поможем проверить ваш проект, настроить анализатор, и подскажем, как разобраться с выданными предупреждениями.

Популярные статьи по теме
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

Автор: Андрей Карпов

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…
Эффект последней строки

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

Автор: Андрей Карпов

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.

Комментарии (0)

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять