Изменения в инфраструктуре

инструментов для программистов

Автор: Андрей Карпов

Дата: 26.04.2010

Аннотация

В статье приведены некоторые наблюдения, связанные с изменением в инфраструктуре

инструментов, используемых программистами в повседневной работе. В первую очередь эти

наблюдения связаны с выходом Visual Studio 2010.

Введение

Набор инструментов, используемых разработчиком, регулярно обновляется. Появляются

совершенно новые инструменты, некоторые перестает быть актуальным, какие-то перестают

развиваться и вытесняются более совершенными аналогами. За всем этим наблюдать достаточно

интересно, и я решил поделиться некоторыми своими последними наблюдениями в этой области.

Еще сразу хочу заметить, что мне близка позиция, что чем меньше разнородных инструментов

используется, тем лучше. Я заранее готов к критике в минимализме функциональности. Моя

позиция спорная, но вполне заслуживает право на существование.

Автоматизированное тестирование

Некоторая функциональность, которая ранее была доступна только при использовании сторонних

утилит, постепенно перемещается в среды разработки. В частности в Visual Studio. Однако эта

функциональность по-прежнему ассоциируется у разработчиков только со сторонними

инструментами. Для примера можно привести систему автоматизированного тестирования

пользовательского интерфейса приложений, появившуюся в Visual Studio 2010 Premium/Ultimate,

которая делает возможным во многих случаях отказаться от таких инструментов как AutomatedQA

TestComplete или Borland SilkTest.

Прошу понять меня правильно. Я вовсе не предлагаю отказываться от имеющейся базы тестов и

срочно начинать переход на систему тестирования, встроенную в Visual Studio 2010. И я вовсе не

агитирую за ее использование. TestComplete - это один из самых мощных коммерческих

продуктов, предназначенных для автоматизации тестирования программного обеспечения.

Однако если вы используете Visual Studio 2010 и принимаете решение о выборе системы

автоматизированного тестирования для нового проекта, то возможно вам не стоит далеко ходить.

Если не требуются особые специфические возможности при тестировании, то вам не придется

покупать и использовать дополнительные системы помимо Visual Studio 2010.

Мы используем систему тестирования пользовательского интерфейса из Visual Studio для

тестирования интерфейса PVS-Studio. Ранее мы были больше сосредоточены на тестировании

внутренних модулей, но с ростом интерфейсной части, встала задача перейти от ее ручного

тестирования к автоматическому. Тем не менее, наши запросы достаточно скромны и мы

довольны, что выбрали тестирование в Visual Studio. На ри

системы тестирования Visual Studio в процессе работы.

довольны, что выбрали тестирование в Visual Studio. На рисунках 1 и 2 приведены некоторые окна

системы тестирования Visual Studio в процессе работы.

сунках 1 и 2 приведены некоторые окна

Рисунок 1 - Запись действий пользователя в Visual Studio

Рисунок 2 - Дерево элементов управления в Visual Studio

Вывод - выгодно изучить нововведения в уже используемом инструментарии. Если у вас

стандартные запросы по тестированию, то возможно вам хватит функциональности Visual Studio

при разработке новых проектов. Тем самым количество сущностей (инструментов), с которыми вы

имеете дело, не увеличится, а это всегда хорошо.

Редактор кода

Аналогично с тестированием, дело обстоит и с помощником - Visual Assist. Я помню, как хорошо с

ним было во времена Visual Studio 6.0. Но многие говорят о его полезности, просто не зная о

современных возможностях последних Visual Studio или не замечая их. Большинство

возможностей, которые я так ценил в Visual Assist, постепенно реализовались в Visual Studio.

Начиная с Visual Studio 2008, я пришел к выводу, что спокойно могу спокойно обходиться без

Visual Assist и отказался от его использования. С выходом Visual Studio 2010 использование Visual

Assist стало для меня совершенно неактуальным.

Не спорю, в Visual Assist есть функции, которые никогда не будет входить Visual Studio. И уверен,

