Попробовать статический анализатор кода легко. А вот, чтобы внедрить его, особенно в разработку большого старого проекта, потребуется умение. При неправильном подходе анализатор может добавить работы, замедлить разработку и демотивировать команду. Давайте кратко поговорим, как правильно подойти к интеграции статического анализа в процесс разработки и начать его использовать как часть CI/CD.
Читать полностью »
Как справедливо заметил легендарный писатель Жюль Верн: «Хорошо использованный минимум вполне достаточен». В нашу эпоху понятие хорошо использованного минимума применимо и к коду. Печально, но факт: в современном мире кода слишком много. Если быть точнее, то слишком много ненужного кода, среди которого код полезный просто задыхается.
Учитывая вышесказанное, ненужный код – это зло по умолчанию. Он портится со временем. Он требует постоянной поддержки. Он содержит баги, которые нужно выискивать. Когда появляются новые функции, старый код приходится к ним приспосабливать. Чем больше у вас кода, тем больше ошибок может в нем затаиться. Чем больше времени занимают проверки или компиляции, тем дольше новый сотрудник будет разбираться в вашей системе.
И вдобавок ко всей этой чехарде, код пишется программистами. Чем его больше, тем больше требуется программистов. С увеличением числа программистов растут и затраты на коммуникацию между ними, что еще дополнительно вносит лепту в копилку расходов на разработку и сопровождение кода.
Читать полностью »
Общаясь с людьми на конференциях и в комментариях к статьям, мы сталкиваемся со следующим возражением: статический анализ сокращает время на нахождение ошибок, но отнимает время у программистов, что нивелирует пользу от его использования и даже наоборот тормозит процесс разработки. Давайте разберём это возражение и покажем, что оно беспочвенно.
Читать полностью »
Из документации Google's Engineering Practices
В этом руководстве приведены рекомендации по оптимальному проведению код-ревью, основанные на многолетнем опыте. Все вместе они составляют один документ, разбитый на множество разделов. Необязательно читать их все, но часто для себя и команды лучше изучить руководство полностью.
См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.
Читать полностью »
Из этой статьи вы узнаете, как запустить проверку embedded-проекта и как работать с отчетом анализатора. Анализатор PVS-Studio поддерживает ряд компиляторов для встраиваемых систем. В текущей версии возможна проверка проектов при сборке одним из следующих компиляторов под Window, Linux и macOS:
Это небольшая история о том, как с помощью PVS-Studio удалось найти ошибку в исходном коде библиотеки, используемой в PVS-Studio. Причём не теоретическую, а фактическую — ошибка проявлялась на практике при использовании библиотеки в анализаторе.
Читать полностью »
PVS-Studio поддерживает анализ проектов на языках C, C++, C# и Java. Использовать анализатор можно под системами Windows, Linux и macOS. В этой заметке речь пойдет об анализе кода, написанного на C и C++ в среде Linux.
Установить PVS-Studio под Linux можно разными способами, в зависимости от типа дистрибутива. Наиболее удобный и предпочтительный способ – использование репозитория: так это позволяет автоматически обновлять анализатор при выходе новых версий. Второй вариант – использовать установочный пакет, который можно скачать здесь.
Читать полностью »
Постепенно и незаметно складывается ситуация, когда сложность серьёзных C++ проектов становится запредельной. К сожалению, теперь C++ программист не может полагаться только на свои силы.
Читать полностью »
Инженеры очень любят измерения и числа. Поэтому нет ничего удивительного в том, что они пытаются измерять в численном виде такую нетривиальную штуку, как качество кода.
Метрик для оценки текстов программ придумали немало — от банального количества строк кода в проекте до не столь очевидного "индекса поддерживаемости" (Maintainability Index). Подробно про все существующие способы обмазывания кода всякими метриками можно почитать в этой статье.
В мире Python, конечно же, есть своя штука для оценки качества кода. Она называется radon. Она написана на этом же самом Python и работает исключительно с питонячими файлами.
Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.
Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.
Несмотря на то, что основная целевая аудитория статьи это разработчики, для её понимания не требуется специальных знаний. Мне бы хотелось чтобы эта статья принесла пользу всем, кто так или иначе связан с процессом разработки, а особенно менеджерам, которые формируют вектор развития продуктов.
Читать полностью »
