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

1. Изменения в инфраструктуре
инструментов для программистов
Автор: Андрей Карпов
Дата: 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. Ранее мы были больше сосредоточены на тестировании
внутренних модулей, но с ростом интерфейсной части, встала задача перейти от ее ручного
тестирования к автоматическому. Тем не менее, наши запросы достаточно скромны и мы

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

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

5. Рисунок 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. И уверен,
что для некоторых эти функции важны или просто удобны и полезны. Есть масса людей, для

6. которых Visual Assist со временем ничуть не теряет важности, а наоборот становится все более
незаменим. Однако, лично я пользовался весьма скромным ассортиментом возможностей и не
испытывал нужды в большем. И эти возможности сейчас удовлетворены средой Visual Studio.
Рассмотрю несколько примеров, вооружившись Visual Studio 2010.
Имеется расцветка синтаксиса. Пусть она не такая разноцветная как в Visual Assist, но вполне
приятная и достаточная для меня. А если учесть подчеркивание синтаксических ошибок, так и
вообще замечательно (смотри рисунок 3).
Рисунок 3 - Подсветка кода в Visual Studio 2010 и подчеркивание некорректных конструкций
Хорошо работает система подсказок по параметрам функций и подсказки имен по первым
введенным символам имени (смотри рисунки 4 и 5):
Рисунок 4 - Подсказка по параметрам функции в Visual Studio 2010

7. Рисунок 5 - Подсказка по именам функций в Visual Studio 2010
Есть возможность, которой мне действительно не хватало без Visual Assist. Это подсказка имен
файлов. В Visual Studio 2010 такая возможность появилась (смотри рисунок 6).

8. Рисунок 6 - Подсказка по именам подключаемых файлов в Visual Studio 2010
Visual Assist помогал мне разобраться даже в плохо отформатированном коде, когда необходимо
понять, где открывается и закрывается скобка. Visual Studio 2010 предоставляет такую же
функциональность, подсвечивая парные скобки, как показано на рисунке 7.
Рисунок 7 - Подсветка парных скобок в Visual Studio 2010

9. Функциональность редактора кода в Visual Studio 2010 меня полностью удовлетворяет. Возможно,
и вы взглянете на этот редактор Visual Studio как бы вновь.
Статический анализ
Когда разговор заходит о статическом анализе Си++ кода, то часто у программиста возникает
ассоциация: "Это некие инструменты типа lint, имеющие command-line интерфейс и которые уже
неактуальны". Попробуем разобраться, как возникло это мнение. Не буду говорить о компаниях и
зрелых процессах разработки, где статический анализ использовался раньше, используется сейчас
и будет использоваться в будущем. Но большинство используют незрелые процессы. Стесняться
этого не стоит. Это недостаток не программистов, а организаций. Для них статический анализатор
все-таки больше экзотика, чем повседневный инструмент, интегрированный в процесс
разработки.
Язык Си является языком, требующим большой аккуратности и внимательности от программиста,
так как очень слабо контролирует выполняемые в коде действия. Более опасным языком
является, пожалуй, только ассемблер. В связи с этим появились инструменты статического анализа
кода, наиболее известным представителем которых является lint. Этот и аналогичные
инструменты использовались достаточно широко в силу отсутствия альтернативных способов
обнаружить ошибки на этапе кодирования. Они были актуальны для циклов разработки программ
любого уровня зрелости.
Новый язык Си++, за счет более строго контроля типов и других усовершенствований, стал гораздо
более безопасным. Компиляторы для Си и Си++ начали выдавать предупреждения о многих
потенциально опасных ситуациях. Фактически они взяли на себя многие функции существовавших
статических анализаторов, и использование последних стало менее популярным. В этот момент
многие отказались от дополнительного уровня анализа с использованием сторонних
инструментов.
Тем не менее, статические анализаторы вовсе не устарели. Они научились обнаруживать многие
типы ошибок связанные с объектно-ориентированным программированием, предупреждать о
некорректном использовании библиотек (например, Qt) и даже выявлять ошибки в параллельных
программах. Следствие - статические анализаторы, как и ранее, позволяют существенно сократить
расходы на этапе тестирования и поддержки. И что приятно, теперь это обычно не отдельные
инструменты, а модули, интегрирующиеся в среду разработки.
Хочется подчеркнуть, что мнение о статических анализаторах как об устаревших command-line
решениях само устарело. Это современные инструменты, прекрасно дополняющее стандартные
возможности компилятора и другие инструменты повышения качества программ.
В качестве примера, вновь возьмем Visual Studio. Начиная с Visual Studio 2005 в состав версии
Team System входит подсистема статического анализа общего назначения Code Analysis. Хотя
система является расширением, она плотно интегрирована в среду и работа с ее
диагностическими сообщениями аналогична работе с сообщениями, выдаваемыми
компилятором (смотри рисунок 8).

11. Рисунок 8 - Вклада настроек Code Analysis в Visual Studio 2010
Существуют и другие, специализированные статические анализаторы. В качестве примера могу
привести разрабатываемый нами анализато PVS-Studio, который также плотно интегрируется в
анализатор ,
Visual Studio (смотри рисунок 9) и позволяет выявить многие ошибки в 64
64-битных и OpenMP
программах.

13. Рисунок 9 - Интеграция PVS-Studio в Visual Studio 2010
Современные статические анализаторы это дружественные программы, работу с которыми могут
осуществлять не только профессионалы, но и программисты, только приступившие к работе.

14. Динамический анализ
Говоря о динамическом анализаторе для поиска ошибок работы с памятью, в первую очередь все
вспоминают об инструменте 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 позволяет выявить
использование некорректных ссылок на участки памяти, контролирует стек и так далее. Проверки
потоков включают в себя проверки состояний гонки, взаимных блокировок, анализ стека вызовов
с настраиваемой глубиной.

15. Рисунок 10 - Настройка уровня диагностики в Intel Parallel Inspector
Самое приятное, что можно осуществлять анализ программ как собранных с помощью Intel C++,
так и с помощью Visual C++. Поддерживается анализ Win32 и Win64 приложений. Intel Parallel
Studio стабильно развивается, имеет невысокую цену и его использование можно смело включать
в долговременные планы.
Заключение
Инфраструктура инструментов для программистов постоянно изменяется. Можно найти как новые
более удобные решения, так и отказаться от некоторых старых (из-за прекращения их развития).
Кстати в крупных компаниях есть специальные сотрудники (и даже отделы), которые занимаются
только тем, что следят за развитием используемых в процессе разработки инструментов.