что для некоторых эти функции важны или просто удобны и полезны. Есть масса людей, для

которых Visual Assist со временем ничуть не теряет важности, а наоборот становится все более

незаменим. Однако, лично я пользовался весьма скромным ассортиментом возможностей и не

испытывал нужды в большем. И эти возможности сейчас удовлетворены средой Visual Studio.

Рассмотрю несколько примеров, вооружившись Visual Studio 2010.

Имеется расцветка синтаксиса. Пусть она не такая разноцветная как в Visual Assist, но вполне

приятная и достаточная для меня. А если учесть подчеркивание синтаксических ошибок, так и

вообще замечательно (смотри рисунок 3).

Рисунок 3 - Подсветка кода в Visual Studio 2010 и подчеркивание некорректных конструкций

Хорошо работает система подсказок по параметрам функций и подсказки имен по первым

введенным символам имени (смотри рисунки 4 и 5):

Рисунок 4 - Подсказка по параметрам функции в Visual Studio 2010

Рисунок 5 - Подсказка по именам функций в Visual Studio 2010

Есть возможность, которой мне действительно не хватало без Visual Assist. Это подсказка имен

файлов. В Visual Studio 2010 такая возможность появилась (смотри рисунок 6).

Рисунок 6 - Подсказка по именам подключаемых файлов в Visual Studio 2010

Visual Assist помогал мне разобраться даже в плохо отформатированном коде, когда необходимо

понять, где открывается и закрывается скобка. Visual Studio 2010 предоставляет такую же

функциональность, подсвечивая парные скобки, как показано на рисунке 7.

Рисунок 7 - Подсветка парных скобок в Visual Studio 2010

Функциональность редактора кода в Visual Studio 2010 меня полностью удовлетворяет. Возможно,

и вы взглянете на этот редактор Visual Studio как бы вновь.

Статический анализ

Когда разговор заходит о статическом анализе Си++ кода, то часто у программиста возникает

ассоциация: "Это некие инструменты типа lint, имеющие command-line интерфейс и которые уже

неактуальны". Попробуем разобраться, как возникло это мнение. Не буду говорить о компаниях и

зрелых процессах разработки, где статический анализ использовался раньше, используется сейчас

и будет использоваться в будущем. Но большинство используют незрелые процессы. Стесняться

этого не стоит. Это недостаток не программистов, а организаций. Для них статический анализатор

все-таки больше экзотика, чем повседневный инструмент, интегрированный в процесс

разработки.

Язык Си является языком, требующим большой аккуратности и внимательности от программиста,

так как очень слабо контролирует выполняемые в коде действия. Более опасным языком

является, пожалуй, только ассемблер. В связи с этим появились инструменты статического анализа

кода, наиболее известным представителем которых является lint. Этот и аналогичные

инструменты использовались достаточно широко в силу отсутствия альтернативных способов

обнаружить ошибки на этапе кодирования. Они были актуальны для циклов разработки программ

любого уровня зрелости.

Новый язык Си++, за счет более строго контроля типов и других усовершенствований, стал гораздо

более безопасным. Компиляторы для Си и Си++ начали выдавать предупреждения о многих

потенциально опасных ситуациях. Фактически они взяли на себя многие функции существовавших

статических анализаторов, и использование последних стало менее популярным. В этот момент

многие отказались от дополнительного уровня анализа с использованием сторонних

инструментов.

Тем не менее, статические анализаторы вовсе не устарели. Они научились обнаруживать многие

типы ошибок связанные с объектно-ориентированным программированием, предупреждать о

некорректном использовании библиотек (например, Qt) и даже выявлять ошибки в параллельных

программах. Следствие - статические анализаторы, как и ранее, позволяют существенно сократить

расходы на этапе тестирования и поддержки. И что приятно, теперь это обычно не отдельные

инструменты, а модули, интегрирующиеся в среду разработки.

Хочется подчеркнуть, что мнение о статических анализаторах как об устаревших command-line

