Долгое время меня беспокоили статьи в интернете, в которых делалась попытка на основе проверки небольших проектов, судить о пользе использования статических анализаторов кода.
Во многих из прочитанных мною статей делается такое предположение. Если в проекте размером 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. В них я регулярно публикую ссылки на интересные статьи по тематикам: Си/Си++, статический анализ кода, оптимизация, прочие интересное о программировании. Статьи и наши, и чужие. А то меня всюду выгнали, кроме «Я пиарюсь».
Во многих из прочитанных мною статей делается такое предположение. Если в проекте размером 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. В них я регулярно публикую ссылки на интересные статьи по тематикам: Си/Си++, статический анализ кода, оптимизация, прочие интересное о программировании. Статьи и наши, и чужие. А то меня всюду выгнали, кроме «Я пиарюсь».
