PVS-Studio: новый триальный режим

в 12:56, , рубрики: C, c/c++, c++, pvs-studio, static code analysis, Блог компании PVS-Studio, демо-версия, Си, статический анализ кода, статический анализатор кода

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

История

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

Как было раньше

Демонстрационная версия ничем функционально не отличалась от полной версии. Единственное ограничение — «количество кликов» (предыдущий демонстрационный режим описан в статье 2012 года).

Человек мог сделать ограниченное количество переходов к подозрительным участкам кода, щелкая по сообщениям в списке:

Рисунок 1. Оставшееся количество переходов по коду.

Рисунок 1. Оставшееся количество «переходов по коду».

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

В начале человеку давалось 100 «переходов». Затем ему предлагалось форма, где он мог указать и отправить информацию о себе. Тогда ему давалось ещё 100 «переходов».

Было очень-очень мало писем с контактной информацией, поэтому мы изменили пропорцию. Начали давать в начале 20 кликов, а ещё 200 можно получить, прислав нам контактную информацию. К сожалению, это не помогло. Стало не очень-очень мало, а просто мало.

Что нам не нравилось

У выбранного нами подхода было 2 проблемы. Одна небольшая, связанная с самим триалом. И вторая глобальная, связанная со сложностью демонстрации возможностей инструментов статического анализа. Начнём с меньшей проблемы.

Как нам кажется, ограниченное количество «кликов» отпугивает человека от знакомства с инструментом. Особенно, когда их в начале только 20. Человек начинает жадничать и просто смотрит список, не переходя к конкретным участкам кода. В добавок некоторым кажется, что предоставлено вообще только 20 переходов, что портит настроение.

Однако это всё несущественно по сравнению со следующей проблемой. Её мы осознали, наблюдая со стороны, как люди впервые устанавливают и начинают использовать наш анализатор.

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

Самая основная беда — люди начинают «включать всё на максимум». Это первое, что они делают. Они включают 3 уровень предупреждений и 64-битные диагностики, которые выключены по умолчанию. Так им кажется, что у них больше контроля и они смогут лучше оценить возможности инструмента.

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

Если программист «включил всё», то можно попрощаться с ним, как с потенциальным пользователем. Он будет крайне разочарован инструментом. Причина — вместо полезных сообщений он видит бессмысленный шум. Мы наблюдали это. Люди включают всё на максимум, и, просмотрев 30 неинтересных сообщений, теряют интерес. Всё. Позитивного знакомства не состоялось.

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

Кстати, не мы одни переживаем на эту тему. В статье "A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World" есть следующая мысль:

Первоначальные отчеты об анализе имеют для людей уж слишком высокое значение. Если первые N сообщений содержат ложные срабатывания (N=3?), они начнут заявлять что-то типа: «Этот инструмент — отстой!».

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

Что мы решили изменить

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

В демонстрационном режиме мы жёстко отключаем 2 и 3 уровень всех диагностик. И их нельзя включить.

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

Нам кажется, так у инструмента намного выше шанс понравиться людям. А уже если инструмент понравился, потом не будет проблема аккуратно разобраться с диагностиками и настроить анализатор. Самое главное найти и сразу показать ошибки в коде.

Итого: новая триальная модель

PVS-Studio можно скачать здесь. Демонстрационная версия имеет следующие ограничения:

  1. Для просмотра доступны сообщения только 1 уровня.
  2. Можно выполнить 50 переходов по коду. После этого анализатор предложит человеку отправить информацию о себе. Если он согласится, то ему будет предоставлено ещё 50 переходов.

Ограничения демонстрационной версии могут показаться суровы. Однако, от таких ограничений выиграем как мы, так и вы.

Просмотр только первого уровня предупреждений гарантирует, что человек не пропустит настоящие ошибки. Это очень важно. Нужно сразу показать наличие ошибок в коде. Это полезно и нам и потенциальному пользователю.

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

Получить письма и начать общение очень важно для нас. Часто мы можем помочь человеку с какими-то сложностями, возникающими при работе с анализатором кода. Помогаем что-то настроить, избавить от ложных срабатываний, поясняем сообщения анализатора. Очень часто мы можем превратить негативное впечатление в положительное и сделать человека клиентом. Достаточно бывает подсказать ему какую-то волшебную настройку. А чтобы сделать это чудо, нужно общаться.

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

Общаясь, мы сделаем анализатор PVS-Studio лучше, исправим множество ошибок в вашем коде и будем стоять на страже его качества! Пишите нам: support@viva64.com

Дополнительные ссылки

  1. Очень хорошая статья для первого знакомства с PVS-Studio. PVS-Studio для Visual C++.
  2. Демонстрация возможностей анализатора. Обновляемый список статей, в которых мы рассказываем об ошибках, найденных с помощью PVS-Studio в открытых проектах.

Автор: Andrey2008

Источник

Поделиться новостью

* - обязательные к заполнению поля