Если вы считаете себя хорошим программистом, ну, скажем так, вы оцениваете свой уровень выше среднего, прошу не читать эту статью. Эта статья предназначена для менеджеров программных проектов. С ними я хочу обсудить хотя и важные, но скучные для программистов вопросы, связанные с методологией статического анализа кода.
Надеюсь, введение отпугнуло от чтения хотя бы некоторых программистов. Кто-то, наверное, из принципа продолжил чтение, но что ж, это их добровольный выбор. Мы поговорим о вещах, которые неприятны программистам.
Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.
Любому менеджеру, да и самим программистам понятно, что качественный код лучше, чем некачественный. Понятно и то, что чем реже в программе проявляются глюки, тем лучше.
Самое интересное начинается дальше. Хотя все признают важность качественного кода, некоторые программисты приходят просто в негодование, когда им предлагают использовать статический анализ кода. Такое впечатление, что их оскорбили, усомнившись в их профессионализме, и они спешат ответить всем арсеналом своей негативной критики. За годы мы услышали огромное количество нелестных отзывов, приблизительно следующего содержания:
- «это инструмент для Макдональдса, а в нашей команде работают эксперты, и если у нас и бывают ошибки, то они связаны только с синхронизацией потоков»
- «мы не используем статический анализ кода, так как набираем только профессионалов выше среднего»
Думаю, если бы в момент таких дискуссий рядом присутствовал менеджер проекта, то немало программистов получило от него щелбан за гордыню. Каждый руководитель может вспомнить, как несколько дней искали ошибку, которая потом оказалась какой-то глупой опечаткой. Или менеджера может начать одолевать скепсис: если все так всё хорошо, почему приложение продолжает падать время от времени? Менеджеры не так радужно, как программисты, относятся к процессу разработки проекта и возникающим проблемам.
Рисунок 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 может показывать ошибки, относящиеся только к новому или измененному коду (см. массовое подавление сообщений анализатора).
Следует скептически относиться к возражениям программистов на тему того, почему им не нужен статический анализатор. Им-то, может, он действительно не нужен. Он нужен проекту. Эта одна из методологий, такая же как, например, юнит-тесты, которая позволяет повысить надежность программы и, тем самым, сократить траты на её сопровождение. Чем быстрее какие-то ошибки будут найдены, тем лучше. Статические анализаторы позволяют выявлять ошибки на самом раннем этапе, т.е. сразу, как только они появятся в коде.
Рисунок 2. Учтите, некоторые программисты используют статический анализ неправильно.
Ещё один важный момент. Некоторые программисты могут заявить, что при тестовом прогоне ошибок найдено мало, поэтому внедрение анализатора кода нецелесообразно. Не дайте им себя запутать. Конечно, ошибок в отлаженном и работающем коде будет немного, иначе бы программа не работала. Однако, поиск и устранение ошибок может обходиться очень дорого. Часто многие жалобы пользователей и часы медитации программистов в отладчике могли бы просто исчезнуть, благодаря одному запуску анализатора кода. Вся суть и польза статического анализа в его регулярном применении, а не разовых запусках.
Несколько раз я сам слышал, что некоторые программисты запускают статические анализаторы при подготовке к релизу. Если кто-то так делает и утверждает, что это нормально, то он профнепригоден. Это самый неправильный способ использования статических анализаторов. Это то же самое, что включать перед релизом предупреждения компилятора, а все остальное время работать над проектом, полностью их отключив.
Спасибо за внимание. Приглашаю всех, кто заинтересовался методологией статического анализа в целом и анализатором PVS-Studio в частности, написать нам. Мы поможем проверить ваш проект, настроить анализатор, и подскажем, как разобраться с выданными предупреждениями.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. A post about static analysis for project managers, not recommended for the programmers
Комментарии (0)