Набор инструментов, используемых разработчиком, регулярно обновляется. Появляются совершенно новые инструменты, некоторые перестает быть актуальным, какие-то перестают развиваться и вытесняются более совершенными аналогами. За всем этим наблюдать достаточно интересно, и я решил поделиться некоторыми своими последними наблюдениями в этой области.
Еще сразу хочу заметить, что мне близка позиция, что чем меньше разнородных инструментов используется, тем лучше. Я заранее готов к критике в минимализме функциональности. Моя позиция спорная, но вполне заслуживает право на существование.
Некоторая функциональность, которая ранее была доступна только при использовании сторонних утилит, постепенно перемещается в среды разработки. В частности в 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. На рисунках 1 и 2 приведены некоторые окна системы тестирования Visual Studioв процессе работы.
Рисунок 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 — Вклада настроек Code Analysis в Visual Studio 2010
Существуют и другие, специализированные статические анализаторы. В качестве примера могу привести разрабатываемый нами анализатор PVS-Studio, который также плотно интегрируется в 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 стабильно развивается, имеет невысокую цену и его использование можно смело включать в долговременные планы.
Инфраструктура инструментов для программистов постоянно изменяется. Можно найти как новые более удобные решения, так и отказаться от некоторых старых (из-за прекращения их развития). Кстати в крупных компаниях есть специальные сотрудники (и даже отделы), которые занимаются только тем, что следят за развитием используемых в процессе разработки инструментов.
Еще сразу хочу заметить, что мне близка позиция, что чем меньше разнородных инструментов используется, тем лучше. Я заранее готов к критике в минимализме функциональности. Моя позиция спорная, но вполне заслуживает право на существование.
Автоматизированное тестирование
Некоторая функциональность, которая ранее была доступна только при использовании сторонних утилит, постепенно перемещается в среды разработки. В частности в 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. На рисунках 1 и 2 приведены некоторые окна системы тестирования Visual Studioв процессе работы.
Рисунок 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 — Вклада настроек Code Analysis в Visual Studio 2010
Существуют и другие, специализированные статические анализаторы. В качестве примера могу привести разрабатываемый нами анализатор PVS-Studio, который также плотно интегрируется в 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 стабильно развивается, имеет невысокую цену и его использование можно смело включать в долговременные планы.
Заключение
Инфраструктура инструментов для программистов постоянно изменяется. Можно найти как новые более удобные решения, так и отказаться от некоторых старых (из-за прекращения их развития). Кстати в крупных компаниях есть специальные сотрудники (и даже отделы), которые занимаются только тем, что следят за развитием используемых в процессе разработки инструментов.