решениях само устарело. Это современные инструменты, прекрасно дополняющее стандартные

возможности компилятора и другие инструменты повышения качества программ.

В качестве примера, вновь возьмем Visual Studio. Начиная с Visual Studio 2005 в состав версии

Team System входит подсистема статического анализа общего назначения Code Analysis. Хотя

система является расширением, она плотно интегрирована в среду и работа с ее

диагностическими сообщениями аналогична работе с сообщениями, выдаваемыми

компилятором (смотри рисунок 8).

Рисунок 8

Существуют и другие, специализированные статические анализаторы. В качестве примера могу

привести разрабатываемый нами анализато

Visual Studio (смотри рисунок 9) и позволяет выявить многие ошибки в 64

программах.

Рисунок 8 - Вклада настроек Code Analysis в Visual Studio 2010

Существуют и другие, специализированные статические анализаторы. В качестве примера могу

привести разрабатываемый нами анализатор PVS-Studio, который также плотно интегрируется в

Visual Studio (смотри рисунок 9) и позволяет выявить многие ошибки в 64

Вклада настроек Code Analysis в Visual Studio 2010

Существуют и другие, специализированные статические анализаторы. В качестве примера могу

, который также плотно интегрируется в

Visual Studio (смотри рисунок 9) и позволяет выявить многие ошибки в 64-битных и OpenMP

Рисунок 9 - Интеграция PVS-Studio в Visual Studio 2010

Современные статические анализаторы это дружественные программы, работу с которыми могут

осуществлять не только профессионалы, но и программисты, только приступившие к работе.

Динамический анализ

Говоря о динамическом анализаторе для поиска ошибок работы с памятью, в первую очередь все

вспоминают об инструменте DevPartner BoundsChecker Suite. Однако хочется уменьшить пыл его

сторонников и тех, кто рекомендует его в форумах. Бесспорно, это был замечательный и

незаменимый инструмент на протяжении долгого времени. К сожалению, в настоящее время

проект не развивается и быстро устаревает. Например, BoundsChecker не поддерживает Win64

приложения. Он способен запускаться в 64-битной среде и проверять 32-битные приложения, но

не умеет работать с 64-битными приложениями. Цитата из буклета: "DevPartner Studio supports 32-

bit application development on 64-bit Windows (WOW 64)".

Отставание такого рода недопустимо для инструментов тестирования. К счастью на смену

BoundsChecker и другим инструментам динамического анализа пришел новый титан, на котором

гораздо разумнее сосредоточить свое внимание. Речь идет об инструменте Intel Parallel Inspector

входящем в состав Intel Parallel Studio.

Intel Parallel Studio интегрируется в Visual Studio (смотри рисунок 10) и добавляет возможность

проверки работы с памятью и потоками. Проверка памяти в Intel Parallel Inspector включает в себя

проверку утечки памяти, обнаружение указателей, ссылающихся на удаленный объект, выявление

работы с неинициализированными переменными. Intel Parallel Inspector позволяет выявить

использование некорректных ссылок на участки памяти, контролирует стек и так далее. Проверки

потоков включают в себя проверки состояний гонки, взаимных блокировок, анализ стека вызовов

с настраиваемой глубиной.

Рисунок 10 - Настройка уровня диагностики в Intel Parallel Inspector

Самое приятное, что можно осуществлять анализ программ как собранных с помощью Intel C++,

так и с помощью Visual C++. Поддерживается анализ Win32 и Win64 приложений. Intel Parallel

Studio стабильно развивается, имеет невысокую цену и его использование можно смело включать

в долговременные планы.

Заключение

Инфраструктура инструментов для программистов постоянно изменяется. Можно найти как новые

более удобные решения, так и отказаться от некоторых старых (из-за прекращения их развития).

Кстати в крупных компаниях есть специальные сотрудники (и даже отделы), которые занимаются

только тем, что следят за развитием используемых в процессе разработки инструментов.