Скачай PVS-Studio и найди ошибки в С, С++,C# коде
281,86
рейтинг
19 августа 2014 в 09:17

Разработка → Новая услуга: регулярный аудит Си/Си++ кода

PVS-Studio, аудит кода

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

Беды статического анализа, как продукта


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

Разберём в начале причины, из-за чего инструмент статического анализа может негативно восприниматься разработчиками.
  1. Пробуя инструмент статического анализа, программист видит мало настоящих ошибок и много ложных срабатываний (пояснения). Вдаваться в подробности методологии статического анализа разработчику нет времени и не хочется. У него много текущих дел. Поэтому он стремится побыстрее вынести решение, что инструмент бесполезен и вернуться к прежним делам. К счастью, именно это не так страшно. Программисту можно объяснить, что основное преимущество от статического анализа в регулярном использовании, а не в разовых проверках. Хорошая аналогия — предупреждения компилятора. Он ведь включает их не пару раз в год, а работает с ними постоянно.
  2. Тем не менее, даже во время пробных запусков PVS-Studio умудряется найти настоящие ошибки в коде. Из-за этого, к несчастью, может превратиться в кровного врага. Некоторые совершенно не умеют переносить критику. Даже если это вывод программы. Такой вывод можно сделать, как логическими заключениями, так и по негативу, который иногда сваливается на нас. Со стороны это сложно понять. Если в коде находятся ошибки, для компании хорошо. Но для человека, который допустил ошибку, это неприятно. Он не подаст виду, но будет неосознанно стараться избежать ситуации, когда ошибку находит кто-то другой, а не он сам. Это можно добиться, сделав так, чтобы статический анализ более не использовался. Нерациональное решение с точки зрения командной работы, но зато человек чувствует себя более комфортно. Именно из-за такого саботажа некоторые руководители отделов разработки берут на себя роль по анализу диагностических предупреждений. В такой ситуации программисту деваться некуда. Программисты после чтения этого пункта будут возмущены. Именно поэтому я не рекомендовал этот текст им к прочтению :).
  3. Кажется, что статический анализ отнимает время от работы. Заметно время, которое человек регулярно будет тратить на настройку анализатора и регулярную работу с ним. Но совершенно непонятно, сколько времени и сил сэкономит быстро устранённая опечатка, найденная при анализе кода.
  4. Перейдём от психологического дискомфорта к практическим неудобствам. Часто программисты не понимают, что хочет им сказать статический анализатор кода. К сожалению, PVS-Studio не обладает искусственным интеллектом, чтобы составить рассказ о том, почему вот здесь может быть ошибка. Эта большая реальная проблема. Программисты не виноваты. Требуется время и опыт, чтобы научиться понимать сообщения анализатора. В результате, возможности PVS-Studio остаются недооценёнными. Я хорошо вижу это из общения в поддержке. Люди пишут о том, что встретили то или иное ложное срабатывание и предлагают его исправить. В процессе уточнения нередко выясняется, что это самая настоящая ошибка, и разработчики не заметили её или даже не могли предположить, что такая ситуация может быть. Это печально. Ведь речь идёт о тех, кто нам написал. Можно сделать предположение, что множество настоящих ошибок не воспринимается и размечается как ложное срабатывание. Кстати, такая беда не только у статических анализаторов. Даже поведение компилятора интерпретируется неправильно (примеры).
  5. Ложные срабатывания. К сожалению, они были, есть и будут. Такова уж суть методологии статического анализа кода. С ложными срабатываниями можно бороться улучшая код, или подавляя их с помощью настроек. В любом случае это труд и им неинтересно заниматься. Плюс это опять требует времени для накопления опыта. Ложные срабатывания очень портят впечатление от продукта. Но, продавая PVS-Studio, как продукт, мы не можем ничего с этим сделать.

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

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

Новое предложение: аудит


Опишу, как строится процесс аудита и его преимущества.

Процесс:
  1. Мы подписываем NDA, который позволит передавать нам код.
  2. Заключаем контракт. Мы ориентируемся на годовые контракты. Однако, всегда хочется в начале попробовать. Поэтому возможен вариант заключения пробного трёхмесячного контракта. Менее, чем на 3 месяца заключать контракт бессмысленно. Мы должны научиться компилировать ваш проект, научиться автоматически выкачивать обновления, научиться проверять его, настроить анализатор, заставить ваших админов не банить наши письма и так далее. Пока все эти вопросы будут утрясены, пройдёт месяц. И нужно ещё хотя-бы 2 месяца, чтобы оценить пользу от сотрудничества.
  3. На первом этапе наш сотрудник просмотрит все диагностические сообщения общего назначения, выданные анализатором, и предоставит отчёт о найденных дефектах. После чего уже начнётся ежедневный аудит нового кода.
  4. Выделенный опытный сотрудник ежедневно занимается с вашим проектом. Если что-то сломалось, то чинит сборку проекта. И самое главное, просматривает результаты анализа. Если он находит подозрительное место в коде, то он уведомляет вас. При этом он может уведомлять именного того сотрудника, который заложил код, приводящий к предупреждению.
  5. В случае, если ошибка не очевидна, наш сотрудник поясняет её, а также оказывает консультации по тому, как лучше её исправить.

