Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

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

Одним из наиболее важных инструментов для наших разработчиков был разработанный NuMega Technologies невероятно мощный отладчик для Windows — SoftICE. Он загружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные возможности управления и наблюдения за внутренними процессами приложения и операционной системы. Команда разработчиков часто использовала SoftICE для разрешения наиболее сложных проблем при отладке.

Мы часто использовали средства анализа производительности, в том числе наши собственные продукты TrueTime и TrueCoverage, для настройки производительности собираемых приложений. Мы поняли, что эти инструменты нужно использовать регулярно в течение цикла разработки, а не в самом конце, когда времени на оптимизацию или устранение проблем не хватает. Анализ производительности проекта по завершении определённого этапа или при выпуске бета-версии предупреждает проблемы и часто раскрывает ошибки, которые могут не проявляться в коде до самого выпуска. Не ждите, пока вы столкнётесь с проблемами производительности, а начинайте сразу применять средства анализа производительности.

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

Так как наши планы тестирования требовали максимально возможной автоматизации, мы всегда интересовались инструментами, способными нам в этом помочь. Наиболее важными были средства написания сценариев (Perl, командные файлы DOS и т.п.) и средства автоматизации тестирования. В то время Visual Test был доступен по разумной цене и предлагался взыскательным тестировщикам и разработчикам. С его помощью мы тестировали пользовательский интерфейс, но в подавляющем большинстве мероприятий по автоматизации полагались на средства написания сценариев.

Из собственного опыта

Когда мы создавали группу разработки ПО, проверяющего исправность кода, члены команды не были до конца уверены в его значимости. Но с продвижением проекта, когда команда начала применять собственный продукт на собственном коде, стало ясно, что если разработчики блочно тестировали свой код с полнотой 80%, то качество продукта заметно повышалось.

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

• Отбор нужных инструментов

Одна из главных ошибок которую допускают команды разработчиков, — игнорирование нужных инструментов. Я убеждён в том, что система управления исходным кодом и система устранения проблем и неисправностей необходимы. В равной степени для команды разработчиков важны средства отладки, поиска ошибок, оптимизации производительности и проверки полноты. Они помогут решить многие уникальные проблемы, всплывающие на поверхность в процессе разработки.

Всё, что может ускорить и автоматизировать цикл разработки, критично для вашего графика. Слишком часто графики сбиваются, так как сложные ошибки или проблемы с производительностью вносятся в процессе разработки, но не выявляются на раннем этапе. Когда они обнаружены, людям без посторонней помощи устранить их практически невозможно. Времени искать нужные инструменты в Интернете просто не будет. Убедитесь, что определились с инструментами, которые вам понадобятся, интегрировали их в процесс разработки и обучили персонал работе с ними.

• Смена инструментов на средине пути

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