До недавнего времени мы занимались исключительно развитием и продажей продукта 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.

Автор:

Источник