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

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

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

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

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

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

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

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

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

Как бы вы оценили свои навыки программирования? (Ниже среднего, среднего или выше среднего)?

На основании психологических исследований в разных группах около 90% всех программистов ответят Выше среднего.

Конечно, это не может быть правдой. В группе из 100 человек 50 - выше среднего, 50 - ниже среднего. Этот эффект известен как иллюзорное превосходство. Это описано в некоторых сферах, но даже если вы не слышали об этом, вы, скорее всего, ответите« выше среднего ».

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

Анализатор PVS-Studio находит ошибки в коде таких проектов, как Qt, MSBuild, LLVM, GCC, GDB, Chromium. Разработчиков этих проектов нельзя поставить ниже среднего. Однако это не мешает программистам ответить, что их код очень качественный и анализ для них совершенно не актуален.

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

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

Кстати, вот интересный рассказ по теме. Совсем недавно мой коллега проверил проект CryEngine V и обнаружил множество ошибок. Предупреждений высокого уровня было так много, что моему коллеге не хватило терпения просмотреть их все. Затем мы внезапно узнаем, что Crytek испытывает некоторые проблемы и несколько программистов не получают зарплату уже более 3 месяцев. Нездоровая ситуация в компании сказалась на качестве кода. Было интересно увидеть такие четкие отношения.

В общем, не бойтесь заставлять программистов использовать статический анализ кода. Пусть это будет не PVS-Studio, а какой-нибудь Cppcheck (который делает простые проверки, но бесплатно). Это уже будет здорово. Программист может начать возражать, поэтому менеджер должен оставаться твердым.

Часто программисты ссылаются на то, что работа с анализатором требует времени, вынуждая просматривать ложные срабатывания.

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

Доказательство: ошибка, которая занимала около 50 часов безуспешного поиска, была обнаружена и обнаружена менее чем за час.

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

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

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

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

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

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