Comments 26
А что, отец, люди которые даже бесплатные статические анализаторы не используют в вашем городе есть? Тот же clang-check от совсем глупых ошибок вроде неплохо спасает.
У нас 100 пожарных, и не одного пожара. Что мы делаем не так?
Непонятная какая-то аналогия.
Вы всё делаете так. Если эти пожарные регулярно объезжают город и в пожароопасных местах наводят порядок — то и хорошо. Пожарные для того и нужны, чтобы пожаров меньше было, с не чтобы с ними «героически бороться», когда уже всё полыхает…
Если у вас нет пожаров, зачем вам пожарные?
Вспоминая Жеглова: «А ты скажи ему, что правопорядок в стране определяется не наличием воров, а умением властей их обезвреживать. Вот так»
Хочу заметить, что такой анализатор не спасет от логических ошибок в бизнес-логике приложения. Тут помогут только юнит тесты. Но эти же самые тесты выявят любые ошибки, в том числе и те, что обнаруживает статический анализатор. Кроме того, анализатор не поможет, если часть логики находится, например, в хранимых процедурах на уровне БД.
Хочу заметить, что такой анализатор не спасет от логических ошибок в бизнес-логике приложения. Тут помогут только юнит тесты.Про бизнес логику Вы правы.
Но эти же самые тесты выявят любые ошибки, в том числе и те, что обнаруживает статический анализатор.А вот здесь дело обстоит иначе. Теоретически утверждение верно, но к практике оно не применимо.
Статические анализаторы и юнит-тесты не конкурируют, а дополняют другую. У юнит-тестов есть слабые места, которые отлично подстрахует статический анализ:
- Сами юнит-тесты часто содержат ошибку. Для юнит-тестов не пишут другие юнит-тесты. :) Зато анализатор проверяет тесты. И по моему опыту, там очень часто находятся ошибки. Чаще всего выясняется, что тест ничего не тестирует.
- Не все ошибки можно найти юнит-тестами. Вернее, это слишком сложно. Например, юнит тестом очень сложно найти ошибку обнуления стековой памяти при выходе из функции. Я имею в виду вот это. Или, например, юнит-тестом можно не найти чтение из неинициализированной переменной (тестам повезёт и там будет хорошее значение).
- Слишком дорого покрыть тестами весь код. Статические анализаторы проверяют весь код. В результате, находится огромное количество ошибок в коде, который редко выполняется.
- Непонятно что делать с большим проектом, в котором мало юнит-тестов, а хочется в обозримом времени улучшить его качество. Писать тесты — слишком долго и дорого. Статический анализ в этот момент становится хорошей альтернативой.
Прочитал и чуть завыть не захотелось!
Живу я в аскетичном мире golang и об анализаторах кода в нем речи нет и, видимо, не будет. Так вот даже обилие тестов не заменит анализатор — это подходы с разных сторон для обеспечения качества кода и сокращения расходов.
Живу я в аскетичном мире golang и об анализаторах кода в нем речи нет и, видимо, не будет. Так вот даже обилие тестов не заменит анализатор — это подходы с разных сторон для обеспечения качества кода и сокращения расходов.
Для юнит-тестов не пишут другие юнит-тесты.
Не совсем, есть же мутационное тестирование, которое как-раз выявляет качество тестов, wiki:
Mutation testing (or Mutation analysis or Program mutation) is used to design new software tests and evaluate the quality of existing software tests
UFO just landed and posted this here
UFO just landed and posted this here
Юнит тест будет содержать ту же логическую ошибку.
Да только проблема не в том, что анализатор не найдет ошибок, а в том что выдаст миллион ложных срабатываний. Единственный вариант использовать его с самых первых строк нового проекта. А они есть вообще на C++?
Да только проблема не в том, что анализатор не найдет ошибок, а в том что выдаст миллион ложных срабатываний.Вы преувеличиваете размер беды. Да, поначалу анализаторы кода могут выдавать огромное количество предупреждений. Однако, все серьёзные анализаторы кода предоставляют различные варианты настройки. И уже после минимальной настройки, количество ложных срабатываний может быть уменьшено в разы. Больше всего ложных срабатываний относится к неудачным макросам. Разметив эти макросы, можно получить сразу намного более приятную картину в отчёте.
Например, вот статья где идёт речь о количестве ложных срабатываний, выдаваемых PVS-Studio: Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний.
Единственный вариант использовать его с самых первых строк нового проекта.Да, это вполне вариант. Но почти нереальный на практике. :)
Поэтому в PVS-Studio есть вариант разметить все предупреждения как пока неинтересные и работать только с предупреждениями, относящимися к новому или изменённому коду. Это позволяет легко внедрить использование статического анализа в большой проект и начать сразу получать от него пользу. Подробнее: Массовое подавление сообщений анализатора (отключение выдачи предупреждений на существующий код).
Если у вас в проекте «миллион ложных срабатываний», то видимо это не очень качественный проект.
Я вам больше скажу — это ужасный проект. Это проект, который разрабатывался сотней человек последние 15 лет. Он содержит 4G исходников. Он собирается за 2.5 часа. Там нельзя включить максимальный кровень предупреждений поскольку слетает Visual Studio. Там много еще всякого.
Но… только такие проекты и имеют ценность.
Так что миллион ложных срабатываний — это не перувеличение. Это данность. И размечать неинтересные предупреждения статического анализатора — тоже не вариант. Помогает только отключение всего и включение только интересных, что убивает саму идею анализатора.
За всю историю моих мытарств с анализом кодовой базы я нашел только 1 (один) инструмент, который успешло распарсил все исходники (и разумеется я забыл его название :) ). Все кроссреференсеры, инструментирующие профайлеры, тулы типа парсера кода от Rational Rose — все падают.
Но… только такие проекты и имеют ценность.
Так что миллион ложных срабатываний — это не перувеличение. Это данность. И размечать неинтересные предупреждения статического анализатора — тоже не вариант. Помогает только отключение всего и включение только интересных, что убивает саму идею анализатора.
За всю историю моих мытарств с анализом кодовой базы я нашел только 1 (один) инструмент, который успешло распарсил все исходники (и разумеется я забыл его название :) ). Все кроссреференсеры, инструментирующие профайлеры, тулы типа парсера кода от Rational Rose — все падают.
Ну вот тут вы уже начинаете немного подвирать. Между программистами и «тестировщиком» находятся ещё автоматические тесты, которые и ловят большинство ошибок.
А вот если их нет, то польза от PVStudio будет никакая, потому что результирующий продукт всё равно будет страшно сырой, а тестировщики всё не оттестируют.
А вот если их нет, то польза от PVStudio будет никакая, потому что результирующий продукт всё равно будет страшно сырой, а тестировщики всё не оттестируют.
в тегах к статье вы указали «Java». Вопрос: когда можно будет проверить свой java проект вашим анализатором?
хороший пример, много проверок не бывает, лучше запускать тесты и анализаторы каждый день над своим кодом, чем гдето там потом…
у нас похожая ситуация была… программисты пишут-пишут, тестер проверяет, исправляют, проверяют, исправляют… а гдето бывает вылазят новые в ходе исправлений. ужас был. было время и без тестера — еще тот ад.
ситуация качественно изменилась после внедрения тестов: фичу сделал, тесты запустил — все ок, ушло тестеру, который в очень редких случаях чтото находит :)
жаль на Go не видел анализаторов подобных Вашему.
у нас похожая ситуация была… программисты пишут-пишут, тестер проверяет, исправляют, проверяют, исправляют… а гдето бывает вылазят новые в ходе исправлений. ужас был. было время и без тестера — еще тот ад.
ситуация качественно изменилась после внедрения тестов: фичу сделал, тесты запустил — все ок, ушло тестеру, который в очень редких случаях чтото находит :)
жаль на Go не видел анализаторов подобных Вашему.
Sign up to leave a comment.
Философия статического анализа кода: у нас 100 программистов, анализатор нашел мало ошибок, он бесполезен?