для чего могут использоваться динамические среды разработки
Среды разработки
В любом производственном процессе, к которому относится и разработка программ, есть различные этапы. Грубо говоря, их можно представить так:
Производство
С этим пунктом всё более менее понятно: мы поставили себе любимый редактор, открыли в нем исходный код проекта и работаем, не покладая рук. Возможно, даже, пишем тесты и, самое главное, иногда их запускаем. Если это веб-сайт, то периодически запускаем сервер и смотрим в браузере, что получилось.
Кроме этого, код в среде разработки обычно пишется не в основной ветке вашей системы контроля версий, а в ветке-фиче. Это важно, так как не блокирует возможность делать быстрые правки, если на сервере что-то поломалось, и нужно поправить только небольшой кусок, а новые наработки вы ещё не готовы выливать.
Читайте также: DevOps — что это такое и почему эти практики меняют мир разработки уже сейчас
Сборка
После того, как вы реализовали свою задачу (фичу) и она была протестирована, код задачи вливается в основную ветку — и происходит так называемая интеграция. Это название связано с тем, что, возможно, кроме этой фичи, параллельно велась разработка другой фичи, в другой ветке, и с высокой вероятностью ту задачу выполняли даже не вы. И вот теперь в основной ветке они встретились, а работают они вместе или нет — ещё предстоит выяснить.
(Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде).
Контроль и испытания
Обычно тестирование включает в себя несколько этапов. Первый, на котором происходит проверка конкретно вашей отдельной фичи, и второй, на котором проверяется всё то, что пойдет в следующий релиз.
Ведь даже собрав всё в одну ветку (все фичи) и проверив их локально, нельзя быть до конца уверенным, что в бою, на реальных данных, всё заработает хорошо. Кроме этого, скорее всего, у вас есть менеджер или даже тестировщики, которые тоже хотят посмотреть/проверить, всё ли хорошо. И тут на сцену врывается ещё одна производственная среда, которая называется средой интеграции (предпродакшен), или стейджинг (staging), как её все называют.
Тут появляется ещё одно новое слово: «релиз». Релиз по-другому называют «выпуск». С одной стороны, это процесс выкатки в бой новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.
Continuous Integration Server
Одна из разновидностей сборочной среды называется «сервер непрерывной интеграции». Это такая отдельная машина (а может быть целый парк машин), на которую выливается код для проверки в автоматическом режиме. Обычно это происходит по какому-нибудь событию, например, на Github это пулреквест. В настроенных проектах каждый пулреквест отправляется в сервис, подобный https://travis-ci.org. Этот сервис прогоняет тестовый набор на нужной ветке (с фичей) и после этого прикрепляет отчет к пулреквесту, в котором пишет о результатах проверки.
Такая система позволяет очень сильно ускорить процесс интеграции. Сильно снижается нагрузка на разработчиков и автоматизируется рутина. Разработчику достаточно писать код и отправлять его в репозиторий, а система сама будет проводить необходимые проверки и выполнять слияние. Непрерывная интеграция является частью практик под названием «экстремальное программирование (XP)».
Доставка
Мы упустили один важный момент. Каким образом новый код попадает в предпродакшен и в продакшен-среду после того, как вы закончили разработку? Делает он это благодаря процессу, который в простонародье называют «деплой».
Как показывает практика, многие до сих пор делают деплой руками. Заходят на сервер (а если их много?) клонируют код, руками меняют базу и так далее.
Можно бесконечно обсуждать то, насколько это плохо. Начиная с того, что по сути отсутствует налаженный, повторяемый процесс, а значит всегда есть вероятность того, что ворвется человеческий фактор и случайно будет что-то забыто/потеряно/удалено. Заканчивая тем, что знания хранятся в одной голове, и сам процесс релиза становится вуду-процедурой, которую может делать только Вася, а иногда он болеет, ходит в отпуск и может уволиться. Часто в таких компаниях релиз — крайне болезненная процедура, которая занимает не один час, а может даже пару дней.
При хорошо отлаженном процессе, релиз занимает десяток минут, и может делаться любым разработчиком в любой момент (почти). Хекслет иногда деплоится по 5-10 раз в день.
Основные задачи, которые стоят перед вами во время деплоя:
Ещё раз про семь основных методологий разработки
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.
Когда использовать каскадную методологию?
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
Когда использовать Agile?
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
Что такое IDE? Обзор 10 лучших IDE
Что такое IDE (интегрированная среда разработки) и чем она отличается от текстового редактора?
IDE (integrated development environment) включает в себя эти компоненты, как и ряд других. Некоторые из них поставляются с дополнительными инструментами для автоматизации, тестирования и визуализации процесса разработки. Термин «интегрированная среда разработки» означает, что предоставляется все необходимое для превращения кода в функционирующие приложения.
Microsoft Visual Studio
Интегрированная среда программирования NetBeans
Бесплатная IDE для C (и многих других языков программирования) с открытым исходным кодом. Подходит для редактирования существующих проектов или создания новых. NetBeans предлагает простой drag-and-drop интерфейс, который поставляется с большим количеством удобных шаблонов проектов. Среда в основном используется для разработки Java приложений, но можно устанавливать пакеты, поддерживающие другие языки.
Недостатки: эта бесплатная среда разработки потребляет много памяти, поэтому может работать медленно на некоторых ПК.
PyCharm — лучшая среда разработки для Python
Поддерживаемые языки: AngularJS, Coffee Script, CSS, Cython, HTML, JavaScript, Node.js, Python, TypeScript.
Недостатки: пользователи жалуются, что эта среда разработки Python содержит некоторые ошибки, такие как периодически не работающая функция автоматического заполнения, что может доставить определенные неудобства.
IntelliJ IDEA
Поддерживаемые языки программирования: AngularJS, CoffeeScript, HTML, JavaScript, LESS, Node JS, PHP, Python, Ruby, Sass, TypeScript и другие.
Недостатки: эта среда разработки JavaScript требует времени и усилий на изучение, поэтому может оказаться не лучшим вариантом для начинающих. В ней есть много сочетаний горячих клавиш, которые нужно просто запомнить. Некоторые пользователи жалуются на неуклюжий интерфейс.
Eclipse
Поддерживаемые языки: C, C++, Java, Perl, PHP, Python, Ruby и другие.
Code::Blocks
Недостатки: относительно компактная IDE для СИ, поэтому она не подходит для крупных проектов. Это отличный инструмент для новичков, но продвинутые программисты могут быть разочарованы ее ограничениями.
Aptana Studio 3
Самая мощная из IDE с открытым исходным кодом. Aptana Studio 3 значительно улучшена по сравнению с предыдущими версиями. Поддерживает большинство спецификаций браузеров. Поэтому пользователи этой IDE могут с ее помощью быстро разрабатывать, тестировать и развертывать веб-приложения.
Недостатки: есть проблемы со стабильностью, и она работает медленно. Поэтому профессиональные разработчики могут предпочесть более мощную HTML среду разработки.
Komodo
Поддерживаемые языки: CSS, Go, JavaScript, HTML, NodeJS, Perl, PHP, Python, Ruby, Tcl и другие.
Недостатки: бесплатная версия среды разработки программного обеспечения не включает в себя все функции. В то же время премиум версия явно стоит своих денег.
RubyMine
Поддерживаемые языки: CoffeeScript, CSS, HAML, HTML, JavaScript, LESS, Ruby и Rails, Ruby и SASS.
Xcode
Поддерживаемые языки: AppleScript, C, C++, Java, Objective-C.
Выбор подходящей IDE
Какая IDE окажется лучшей именно для вас зависит от используемой операционной системы, языка программирования и тех платформ, которые вы хотите развивать.
Дайте знать, что вы думаете по данной теме статьи в комментариях. Мы очень благодарим вас за ваши комментарии, дизлайки, отклики, подписки, лайки!
Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, отклики, подписки, лайки, дизлайки низкий вам поклон!
Использование статического и динамического анализа для повышения качества продукции и эффективности разработки
Тодд Лендри (Todd Landry)
Klocwork
[email protected]
Введение
При статическом анализе (static analysis) можно обнаружить много разнообразных дефектов и слабых мест исходного кода даже до того, как код будет готов для запуска. С другой стороны, динамический анализ (runtime analysis), или анализ во время выполнения, происходит на работающем программном обеспечении и обнаруживает проблемы по мере их возникновения, обычно используя сложные инструментальные средства. Кто-то может возразить, что одна форма анализа предваряет другую, но разработчики могут комбинировать оба способа для ускорения процессов разработки и тестирования, а также для повышения качества выдаваемого продукта.
В данной статье вначале рассматривается метод статического анализа. С его помощью можно предотвратить проблемы до их проникновения в состав основного программного кода и гарантировать, что новый код соответствует стандарту. Используя разные техники анализа, например, проверку абстрактного синтаксического дерева (abstract syntax tree, AST) и анализ кодовых путей, инструменты статического анализа могут выявить скрытые уязвимости, логические ошибки, дефекты реализации и другие проблемы. Это может происходить как на этапе разработки на каждом рабочем месте, так и во время компоновки системы. Далее в статье исследуется метод динамического анализа, который можно использовать на этапе разработки модулей и системной интеграции и который позволяет выявить проблемы, пропущенные при статическом анализе. При динамическом анализе не только обнаруживаются ошибки, связанные с указателями и другими некорректностями, но и есть возможность также оптимизировать использование циклов ЦПУ, ОЗУ, флеш-памяти и других ресурсов.
В статье обсуждаются также варианты комбинирования статического и динамического анализа, что поможет предотвращать возврат к более ранним этапам разработки по мере «созревания» продукта. Такой подход с использованием сразу двух методик помогает избежать проявления большинства проблем еще на ранних этапах разработки, когда их легче и дешевле всего исправить.
Объединяя лучшее из двух миров
Инструменты статического анализа находят программные ошибки еще на ранней фазе создания проекта, обычно перед тем, как создается исполняемый файл. Такое раннее обнаружение особенно полезно для проектов больших встраиваемых систем, где разработчики не могут использоваться средства динамического анализа до тех пор, пока программное обеспечение не будет завершено настолько, чтобы его было можно запустить на целевой системе.
На этапе статического анализа обнаруживаются и описываются области исходного кода со слабыми местами, включая скрытые уязвимости, логические ошибки, дефекты реализации, некорректности при выполнении параллельных операций, редко возникающие граничные условия и многие другие проблемы. Например, инструменты статического анализа Klocwork Insight выполняют глубокий анализ исходного кода на синтаксическом и семантическом уровнях. Эти инструментальные средства выполняют также сложный межпроцедурный анализ управляющих потоков и потоков данных и используют усовершенствованную технику отсекания ложных путей, оценивают значения, которые будут принимать переменные и моделируют потенциальное поведение программы во время исполнения.
Разработчики могут использовать инструменты статического анализа в любое время на этапе разработки, даже когда написаны лишь фрагменты проекта. Однако чем более завершенным является код, тем лучше. При статическом анализе могут просматриваться все потенциальные пути исполнения кода – при обычном тестировании такое происходит редко, если только в проекте не требуется обеспечения 100%-го покрытия кода. Например, при статическом анализе можно обнаружить программные ошибки, связанные с краевыми условиями или ошибками путей, не тестируемыми во время разработки.
Поскольку во время статического анализа делается попытка предсказать поведение программы, основанное на модели исходного кода, то иногда обнаруживается «ошибка», которой фактически не существует – это так называемое «ложное срабатывание» (false positive). Многие современные средства статического анализа реализуют улучшенную технику, чтобы избежать подобной проблемы и выполнить исключительно точный анализ.
| Статический анализ: аргументы «за» | Статический анализ: аргументы «против» |
| Используется уже на ранних этапах жизненного цикла программного обеспечения, прежде чем код готов для исполнения и до начала тестирования. Могут анализироваться существующие базы кодов, которые уже прошли тестирование. Средства могут быть интегрированы в среду разработки в качестве части компонента, используемого при «ночных сборках» (nightly builds) и как часть инструментального набора рабочего места разработчика. Низкие стоимостные затраты: нет необходимости создавать тестовые программы или фиктивные модули (stubs); разработчики могут запускать свои собственные виды анализа. | Могут обнаруживаться программные ошибки и уязвимости, которые не обязательно приводят к отказу программы или воздействуют на поведение программы во время ее реального исполнения. Ненулевая вероятность «ложного срабатывания». |
Таблица 1 — Аргументы «за» и «против» статического анализа.
Инструменты динамического анализа обнаруживают программные ошибки в коде, запущенном на исполнение. При этом разработчик имеет возможность наблюдать или диагностировать поведение приложения во время его исполнения, в идеальном случае – непосредственно в целевой среде.
Во многих случаях в инструменте динамического анализа производится модификация исходного или бинарного кода приложения, чтобы установить ловушки, или процедуры-перехватчики (hooks), для проведения инструментальных измерений. C помощью этих ловушек можно обнаружить программные ошибки на этапе выполнения, проанализировать использование памяти, покрытие кода и проверить другие условия. Инструменты динамического анализа могут генерировать точную информацию о состоянии стека, что позволяет отладчикам отыскать причину ошибки. Поэтому, когда инструменты динамического анализа находят ошибку, то, скорее всего, это настоящая ошибка, которую программист может быстро идентифицировать и исправить. Следует заметить, что для создания ошибочной ситуации на этапе выполнения должны существовать точно необходимые условия, при которых проявляется программная ошибка. Соответственно, разработчики должны создать некоторый контрольный пример для реализации конкретного сценария.
| Динамический анализ: аргументы «за» | Динамический анализ: аргументы «против» |
| Редко возникают «ложные срабатывания» – высокая продуктивность по нахождению ошибок Для отслеживания причины ошибки может быть произведена полная трассировка стека и среды исполнения. Захватываются ошибки в контексте работающей системы, как в реальных условиях, так и в режиме имитационного моделирования. | Происходит вмешательство в поведение системы в реальном времени; степень вмешательства зависит количества используемых инструментальных вставок. Это не всегда приводит к возникновению проблем, но об этом нужно помнить при работе с критическим ко времени кодом. Полнота анализа ошибок зависит от степени покрытия кода. Таким образом, кодовый путь, содержащий ошибку, должен быть обязательно пройден, а в контрольном примере должны создаваться необходимые условия для создания ошибочной ситуации. |
Таблица 2 — Аргументы «за» и «против» динамического анализа.
Раннее обнаружение ошибок для уменьшения затрат на разработку
Рис. 1 — По мере продвижения проекта стоимость устранения дефектов программного обеспечения может экспоненциально возрастать. Инструменты статического и динамического анализа помогают предотвратить эти затраты благодаря обнаружению программных ошибок на ранних этапах жизненного цикла программного обеспечения.
Статический анализ
Статический анализ используется в практике программных разработок почти столь же долго, как существует сама разработка программного обеспечения. В своем первоначальном виде анализ сводился к контролю соответствия стандартам стиля программирования (lint). Разработчики пользовались этим непосредственно на своем рабочем месте. Когда дело доходило до обнаружения программных ошибок, то в ранних инструментах статического анализа основное внимание обращалось на то, что лежит на поверхности: стиль программирования и часто возникающие синтаксические ошибки. Например, даже самые простейшие инструменты статического анализа смогут обнаружить ошибку такого рода:
Здесь ошибочное употребление лишней точки с запятой приводит к потенциально катастрофическим результатам: указатель входного параметра функции переопределяется при неожидаемых условиях. Указатель переопределяется всегда, вне зависимости от проверяемого условия.
Ранние инструменты анализа обращали внимание, главным образом, на синтаксические ошибки. Поэтому, хотя при этом и можно было обнаружить серьезные ошибки, все же большинство обнаруживаемых проблем оказывались относительно тривиальными. Кроме того, для инструментов предоставлялся достаточно небольшой кодовый контекст, чтобы можно было ожидать точных результатов. Это происходило потому, что работа проводилась в течение типичного цикла компиляции/компоновки при разработке, а то, что делал разработчик, представляло собой лишь маленькую частицу кода большой программной системы. Такой недостаток приводил к тому, что в инструменты анализа закладывались оценки и гипотезы относительно того, что может происходить за пределами «песочницы» разработчика. А это, в свою очередь, приводило к генерации повышенного объема отчетов с «ложными срабатываниями».
Следующие поколения инструментов статического анализа обращали внимание на эти недостатки и расширяли сферу своего влияния за пределы синтаксического и семантического анализа. В новых инструментах строилось расширенное представление или модель создаваемого кода (нечто похожее на фазу компиляции), а далее моделировались все возможные пути исполнения кода в соответствии с моделью. Далее производилось отображение на эти пути логических потоков с одновременным контролем того, как и где создаются, используются и уничтожаются объекты данных. В процессе анализа программных модулей могут подключаться процедуры анализа межпроцедурного управления и потока данных. При этом также минимизируются «ложные срабатывания» за счет использования новых подходов для отсекания ложных путей, оценки значений, которые могут принимать переменные, моделирования потенциального поведения при работе в реальном времени. Для генерации данных такого уровня в инструментах статического анализа необходимо анализировать всю кодовую базу проекта, проводить интегральную системную компоновку, а не просто работать с результатами, получаемыми в «песочнице» на рабочем столе разработчика.
Абстрактные синтаксические деревья
Абстрактное синтаксическое дерево просто является представлением исходного кода в виде древовидной структуры, как это может генерироваться на предварительных стадиях работы компилятора. Дерево содержит подробное однозначное разложение структуры кода, дающее возможность инструментам выполнить простой поиск аномальных мест синтаксиса.
Очень просто построить программу контроля, которая проверяет соблюдение стандартов относительно соглашения по присваиванию имен и ограничений по функциональным вызовам, например, контроль небезопасных библиотек. Цель выполнения проверок по AST обычно состоит в получении каких-либо логических выводов на основании кода как такового без использования знаний о поведении кода в процессе исполнения.
Многие инструменты предлагают проверки на основе AST для множества языков, включая инструменты с открытым исходным кодом, например, PMD для Java. Некоторые инструменты используют грамматику Х-путей или производную от Х-путей грамматику, чтобы определять условия, которые представляют интерес для программ контроля. Другие инструменты предоставляют расширенные механизмы, дающие возможность пользователям создавать свои собственные программы проверки на основе AST. Такой тип проверки относительно просто проводить, и многие организации создают новые программы проверки такого типа, чтобы проверить соблюдение корпоративных стандартов написания кода или рекомендованных по отрасли лучших методов организации работ.
Анализ кодовых путей
Рассмотрим более сложный пример. Теперь вместо поиска случаев нарушения стиля программирования мы хотим проверить, приведет ли предпринятая попытка разыменования указателя к правильной работе или к сбою:
Поверхностное рассмотрение фрагмента приводит к очевидному выводу, что переменная ptr может принимать значение NULL, если переменная x – нечетна, и это условие при разыменовании неизбежно приведет к обращению к нулевой странице. Тем не менее, при создании программы проверки на основе AST найти такую программную ошибку весьма проблематично. Рассмотрим дерево AST (в упрощенном виде для ясности), которое было бы создано для приведенного выше фрагмента кода:
В подобных случаях никакой поиск по дереву или простое перечисление узлов не смогут обнаружить в разумно обобщенной форме предпринимаемую попытку (по меньшей мере, иногда недопустимую) разыменования указателя ptr. Соответственно, инструмент анализа не может просто проводить поиск по синтаксической модели. Необходимо также анализировать жизненный цикл объектов данных по мере их появления и использования внутри управляющей логики в процессе исполнения.
Посредством подобного анализа путей исполнения кода, как в прямом направлении от запуска события к целевому сценарию, так и в обратном направлении от запуска события к требуемой инициализации данных, инструментальное средство сможет дать ответы на поставленные вопросы и выдать отчет об ошибках в случае, если целевой сценарий или инициализация исполняются или не исполняются так, как ожидается.
Реализация подобной возможности существенна для выполнения расширенного анализа исходного кода. Поэтому разработчики должны искать инструменты, в которых используется расширенный анализ кодовых путей для обнаружения утечек памяти, неправильного разыменования указателей, передачи небезопасных или неправильных данных, нарушений параллелизма и многих других условий, приводящих к возникновению проблем.
Последовательность действий при выполнении статического анализа
При статическом анализе могут быть обнаружены проблемы в двух ключевых точках процесса разработки: во время написания программе на рабочем месте и на этапе системной компоновки. Как уже говорилось, текущее поколение инструментальных средств работает, главным образом, на этапе системной компоновки, когда есть возможность проанализировать кодовый поток всей системы в целом, что приводит к весьма точным диагностическим результатам.
Уникальный в своем роде продукт Klocwork Insight позволяет проводить анализ кода, создаваемого на рабочем месте конкретного разработчика, при этом избегать проблем, связанных с неточностью диагностики, что обычно свойственно инструментам подобного рода. Компания Klocwork предоставляет возможность проведения связного анализа кода на рабочем месте (Connected Desktop Analysis), когда выполняется анализ кода разработчика с учетом понимания всех системных зависимостей. Это приводит к проведению локального анализа, который является в такой же мере точным и мощным, как и централизованный системный анализ, но все это выполняется до полной сборки кода.
С точки зрения перспектив относительно последовательности действий при анализе, данная способность позволяет разработчику провести точный и высококачественный статический анализ на самом раннем этапе жизненного цикла разработки. Инструмент Klockwork Insight выдает в интегрированную среду разработчика (IDE) или в командную строку сообщения по всем проблемам по мере написания разработчиком кода и периодического выполнения им операций компиляции/компоновки. Выдача таких сообщений и отчетов происходит до выполнения динамического анализа и до того, как все разработчики сведут свои коды воедино.
 | |