Преимущества аудита:
  • Вам не надо задумываться, есть Linux-версия PVS-Studio или нет. Это наша задача адаптировать анализатор для используемой вами операционной системы и компилятора. Если у вас не используется для разработки что-то экзотическое, мы сумеем проверить ваш код.
  • Сотрудники не могут сознательно или бессознательно саботировать регулярную проверку кода. Им будет некуда деться.
  • Мы получаем деньги за то, что ищем ошибки. А значит заинтересованы внимательно относиться к предупреждениям анализатора. Программист склонен назвать ошибку не ошибкой или просто ленится изменить явно плохой код. В случае аудита всё будет на виду. Мы получаем преимущество: не замалчиваются ошибки, которые нашёл PVS-Studio, что подтверждает ценность инструмента. Вы получаете преимущество: внимательный анализ диагностических сообщений.
  • Ваши программисты не работают с ложными сообщениями. При этом не потребуется вносить какие-либо правки в код, чтобы устранять ложные срабатывания. Вы получаете информацию только о настоящих проблемах в коде или явно плохом коде. Ложные срабатывания — это наша проблема, с которой мы справимся. Сбывается мечта программиста — вы получаете инструмент, который почти никогда не будет давать ложных срабатываний!
  • Информация о найденных дефектах приходит руководителю и конкретно тому программисту, кто написал опасный код. Программист сможет легко поправить свой собственный код. Менеджер будет видеть общую картину.
  • Мы хорошо понимаем, как работает статический анализатор. Поэтому мы сможем снабжать диагностические сообщения анализатора дополнительными комментариями, которые помогут человеку понять причину предупреждения. Это очень важный момент. Настоящая ошибка не будет по невнимательности помечена, как ложное срабатывание.
  • При желании, специалист, проводящий аудит, может давать рекомендации общего плана по улучшению кода. Он также поможет улучшить стандарт кодирования, используемый в компании.

Недостаток аудита:
  • Более замедленная реакция на дефект в коде. Самое эффективный режим — это проверка кода сразу после компиляции. В PVS-Studio имеется для этого режим автоматического анализа. В случае аудита, вы будете получать отчёт раз в день. Это, конечно, тоже очень хорошо, но всё-таки с запозданием.

Цены


Мы оцениваем 1 месяц аудита в 100 000р. Это экономно. Давайте посчитаем.

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

С учетом покупки лицензии, зарплаты нового квалифицированного сотрудника, а также, что сотрудник требует дополнительных накладных расходов (налог на зарплату, место в офисе, мощный компьютер для запуска тестов), то в 100 000 в месяц вы никак не уложитесь.

Таким образом, удалённый аудит может обойтись вашей компании не только дешевле, но и внедрить его будет намного проще. Всё сделают за вас. Вам надо только предоставить доступ к исходникам и анализировать информацию о найденных ошибках в коде.

Контакты


