Улучшение качества открытого программного обеспечения с помощью инструментов анализа кода (Максим Звягинцев, OSSDEVCONF-2019) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
[[File:{{#setmainimage:Улучшение качества открытого программного обеспечения с помощью инструментов анализа кода (Максим Звягинцев, OSSDEVCONF-2019)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->
{{vklink|1449}}
{{fblink|2435488363370837}}
<references/>
[[Категория:OSSDEVCONF-2019]]
[[Категория:Статический анализ кода]]
[[Категория:Динамический анализ]]
{{stats|disqus_comments=0|refresh_time=2019-12-30T14:28:44.058390|vimeo_plays=127|youtube_comments=1|youtube_plays=49}} | |||
Версия 11:28, 30 декабря 2019
- Докладчик
- Максим Звягинцев
Одним из способов внести свой вклад в развитие открытого программного обеспечения, является поиск и исправление различных программных ошибок и потенциальных уязвимостей. Достаточно просто, это можно осуществить, используя статические анализаторы кода. Это можно делать даже в том случае, если вы ещё мало знакомы с устройством работы проекта, но хотите внести вклад в его улучшение. Поговорим о методологии анализа исходного кода, бесплатных инструментах и автоматизации процессов проверки.
Содержание
Видео
Презентация
Thesis
Представим достаточно большой проект на GitHub. Есть множество желающих поучаствовать в разработке, однако тестировщиков всегда недостаточно. Это серьезная проблема, так как без чётко выстроенной системы тестирования серьезные баги могут попасть в релиз. Для того, чтобы исправить эту ситуацию стоит рассмотреть различные способы автоматизации, такие как unit тесты, динамический и статический анализ и системы непрерывной интеграции.
Предлагаю рассмотреть статические и динамические анализаторы. Они отлично дополняют друг друга, так как позволяют одновременно выявить ошибки в исходном коде и проанализировать работоспособность во время выполнения.
На первый взгляд может показаться, что эти типы анализаторов достаточно похожи, однако это не так. Статический анализ работает с исходным кодом. Он занимается поиском различных аномалий, опечаток, потенциальных уязвимостей и многих других проблем, которые могут не проявлять себя во время работы программного обеспечения, но быть бомбой замедленного действия. Динамический анализ напротив смотрит не на исходный код, а на выполнение программы. Такой подход позволяет обнаружить такие серьезные проблемы, как например утечки памяти, выходы за границы массивов или гонки потоков. Разумеется, это не единственное, что умеют динамические анализаторы. Помимо поиска множества других проблем, они могут собрать различные метрики, например время выполнения частей программы и отдельных функций или покрытие кода тестами.
Вернемся к статическому анализу. В первый раз мы, конечно, проверим весь проект. И скорее всего получим внушительный список ошибок, так как анализатор ещё не настроен. Для такой ситуации существует подавление ложных срабатываний. Например, директива #pragma позволяет убрать ложные предупреждения компилятора. Да, компиляторы зачастую немного занимаются статическим анализом, однако они могут обнаружить лишь самые типовые ошибки из-за сложности реализации полноценного статического анализа.
Итак, мы разобрались со всеми предупреждениями, исправив ошибки и подавив ложные срабатывания. Однако, новые изменения кода могут принести в проект новые ошибки и новые потенциальные уязвимости, поэтому разумно запускать статический анализ достаточно часто, чтобы не накапливать технический долг.
Первое, что приходит в голову — делать проверки после каждого изменения исходного кода. Конечно, это сработает и будет выдавать все необходимые предупреждения, однако есть одна серьезная проблема — время анализа. Проверка большого проекта может быть весьма долгой, поэтому нужно каким-то образом ускорить её.
Например, в анализаторе PVS-Studio есть режим инкрементального анализа. Он позволяет проверить те файлы, которые были изменены с момента последней проверки. Это безусловно хороший вариант для локального анализа, однако это не подходит для ситуации, когда множество разработчиков делают вклад в общую кодовую базу.
Решением этой проблемы будет проверка кода при pull request. Например, у нас есть две ветки, которые нужно слить в одну. Для удобства назовем «главную» ветку master, а «ответвление» — hotfix. Проблема в том, что hotfix может принести в общую кодовую базу ошибки, так как никто не застрахован от опечаток. Поэтому было бы разумно проверять перед слиянием разницу между ветками. Это можно реализовать, например, при помощи связки сервиса непрерывной интеграции и анализаторов кода.
!.jpg)
Примечания и ссылки
Plays:176 Comments:1