| Инструмент Klockwork Insight обеспечивает проведение анализа кода на рабочем месте, позволяя разработчикам устранить критические ошибки и уязвимости до полной сборки всего кода. | Инструмент Klockwork Insight интегрируется в среду компоновки для выполнения статического анализа с учетом перспектив работы в составе системы. В результате система обеспечения качества (QA) может тестировать код с меньшим количеством ошибок, больше обращая внимание на функциональные проблемы. |
Технология динамического анализа
Для обнаружения программных ошибок в инструментах динамического анализа часто производится вставка небольших фрагментов кода либо непосредственно в исходный текст программы (вставка в исходный код), либо в исполняемый код (вставка в объектный код). В таких кодовых сегментах выполняется «санитарная проверка» состояния программы и выдается отчет об ошибках, если обнаруживается что-то некорректное или неработоспособное. В таких инструментах могут быть задействованы и другие функции, например, отслеживание распределения памяти и ее использования во времени.
В данной статье мы рассмотрим технологии, используемые в инструментах разработчика QNX Momentics, особенно обращая внимание на GCC Mudflap и специализированные библиотеки этапа исполнения.
GNU C/C++ Mudflap: внедрение в исходный код на этапе компиляции
В инструментальном средстве Mudflap, присутствующем в версии 4.х компилятора GNU C/C++ (GCC), используется внедрение в исходный код во время компиляции. При этом во время исполнения происходит проверка конструкций, потенциально несущих в себе возможность появления ошибок. Основное внимание в средстве Mudflap обращается на операции с указателями, поскольку они являются источником многих ошибок на этапе выполнения для программ, написанных на языках C и C++.
С подключением средства Mudflap в работе компилятора GCC появляется еще один проход, когда вставляется проверочный код для операций с указателями. Вставляемый код обычно выполняет проверку на достоверность значений передаваемых указателей. Неправильные значения указателей приведут к выдаче компилятором GCC сообщений на стандартное устройство выдачи ошибок консоли (stderr). Средство Mudflap для контроля за указателями не просто проверяет указатели на нулевое значение: в его базе данных хранятся адреса памяти для действительных объектов и свойства объектов, например, местоположение в исходном коде, метка даты/времени, обратная трассировка стека при выделении и освобождении памяти. Такая база данных позволяет быстро получить необходимые данные при анализе операций доступа к памяти в исходном коде программы.
В библиотечных функциях, подобных strcpy(), не выполняется проверка передаваемых параметров. Такие функции не проверяются и средством Mudflap. Тем не менее, в Mudflap можно создать символьную оболочку (symbol wrapper) для статически подключаемых библиотек или вставку для динамических библиотек. При такой технологии между приложением и библиотекой создается дополнительный слой, что дает возможность провести проверку достоверности параметров и выдать сообщение о проявлении отклонений. В средстве Mudflap используется эвристический алгоритм, основанный на знании границ памяти, используемых приложением (динамическая память, стек, сегменты кода и данных и т.д.), чтобы определить правильность значений возвращаемых указателей.
На рис. 3 показан пример представления ошибки в среде IDE вместе с соответствующей информацией по обратной трассировке. Обратная трассировка работает как связующее звено с исходным кодом, что позволяет разработчику быстро диагностировать причину проблемы.
При использовании средства Mudflap может возрасти время на компоновку, и может уменьшиться производительность во время исполнения. Данные, представленные в статье “Mudflap: Pointer Use Checking for C/C++” [1] («Средство Mudflap: проверка использования указателей для языков C/C++”) говорят о том, что с подключением Mudflap время компоновки возрастает в 3…5 раз, а программа начинает работать медленнее в 1.25 … 5 раз. Совершенно ясно, что разработчики критических по времени исполнения приложений должны пользоваться эти средством с осторожностью. Тем не менее Mudflap является мощным средством для выявления подверженных ошибкам и потенциально фатальных кодовых конструкций. Компания QNX планирует использовать средство Mudflap в будущих версиях своих инструментов динамического анализа.
Рис. 3 — Использование информации обратной трассировки, отображаемой в среде QNX Momentics IDE для поиска исходного кода, приведшего к ошибке.
Отладочные версии библиотек этапа исполнения
Наряду с использованием специальных отладочных вставок в библиотеки этапа исполнения, которые приводят к значительным дополнительным расходам памяти и времени на этапах компоновки и исполнения, разработчики могут использовать предварительно подготовленные (pre-instrumented) библиотеки этапа исполнения. В таких библиотеках вокруг функциональных вызовов добавляется определенный код, цель которого состоит в проверке достоверности входных параметров. Например, рассмотрим старую знакомую – функцию копирования строк:
В отладочной версии библиотеки производится проверка значений параметров ‘ a ’ и ‘ b ’. Проверяются также длины строк, чтобы убедиться в их совместимости. Если обнаруживается недействительный параметр, то выдается соответствующее аварийное сообщение. В среде QNX Momentics данные сообщения об ошибках импортируются из целевой системы и выводятся на экран. В среде QNX Momentics используется также технология слежениями за случаями выделения и освобождения памяти, что дает возможность выполнять глубокий анализ использования ОЗУ.
Отладочная версия библиотеки будет работать с любым приложением, в котором используются ее функции; не нужно вносить никаких дополнительных изменений в код. Более того, разработчик может добавить библиотеку во время запуска приложения. Тогда библиотека заменит соответствующие части полной стандартной библиотеки, устраняя необходимость использовать отладочную версию полной библиотеки. В среде QNX Momentics IDE разработчик может добавить такую библиотеку при запуске программы как элемент нормального интерактивного сеанса отладки. На рис. 4 показан пример того, как в среде QNX Momentics происходит обнаружение и выдача сообщений об ошибках работы с памятью.
В отладочных версиях библиотек предоставляется проверенный «неагрессивный» метод обнаружения ошибок при вызовах библиотечных функций. Такая технология идеальна для анализа ОЗУ и для других методов анализа, которые зависят от согласованных пар вызовов, например, malloc() и free(). Другими словами, данная технология может обнаруживать ошибки на этапе исполнения только для кодов с библиотечными вызовами. При этом не обнаруживаются многие типичные ошибки, такие как встроенный код разыменования ссылки (inline pointer dereferences) или некорректные арифметические операции с указателями. Обычно при отладке осуществляется контроль только некоторого подмножества системных вызовов. Подробнее с этим можно познакомиться в статье [2].
Рис. 4 — Анализ ОЗУ происходит путем расстановки ловушек в области вызовов API, связанных с обращением к памяти.
Последовательность действий при динамическом анализе
Если говорить кратко, то динамический анализ включает в себя захват событий о нарушениях или других значительных событиях во встраиваемой целевой системе, импорт этой информации в среду разработки, после чего используются средства визуализации для быстрой идентификации содержащих ошибку участков кода.
Рис. 5 — Типовая последовательность действий при динамическом анализе
Комбинирование последовательности действий различных видов анализа в среде разработки
Каждый из инструментов статического и динамического анализа имеет свои сильные стороны. Соответственно, команды разработчиков должны использовать эти инструменты в тандеме. Например, инструменты статического анализа способны обнаруживать ошибки, которые пропускаются инструментами динамического анализа, потому что инструменты динамического анализа фиксируют ошибку лишь в случае, если во время тестирования ошибочный фрагмент кода исполняется. С другой стороны, инструменты динамического анализа обнаруживают программные ошибки конечного работающего процесса. Вряд ли нужно устраивать дискуссию по поводу ошибки, если уже обнаружено использование указателя с нулевым значением.
В идеальном случае разработчик в ежедневной работе будет использовать оба инструмента анализа. Задача существенно облегчается, если инструменты хорошо интегрированы в среду разработки на рабочем месте.
Подобная последовательность действий похожа на применяемую в проектах среднего и большого размеров, где уже используются ночные компоновки, система управления исходными кодами и персональная ответственность за коды. Поскольку инструменты интегрированы в среду IDE, разработчики быстро выполняют статический и динамический анализ, не отклоняясь от типовой последовательности действий. В результате качество кода существенно возрастает уже на этапе создания исходных текстов.
Роль архитектуры ОСРВ
В рамках дискуссии об инструментах статического и динамического анализа упоминание об архитектуре ОСРВ может показаться неуместным. Но оказывается, что правильно построенная ОСРВ может в значительной степени облегчить обнаружение, локализацию и разрешение многих программных ошибок.
Например, в микроядерной ОСРВ типа QNX Neutrino все приложения, драйверы устройств, файловые системы и сетевые стеки располагаются за пределами ядра в отдельных адресных пространствах. В результате все они оказываются изолированными от ядра и друг от друга. Такой подход обеспечивает наивысшую степень локализации сбоев: отказ одного из компонентов не приводит к краху системы в целом. Более того, оказывается, что можно легко локализовать ошибку, связанную с ОЗУ, или иную логическую ошибку с точностью до компонента, который эту ошибку вызвал.
Например, если драйвер устройства делает попытку доступа к памяти за пределами своего контейнера процесса, то ОС может идентифицировать такой процесс, указать место ошибки и создать дамп-файл, который может быть просмотрен средствами отладки исходного кода. В то же время, остальная часть системы продолжит свою работу, а разработчик может локализовать проблему и заняться ее устранением.
Рис. 6 — В микроядерной ОС сбои в ОЗУ для драйверов, стеков протоколов и других службах не приведут к нарушению работы других процессов или ядра. Более того, ОС может мгновенно обнаружить неразрешенную попытку доступа к памяти и указать, со стороны какого кода предпринята эта попытка.
По сравнению с обычным ядром ОС микроядру свойственно необычайно малое среднее время восстановления после сбоя (Mean Time to Repair, MTTR). Рассмотрим, что происходит при сбое в работе драйвера устройства: ОС может завершить работу драйвера, восстановить используемые драйвером ресурсы и перезапустить драйвер. Обычно на это уходит несколько миллисекунд. В обычной монолитной операционной системе устройство должно быть перезагружено – этот процесс может занять от нескольких секунд до нескольких минут.
Заключительные замечания
Инструменты статического анализа могут обнаруживать программные ошибки еще до того, как код запускается на исполнение. Обнаруживаются даже те ошибки, которые оказываются не выявленными на этапах тестирования блока, системы, а также на этапе интеграции, потому что обеспечить полное покрытие кода для сложных приложений оказывается очень трудно, и это требует значительных затрат. Кроме того, команды разработчиков могут использовать инструменты статического анализа во время регулярных компоновок системы, чтобы быть уверенным в том, что проанализирован каждый участок нового кода.
Использование раннего обнаружения, лучшего и полного тестового покрытия кода совместно с коррекцией ошибок помогает разработчикам создавать программное обеспечение лучшего качества и в более короткие сроки.
Библиография
О компании QNX Software Systems
QNX Software Systems является одной из дочерних компаний Harman International и ведущим глобальным поставщиком инновационных технологий для встраиваемых систем, включая связующее ПО, инструментальные средства разработки и операционные системы. ОСРВ QNX® Neutrino®, комплект разработчика QNX Momentics® и связующее ПО QNX Aviage®, основанные на модульной архитектуре, образуют самый надежный и масштабируемый программный комплекс для создания высокопроизводительных встраиваемых систем. Глобальные компании-лидеры, такие как Cisco, Daimler, General Electric, Lockheed Martin и Siemens, широко используют технологии QNX в сетевых маршрутизаторах, медицинской аппаратуре, телематических блоках автомобилей, системах безопасности и защиты, в промышленных роботах и других приложениях для ответственных и критически важных задач. Головной офис компании находится в г. Оттава (Канада), а дистрибьюторы продукции расположены в более чем 100 странах по всему миру.