Если вас заинтересовал регулярный аудит кода, то с нами можно связаться воспользовавшись страницей "обратная связь" или по e-mail: support@viva64.com.
Автор: @Andrey2008
PVS-Studio
рейтинг 281,86
Скачай PVS-Studio и найди ошибки в С, С++,C# коде

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

  • +24
    Имхо в самом начале статьи не хватает фразы «На правах рекламы» ибо здесь вообще нет ничего полезного кроме рекламы.
    • +7
      Мистическим образом вы находитесь в блоге компании, где все так или иначе является рекламой ;)
  • +6
    Программистам можно читать. Ну круто же. Ведь, по-большоему счету, именно работа программистов упрощается. Вместо того, чтобы что-то долго настраивать, а потом долго разбираться в куче выхлопа анализатора, тебе будут сразу сообщать полезный сухой остаток.
  • +14
    На мой взгляд, здесь главная сложность — чтобы компании поверили в силу NDA и показали код сторонней организации.
    • 0
      Как думаете, что нужно сделать/предоставить, чтобы эту сложность решить?
      • +9
        Ничего не сделаешь. Есть печальный опыт слива баз, алгоритмов, и прочего из-под НДА.
        Мы просто в РФ.
        • +3
          С сотрудником с улицы есть такие же риски. Только у компании репутация еще имеется.
          • 0
            А вы гарантируете, что ваши сервера не взломают? Что исходники не сольет случайно ваш же сотрудник?
            • +3
              Этот вопрос очень серьезный. На него есть несколько вариантов ответа. Первый — самый простой:
              1. Да.

              А вот если поразмышлять на эту тему, то на мой взгляд сделать риски ниже, чем нанимать «человека с улицы» для работы с кодом. В том смысле, что когда компания нанимает нового сотрудника, то она имеет те же опасения: «А что если он окажется неадекватным и сольет исходники в Интернет». При этом компания риск такой понимает и готова с ним мириться.

              Не вижу, почему компания не может мирится с риском в случае такого контрагента.
              • +2
                Возможно расчет на то, что если человек сольет, то сделает это бесхитростно и его будет просто вычислить. А компания вначале посчитает свою выгоду и найдет подходящего покупателя :) Плюс возможности по использованию кода в своих целях у компании и у одного единственного человека сильно разные.
                • +2
                  Обычно утечки исходников боятся программисты. Любой менеджер понимает, насколько велика разница между исходниками и полноценным продуктом.
  • +1
    А как вы справитесь с кодовой базой крупной компании в N×100млн loc?
    • +13
      Большим ценником.
      • +1
        Разумеется, но если вы говорите, что
        Можно думать об этой услуге, как о сотруднике в штате.

        То для анализа большой кодовой базы в обозримые сроки нужно несколько сот таких сотрудников. Ваш софт-то пережует, но вот миллионы ложных и не ложных срабатываний кто будет анализировать?
        • +1
          Совершенно очевидно, что для больших проектов цена другая.
    • +1
      А если речь о технологиях, то сейчас мы прекрасно жуем проекты порядка 10 млн строк кода.
      • –1
        То есть для N=0.1 вопрос уже опробован.
  • 0
    PVSAS? :)
    Хорошая тема, но, подозреваю, что 100к/мес — не взлетит.
    Хотя, вру. Не взлетит как массовый сервис. Как сервис для крупных (в начале) компаний — взлетит.
    • +1
      Можно думать об этой услуге, как о сотруднике в штате.
      • 0
        100к/мес без НДС но и без других налогов, это как сотрудник на 65к в месяц. В принципе, неплохо.
        А как на счет «выкупа» настроек? То есть можно ли будет «соскочить с иглы» и таки переделать на проверку пост-билда?
  • 0
    Кстати, как раз очередной пример по пункту N4. Сейчас нам написал человек, который обнаружил, что анализатор ругается (V575) на следующий код:

    size_t strLen = _snprintf_s(NULL, 0, 0, "%sSeg%d-Frag%d",
                                me.url.c_str(), sre.firstSegment, fre.firstFragment+j);
    

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

    size_t strLen = _snprintf_s(NULL, 0, 0, "%sSeg%d-Frag%d", "123", 11, 22);
    cout << strLen << endl;
    

    Это код распечатает 0. Оказывается, что это не ложное срабатывание, а ошибка. Вот так и живём.
    • –3
      > Если buffer или format является пустым (NULL) указателем или если значение параметра count меньше или равно нулю, то вызывается обработчик недопустимых параметров.

      эээ… а оно когда-нибудь работало?
      • +1
        В сообщении, на которое вы отвечаете ясно написано, что не работало. Но будь это обыкновенная snprintf, созданная в соответствии с C99, всё было бы в порядке: значит, вероятно, разработчики, не читая MSDN, решили, что микрософтские функции работают в соответствии с C99 (хотя таких функций там нет).
        • +1
          Ясно написано, что написал человек, который решил, что это ложное срабатывание. Значит, он был уверен, что этот код — рабочий.
          • 0
            Это похоже на кусок кода, используемого для отладки. Там вполне могло быть незаметно. Возможно даже malloc(0) всё время возвращал что‐то, куда можно записать требуемое число байт — я не знаю, что конкретно значит «a zero-length item in the heap»: если этот элемент всё время выделяется на странице, доступной для записи (а зачем выделять где‐то ещё?) и после него достаточно свободного пространства (или не свободного, но занятого чем‐то некритичным), то всё вполне могло работать.
  • 0
    Сама идея делегировать аудит имеет право на жизнь. Похоже на тестирование — очень легко делегировать.

    Но вот ценник без привязки к размеру и сложности проекта…
    • 0
      Все это есть, не хочется основной текст забивать кучей таблиц и схем.
  • 0
    Обычно в билд включается что-то вроде coverity tool и все видят ошибки друг друга и быстро вешают это на автора.

    При постоянном создании проблем у автора снижаeтся performance и зарплата в итоге, а вскоре и сокращение.
  • 0
    А расскажите, какие еще есть решения в сфере аудита кода? Вы же, конечно, исследовали имеющиеся варианты, что вас выгодно отличает от конкурентов?
    • 0
      Если часть или весь бизнес компании связан с разработкой программных продуктов, то у нее есть варианты:
      1. Полностью надеяться на своих программистов, ведь с ТАКИМИ зарплатами они же не могут ошибаться. Или могут?
      2. Использовать инструменты для контроля кода. Например, статические анализаторы.
      3. Использовать услуги другой компании, для регулярного контроля кода.

      Мы можем помочь с пунктами 2 и 3.

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

Самое читаемое Разработка