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

Во многих из прочитанных мною статей делается такое предположение. Если в проекте размером N строк кода, найдено 2 ошибки, то в полноценном проекте размером в N*100 строк, можно найти только 200 ошибок. И из этого делается вывод, что статический анализ, это конечно хорошо, но не замечательно. Слишком мало ошибок. Лучше развивать другие методики поиска дефектов.

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

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

Он проверяет этот проект и делает линейную интерполяцию, как много ошибок он сможет отыскать в своём большом проекте. А потом пишет статью о проведённых исследованиях. 

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

Первый недочёт всех этих исследований очевиден. Забывают, что берётся рабочая отлаженная версия какого-то проекта. Многие из ошибок, которые можно было бы быстро найти статическим анализом, искались медленно и печально. Они обнаруживались во время тестирования или после жалоб пользователей. То есть забыто, что статический анализ это инструмент постоянного, а не разового применения. Ведь программисты регулярно смотрят на Warnings, выдаваемые компилятором, а не раз в год.

Со вторым недочётом в исследованиях всё обстоит сложнее и интереснее. У меня было чёткое ощущение, что нельзя равнозначно оценивать маленькие и большие проекты.  Пусть студент написал за 5 дней хороший проект для курсовой работы, содержащий 1000 строк кода. Я уверен, что за 500 дней он не сможет написать хорошее коммерческое приложение, объемом в 100 000 строк кода. Ему помешает рост сложности. Чем больше становится программа, тем сложнее добавлять в неё новый функционал, тем больше требуется её тестировать и больше возиться с ошибками.

В общем, ощущение было, но сформулировать мне его никак не удавалось. Неожиданно мне на помощь пришёл один из сотрудников. Изучая книгу Стива Макконнелла "Совершенный код" он заметил в ней интересную табличку. А я то, про неё и забыл. Это табличка всё сразу расставляет на свои места!

Конечно же, рассматривая маленькие проекты, некорректно оценивать количество ошибок в больших! В них разная плотность ошибок!

Чем больше проект, тем больше ошибок на 1000 строк кода он содержит. Взгляните на эту замечательную таблицу:


Таблица 1. Размер проекта и типичная плотность ошибок. В книге указаны источники данных: "Program Quality and Programmer Productivity" (Jones, 1977), "Estimating Software Costs" (Jones, 1998).

Чтобы было легче воспринимать данные, построим графики.


График 1. Типичная плотность ошибок в проекте. Синий - максимальное количество. Красный - среднее количество. Зелёный - наименьшее количество.



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

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

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

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



P.S. 

Приглашаю присоединиться к моему твиттеру @Code_Analysis или к сообществу на сайте Reddit. В них я регулярно публикую ссылки на интересные статьи по тематикам: Си/Си++, статический анализ кода, оптимизация, прочие интересное о программировании. 



Это сообщение отредактировал(а) Thunderbolt - 30.8.2012, 21:15

Любая статистика хороша при оговорке, которая звучит так: "При прочих равных условиях". Но равны ли остальные условия написания больших и маленьких проектов? Нет. Во-первых маленький проектик пишет студент. Во-первых он вообще не способен справиться с большим проектом, так как его знания малы. А это значит, что персонально у него пока выше плотность ошибок. Во-вторых он ещё очень хорошо помнит лекции, к которых преподаватель с большим опытом рассказывал, как писать надо, а может и как не надо. А это убережёт от многих ошибок, которые даже тот же преподаватель способен допустить в большом проекте. Это несколько снижает количество ошибко в это время (в первые несколько дней после лекций). Со студентом разорались, теперь факторы рамера. В-третьих он ещё не умеет делать грамотную декомпозицию, что увеличивает количество учитываемых взимосвязий в проекте, а значит и его сложность, а значит и количество ошибок. Во-первых меленький проект в принципе содержит меньше взаимозависимостей, которые надо учесть, чтоб недопустить ошибок. Во-вторых оперативная память существует по обе строны экрана и в одном месте она дефицитней, чем в другом кеш. А маленький проект в человеческую оперативу помещается лучше, что позволяет анализировать большую долю взаимозависимостей и снижает сложность. С учётом всех факторов больше всего ошибок в самых маленьких проектах мнее 40-ка строк: там их по нескольку штук в каждой строке. Экстраполяция даст где то тысяч 6 тысячу строк и то по самым скромным оценкам. И никакой анализатор здесь не поможет, так как эти деятели просто не понимают, что им пишет не только анализатор, но даже компилятор, нужна помощь человека. При том, что ошибки тупейшие. Но студент пока просто не понимает, что они значат.

Добавлено @ 20:24
. Нда. Слово "понятно" что то рассматривает и при этом чем то становистя.

Это сообщение отредактировал(а) TarasProger - 13.8.2015, 20:26