Использование инструментов для повышения и контроля качества кода может стать важным фактором успеха при реализации сложных программных проектов. Например, к таким инструментам относятся статические анализаторы. На данный момент они доступны в большом количестве: от бесплатных с открытым исходным кодом до кросс-функциональных коммерческих решений. С одной стороны – есть из чего выбирать, с другой – поиск подходящего вашей команде инструмента может стать настоящей исследовательской работой.
Прежде чем рассказывать про критерии отбора, давайте коротко ознакомимся с методологией. Статический анализ — автоматизированный метод поиска ошибок в исходном коде с помощью специализированных программ. Такой тип анализа направлен на выявление слабых и проблемных мест в проекте, которые при определённом стечении обстоятельств могут привести к более серьёзным последствиям – уязвимостям.
Чтобы ваши пользователи не превратились в тестировщиков, а баги не попали в релиз, стоит сделать акцент на том, что статический анализатор должен использоваться на регулярной основе. При одноразовых запусках время от времени может накопиться очень много сообщений и разбираться с ними будет просто лень. Более того, часть ошибок будет найдена и исправлена более дорогостоящими методами на последующих этапах сопровождения проекта.
Корректный вариант использования статического анализатора кода – это регулярный запуск инструмента и исправление обнаруженных проблем сразу же. Например, запускать анализ можно ежедневно вместе с ночными сборками. Таким образом можно сразу найти и устранить множество ошибок на раннем этапе разработки и не ждать, пока они попадут тестировщикам или того хуже – пользователям.
Если вы хотите во всех подробностях узнать про статический анализ, как он работает, увидеть его плюсы и минусы, а также развеять популярные мифы о нём, то прочтите эту статью на нашем сайте.
Перед тем как сразу забивать в поисковике про интеграцию того или иного инструмента в свой процесс разработки и бросаться их тестировать, стоит оценить, насколько эффективно и легко она пройдёт. Поэтому проведите оценку своих рабочих процессов, выявите основные потребности как бизнеса, так и команды – и тогда поиск наилучшего для вас решения пройдет максимально просто, без больших затрат времени и других ресурсов.
Итак, чтобы поиск и выбор не превратились в очередную инициативу, которой никто не будет заниматься, разберём основные важные функции анализатора, на которые стоит обратить внимание.
Как ни странно, но хотелось бы задержаться на этом этапе, так как нужно понимать размер кодовой базы проекта на том или ином языке, который используется в компании.
Например, у вас мультиязычный проект, состоящий из C++, PHP, Java и других языков. При этом кодовая база по C++ довольно мала. Поэтому останавливать свой выбор на анализаторе, который заточен конкретно под С++ и имеет в своем арсенале большой список правил для анализа, будет не лучшим решением. Он, конечно, найдёт ошибки и выдаст предупреждения, но его использование будет не так эффективно, как могло бы быть. Поддерживать оптимальное качество до 10 000 строк кода можно и другими методами, такими как code review.
Поэтому если в вашей компании используются разные языки, то определитесь, хотите ли вы проверять их все или только конкретные. Порой, чем больше языков поддерживает анализатор, тем более поверхностно он проверяет каждый из них и наоборот.
Как правило, у вашей команды уже настроены средства разработки, которые являются неотъемлемой частью существующего SDLC (Software Development Life Cycle) рабочего процесса. Чтобы не усложнять работу себе и другим отделам, связка с приложением статического анализа должна быть легка и безболезненна.
Например, если вы используете популярные IDE, то для них уже есть готовые плагины и такое встраивание статического анализа помогает экономить много времени и сил на последующей настройке в будущем. Вам не придётся переключаться между несколькими приложениями и синхронизировать данные между ними.
Иначе вам потребуется самостоятельно выполнить несколько трудоёмких задач:
Если у вас "экзотическая" система, то решение тут может быть только одно – написать в поддержку. Там наверняка помогут разобраться с ситуацией.
Мы перешли к тому, за что многие разработчики не любят инструменты статического анализа, особенно если приходится внедрять его в большой проект. Код работает, но в отчёте отображаются десятки ложных срабатываний. Подобный шум не только делает анализ кода неэффективным и сложным, но и подрывает все усилия, вызывая сомнения в эффективности инструмента и демотивируя команду разработчиков.
На самом деле, это нестрашно, так как анализаторы предоставляют различные механизмы настройки и подавления лишних предупреждений. Можно пометить ложные срабатывания и настроить продукт под себя так, чтобы последующий анализ кода проходил без лишнего шума. Увы, но это неизбежный процесс, с которым нужно плотно взаимодействовать на начальных этапах работы, чтобы упростить все последующие запуски.
Нередки случаи, когда из-за отсутствия подавления ложных срабатываний от инструмента отказывались, даже понимая, что он бы приносил пользу в перспективе. Именно поэтому в анализаторе должна быть функция массового подавления таких сообщений об ошибках и возможность вернутся к ним, когда появится время или необходимость. В противном случае может не хватить ресурсов, чтобы разобрать сразу все срабатывания и найти нужные баги.
К инструменту должна прилагаться понятная документация. В ней должны быть описаны все нюансы по настройке и использованию, которые помогут разработчикам интегрировать инструмент и упростить его использование. Особенно удобно, когда помимо общих советов по настройке можно увидеть примеры по устранению ошибок в коде. Благодаря этому даже самое непонятное по описанию правило может быть легко разобрано на схожих случаях в коде.
Конечно, не все вопросы можно решить инструкциями и документацией. Поэтому стоит убедиться, что сервис предлагает качественную и квалифицированную поддержку, которая поможет решить возникшие проблемы и достичь нужных бизнес-целей.
Хорошую поддержку можно оценить по нескольким факторам:
Если вы сталкивались с ситуацией, когда ваш вопрос перекидывают от менеджера к менеджеру и в итоге вам в лучшем случае отвечают месяц спустя, то очевидно, это плохая поддержка. Идеальный вариант – когда помимо решения проблем и адекватного общения компания по запросу может реализовать некоторые "хотелки", чтобы вы могли настроить анализатор конкретно под свои нужды при разработке.
Сканирование кода на основании отраслевых стандартов безопасности и защищённости является важной функцией для снижения риска при разработке вашего программного обеспечения. Помимо очевидно полезного свойства по предотвращению уязвимостей системы безопасности ваших проектов, их наличие может являться критерием для оценки и выбора инструментов статического анализа.
Если вы знаете, что вашему проекту требуется определенный стандарт, необходимо детально изучить возможности каждого инструмента. Насколько хорошо он покрывает различные типы ошибок, стандарты кодирования и глубину анализа. Например, сколько правил MISRA он поддерживает, покрывает ли он OWASP TOP 10, входят ли его правила в CWE TOP 25 и т.д.
Каким набором правил должен обладать анализатор, зависит от ваших целей. Для одного проекта важно только качество и чистота написания кода: выход за границу массива, борьба с опечатками, неопределённым поведением, переполнением буфера и т.д. Для автомобильной промышленности будет важно наличие правил MISRA, AUTOSAR и других стандартов надежной разработки. Для финансового ПО в первую очередь важно учитывать известные проблемы безопасности приложений (OWASP, SEI CERT, CWE и т.д.). Есть анализаторы с комбинированными правилами, которые поддерживают сразу несколько стандартов. И тут нет варианта лучше или хуже, есть только цель использования, а рынок может предложить множество решений исходя из ваших потребностей.
Статические анализаторы могут проверять проект от нескольких минут до десятков часов, так как во время анализа исходного кода они строят семантическую модель и изучают её с разных сторон.
Есть разные факторы, которые могут повлиять на скорость анализа кода:
Как правило, проверку большого проекта запускают по ночам. Поэтому анализ не должен превышать 10 часов, чтобы к возвращению разработчиков и их руководителей результаты уже ожидали их. Этот процесс можно попробовать осуществить быстрее:
Если же вышеперечисленные или собственные манипуляции не сработали, можно связаться с поддержкой. А она в свою очередь либо поможет вам в настройке, либо благодаря вашему фидбеку исправит этот "странный" баг на своей стороне в будущем релизе.
Пытаясь определить, какой статический анализатор лучше, бывает, используют следующий подход. На одном коде запускается несколько анализаторов, и затем сравнивают результаты. Выбирают тот, который сообщает о наибольшем количестве нарушений. В итоге такая быстрая и поверхностная оценка может выдать длинные страницы предупреждений с большим числом ложных срабатываний. Как правило, с такими отчётами приходится сложно и долго работать, что отбивает всё желание на внедрение анализатора.
Поэтому кроме количества ошибок в отчётах должна содержаться информация и об их качестве. Насколько данная ошибка фатальна для программы, и может ли она привести к реальным сбоям в будущем. Если в анализаторе имеется разделение ошибок по уровням достоверности, то это упрощает работу, так как можно сфокусироваться только на ошибках высокого уровня и отключить те, среди которых велик процент ложных срабатываний.
Результаты работы статического анализатора полезны не только разработчикам, но и менеджерам, где каждый устанавливает свои метрики эффективности. Менеджеры проектов и продуктов обеспокоены общим уровнем риска в динамике и заинтересованы, чтобы количество уязвимостей снижалось изо дня в день, ну или как минимум не увеличивалось. А также им хочется видеть в отчётах ответственного за тот или иной фрагмент кода с ошибкой.
Когда дело доходит до безопасности собственных проектов, вопрос о репутации используемого инструмента возникает сам по себе. Перед тем как определиться с анализатором, попробуйте ответить на следующие вопросы.
Если ответы на все эти вопросы легко можно найти, и они имеют позитивную направленность, то скорее всего вы не ошибётесь в выборе рассматриваемого инструмента.
Профессиональные статические анализаторы кода стоят недешево и могут иметь различные модели оплаты. Редко какие из них продаются на индивидуального пользователя. Учитывая стоимость, такие инструменты имеют B2B-модель продаж. Цена формируется исходя из размера команды разработчиков, оказываемых дополнительных услуг в поддержке или аудите и по другим критериям. Оплата может быть как по подписке, так и разово. В любом случае вы вряд ли найдёте анализатор, где чётко и явно на официальном сайте будет прописана точная цена. Обычно, такие инструменты должны предоставлять лицензию, ограниченную по времени или функционалу.
Некоторые из профессиональных коммерческих решений и вовсе идут с бесплатной лицензией для разных пользователей: Open Source проектов, учебных заведений, Microsoft MVP и т.д.
Если вы сомневаетесь, окупится ли внедрение такого инструмента в процесс разработки и сколько часов работы программиста поможет сэкономить, то предлагаем рассуждать в терминах ROI (возврата инвестиций). Примером такого рассуждения является статья в нашем блоге, в которой рассматривается целесообразность внедрения инструмента PVS-Studio.
Кроме коммерческих профессиональных решений, есть и абсолютно бесплатные Open Source инструменты. В этой статье мы не будем сравнивать их между собой и рассматривать их плюсы и минусы, так как многие из вышеперечисленных критериев: поддержка, интеграция и документация – слабо проработаны в Open Source решениях. Если начать разбираться, то это целая тема для отдельной статьи. Чтобы не пропустить её в будущем, подписывайтесь на наш блог на Habr и заходите в соц. сети :)
Конечно, для эффективной работы все эти советы по выбору анализатора работают не поодиночке, а вместе. Инструмент должен быть прост и интуитивен. В противном случае им не будут пользоваться в должной мере. Выбирайте тот продукт, который вы сможете интегрировать в свою организацию, не нарушая SDLC процесс и не создавая лишних расходов.
Важными особенностями являются набор правил и покрытие стандартов безопасности CWE, MISRA, OWASP, AUTOSAR, SEI CERT и др., которые обеспечивает инструмент. Только таким образом качество кода будет повышаться с каждым разом и к релизу проекта код будет "отшлифован" и чист.
Не применяйте анализатор как способ наказать разработчика. Инструменты статического анализа призваны упрощать поиск багов, но никак не искать виновных. Если хотите, чтобы данная методология использовалась по максимуму, тогда следует представить анализатор вашей команде так, чтобы стимулировать его регулярное использование.
Статические анализаторы кода не являются заменой человека. Они упрощают работу и предоставляют отчёты об ошибках. Но для того, чтобы все эти уязвимости верифицировать и исправить, нужен разработчик.
Оценивайте поддержку, которую предоставляет компания. У вашей команды могут возникать вопросы по работе с инструментом, и это нормально!
Определитесь с бюджетом и рассчитайте примерный возврат инвестиций. Если есть сомнения по этому поводу, то всегда можно запросить триальную версию.