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

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

Проблемы с качеством не всегда являются результатом игнорирования приёмов и концепции контроля качества. Это может быть следствием ненадлежащего исполнения обязанностей. Если вам приходилось беседовать с менеджерами или ведущими специалистами о контроле качества в таком проекте, они, вероятно, постарались наговорить много всего о том, что нужно сделать. Но когда вы видите их проекты, то замечаете, что ничего не делается. Создание качественного продукта требует усилий: сосредоточенности, активного участия, исполнительности. Это не теоретические выкладки — все члены команды должны действовать активно и увлечённо.

Я настоятельно рекомендую тестировать продукты сначала вширь, а затем вглубь. Убедитесь, что все основные функции реализованы и нормально работают, прежде чем тратить время на второстепенные функции. Конечно, как я говорил ранее, следует расставить приоритеты в тестировании функций. Однако очень часто команды тратят слишком много времени на мелкие детали какой-то функции, в то время как оставшаяся часть продукта разваливается. Возьмите в качестве примера постройку здания. Какой смысл полировать все до блеска в вестибюле, когда лифты не работают!

Глава 7

Основы технологии разработки программ

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

Какой бы ни была ваша организация, большой или маленькой, вы должны иметь возможность на регулярной основе собирать и устанавливать ваше ПО. Однако слишком часто команды разработчиков неделями и даже месяцами не могут собрать или установить свою собственную программу. Хуже того, никто из них не отвечает за проблемы со сборкой и процедурой установки, так что эта проблема тормозит процесс разработки. Из-за того, что проект невозможно собрать или установить, могут появиться проблемы любого рода, что вызовет задержки. Если вы не знаете точно реальное состояние вашей программы, потому что не можете увидеть или использовать её, значит, вы действуете вслепую. Чтобы воспользоваться советами, данными в книге, вы должны в обязательном порядке иметь возможность собирать и устанавливать ПО.

Технологи по разработке ПО

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

• определение, создание и сопровождение сборочной среды продукта;

• определение, создание и сопровождение процедуры установки продукта;

• определение, создание и обслуживание пакетов исправлений или сервисных пакетов;

• проведение модульного тестирования и основных мероприятий по контролю качества процедуры установки;

• разработка инструментов, сценариев и автоматизация разработки ПО;

• планирование сборочной среды (сборочной лаборатории).

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

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

В NuMega не было выделенных технологов, функции реализации готового продукта выполняла команда. Сначала она состояла из инженера по поддержке и специалиста по инженерной психологии. Что бы вы ни думали, они по совместительству составляли великолепную команду и больше года отлично решали технологические проблемы. Талантливые люди могут брать на себя много задач! Но однажды они позвонили мне из сборочной лаборатории (на самом деле это небольшая комнатка), где боролись со сложной сборкой и сценарием установки. Сообщение было недвусмысленным: «Эд! С нас хватит! Найми технолога!»

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

Сборки

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

Способность собирать ПО является определяющей для поставки программ в срок. Одна из наиболее часто возникающих проблем при создании ПО — заставить все части работать вместе. Если о ней забыть до окончания проекта, то потом решение проблемы займёт недели или месяцы работы. В худшем случае потребуется переопределение каких-то API и функций. А это, естественно, означает появление никем не запланированных задержек.

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

Когда я пришёл в NuMega, единственным человеком, способным собрать продукт целиком, был один из талантливейших инженеров — Мэт Питрек. Даже когда команда и продукты ещё были небольшими, среда разработки была чрезвычайно сложной. Только Мэт знал, что делать. Чтобы собрать программу, он уходил в свой кабинет и закрывал дверь. Он как помешанный колдовал над тремя разными компиляторами и дюжиной сценариев, вручную редактировал конфигурационные и другие файлы. Затем, после 3-4 часов интенсивной работы, он взмахивал волшебной палочкой, и обычно у нас появлялась готовая сборка. Мы предполагали, что он не нашёл никаких проблем.

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

При регулярном создании сборок разработчики могут проверять интеграцию кода. Интерфейсы API, файлы заголовков, параметры, типы данных и макросы — все должны быть в полностью рабочем состоянии, иначе сборка пройдёт некорректно. Сбой при сборке заставит разработчиков общаться друг с другом и при необходимости изменять программу. Но ведь это именно то, что вам нужно: искать и устранять проблемы на раннем этапе, а не в самом конце, скажем, за день до того, когда от вас требуется бета-версия.

Далее приведён ряд рекомендаций о том, как сделать задачу создания сборки более простой и эффективной.

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

Make существует уже несколько десятилетий, всё началось в UNIX, а затем она появилась практически на всех остальных платформах. В течение многих лет её улучшали, и последняя версия — Nmake — входит в состав Microsoft Visual Studio. Обязательно изучите утилиту Make в вашей среде разработки и используйте её для автоматизации задач сборки ПО.