Эта технология является решающей для своевременного выпуска продукта. В этой главе я расскажу об основах технологии разработки ПО и её применении в повседневной работе.
Какой бы ни была ваша организация, большой или маленькой, вы должны иметь возможность на регулярной основе собирать и устанавливать ваше ПО. Однако слишком часто команды разработчиков неделями и даже месяцами не могут собрать или установить свою собственную программу. Хуже того, никто из них не отвечает за проблемы со сборкой и процедурой установки, так что эта проблема тормозит процесс разработки. Из-за того, что проект невозможно собрать или установить, могут появиться проблемы любого рода, что вызовет задержки. Если вы не знаете точно реальное состояние вашей программы, потому что не можете увидеть или использовать её, значит, вы действуете вслепую. Чтобы воспользоваться советами, данными в книге, вы должны в обязательном порядке иметь возможность собирать и устанавливать ПО.
Технологи по разработке ПО
Это члены команды, работающей над проектом, которые имеют необходимые навыки работы с процессами и технологиями сборки и установки ПО. Хотя технологи могут выполнять множество обязанностей, в контексте нашего обсуждения выделим наиболее важные:
• определение, создание и сопровождение сборочной среды продукта;
• определение, создание и сопровождение процедуры установки продукта;
• определение, создание и обслуживание пакетов исправлений или сервисных пакетов;
• проведение модульного тестирования и основных мероприятий по контролю качества процедуры установки;
• разработка инструментов, сценариев и автоматизация разработки ПО;
• планирование сборочной среды (сборочной лаборатории).
Для выполнения этих задач технологи должны быть включены в команду, работающую над проектом, с самого начала до конца. Они должны создать план сборки и процедуры установки в соответствии с требованиями проекта, как они понимаются в настоящий момент. Им следует участвовать в совещаниях по проекту точно так же, как и остальным членам команды.
Из собственного опыта
В NuMega не было выделенных технологов, функции реализации готового продукта выполняла команда. Сначала она состояла из инженера по поддержке и специалиста по инженерной психологии. Что бы вы ни думали, они по совместительству составляли великолепную команду и больше года отлично решали технологические проблемы. Талантливые люди могут брать на себя много задач! Но однажды они позвонили мне из сборочной лаборатории (на самом деле это небольшая комнатка), где боролись со сложной сборкой и сценарием установки. Сообщение было недвусмысленным: «Эд! С нас хватит! Найми технолога!»
В небольших группах отдельный постоянный технолог не нужен. Вместо него эти обязанности могут выполнять другие члены команды по совместительству. Но со временем сложность ПО и размер команды разработчиков возрастают, и потребуются отдельные технологи. А ещё позже — централизованная структура, занимающаяся технологией создания готового продукта. Не надо предполагать, что эта функция не важна или её качество не имеет значения только потому, что в начале её выполнение не потребует работы с постоянной занятостью.
Сборки
Сборка является результатом компиляции всего исходного кода продукта. Для корректного построения вашего ПО, интеграция должна быть обеспечена на самом элементарном уровне — на уровне исходного кода. Целостность исходного кода должна быть совершенной: ошибки компиляции и компоновки недопустимы. В сложных проектах совершенства добиться тяжело из-за массы связей между модулями исходного кода. Однако регулярно собирать свою программу можно и нужно.
Почему они важны
Способность собирать ПО является определяющей для поставки программ в срок. Одна из наиболее часто возникающих проблем при создании ПО — заставить все части работать вместе. Если о ней забыть до окончания проекта, то потом решение проблемы займёт недели или месяцы работы. В худшем случае потребуется переопределение каких-то API и функций. А это, естественно, означает появление никем не запланированных задержек.
Из собственного опыта
Когда я пришёл в NuMega, единственным человеком, способным собрать продукт целиком, был один из талантливейших инженеров — Мэт Питрек. Даже когда команда и продукты ещё были небольшими, среда разработки была чрезвычайно сложной. Только Мэт знал, что делать. Чтобы собрать программу, он уходил в свой кабинет и закрывал дверь. Он как помешанный колдовал над тремя разными компиляторами и дюжиной сценариев, вручную редактировал конфигурационные и другие файлы. Затем, после 3-4 часов интенсивной работы, он взмахивал волшебной палочкой, и обычно у нас появлялась готовая сборка. Мы предполагали, что он не нашёл никаких проблем.
Конечно, новость об успехе всегда радовала, ведь потеря нашего ведущего инженера на полдня всего лишь для завершения сборки лишала нас возможности использовать модель параллельной разработки. Так что нужно было как можно скорее изменить такой порядок вещей.
При регулярном создании сборок разработчики могут проверять интеграцию кода. Интерфейсы API, файлы заголовков, параметры, типы данных и макросы — все должны быть в полностью рабочем состоянии, иначе сборка пройдёт некорректно. Сбой при сборке заставит разработчиков общаться друг с другом и при необходимости изменять программу. Но ведь это именно то, что вам нужно: искать и устранять проблемы на раннем этапе, а не в самом конце, скажем, за день до того, когда от вас требуется бета-версия.
Как их создавать
Далее приведён ряд рекомендаций о том, как сделать задачу создания сборки более простой и эффективной.
Утилита Make
Поддерживает набор правил сборки и отношений в программе для всего приложения или компонента. Описав эти правила, Make может решить, какие образы необходимо собрать и какие исходные файлы должны быть откомпилированы или скомпонованы.
Make существует уже несколько десятилетий, всё началось в UNIX, а затем она появилась практически на всех остальных платформах. В течение многих лет её улучшали, и последняя версия — Nmake — входит в состав Microsoft Visual Studio. Обязательно изучите утилиту Make в вашей среде разработки и используйте её для автоматизации задач сборки ПО.
Номера сборок
Разработчики используют номера для уникальной идентификации сборок. Номер сборки — это монотонно возрастающая целая величина, ни разу не повторяющаяся в истории создания приложения. Номер увеличивается на базовых уровнях, этапах и в каждом последующем выпуске ПО.
Когда сборка приложения происходит просто, в вашей среде разработки и тестирования, вероятно, будет большое число разных сборок.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
Какой бы ни была ваша организация, большой или маленькой, вы должны иметь возможность на регулярной основе собирать и устанавливать ваше ПО. Однако слишком часто команды разработчиков неделями и даже месяцами не могут собрать или установить свою собственную программу. Хуже того, никто из них не отвечает за проблемы со сборкой и процедурой установки, так что эта проблема тормозит процесс разработки. Из-за того, что проект невозможно собрать или установить, могут появиться проблемы любого рода, что вызовет задержки. Если вы не знаете точно реальное состояние вашей программы, потому что не можете увидеть или использовать её, значит, вы действуете вслепую. Чтобы воспользоваться советами, данными в книге, вы должны в обязательном порядке иметь возможность собирать и устанавливать ПО.
Технологи по разработке ПО
Это члены команды, работающей над проектом, которые имеют необходимые навыки работы с процессами и технологиями сборки и установки ПО. Хотя технологи могут выполнять множество обязанностей, в контексте нашего обсуждения выделим наиболее важные:
• определение, создание и сопровождение сборочной среды продукта;
• определение, создание и сопровождение процедуры установки продукта;
• определение, создание и обслуживание пакетов исправлений или сервисных пакетов;
• проведение модульного тестирования и основных мероприятий по контролю качества процедуры установки;
• разработка инструментов, сценариев и автоматизация разработки ПО;
• планирование сборочной среды (сборочной лаборатории).
Для выполнения этих задач технологи должны быть включены в команду, работающую над проектом, с самого начала до конца. Они должны создать план сборки и процедуры установки в соответствии с требованиями проекта, как они понимаются в настоящий момент. Им следует участвовать в совещаниях по проекту точно так же, как и остальным членам команды.
Из собственного опыта
В NuMega не было выделенных технологов, функции реализации готового продукта выполняла команда. Сначала она состояла из инженера по поддержке и специалиста по инженерной психологии. Что бы вы ни думали, они по совместительству составляли великолепную команду и больше года отлично решали технологические проблемы. Талантливые люди могут брать на себя много задач! Но однажды они позвонили мне из сборочной лаборатории (на самом деле это небольшая комнатка), где боролись со сложной сборкой и сценарием установки. Сообщение было недвусмысленным: «Эд! С нас хватит! Найми технолога!»
В небольших группах отдельный постоянный технолог не нужен. Вместо него эти обязанности могут выполнять другие члены команды по совместительству. Но со временем сложность ПО и размер команды разработчиков возрастают, и потребуются отдельные технологи. А ещё позже — централизованная структура, занимающаяся технологией создания готового продукта. Не надо предполагать, что эта функция не важна или её качество не имеет значения только потому, что в начале её выполнение не потребует работы с постоянной занятостью.
Сборки
Сборка является результатом компиляции всего исходного кода продукта. Для корректного построения вашего ПО, интеграция должна быть обеспечена на самом элементарном уровне — на уровне исходного кода. Целостность исходного кода должна быть совершенной: ошибки компиляции и компоновки недопустимы. В сложных проектах совершенства добиться тяжело из-за массы связей между модулями исходного кода. Однако регулярно собирать свою программу можно и нужно.
Почему они важны
Способность собирать ПО является определяющей для поставки программ в срок. Одна из наиболее часто возникающих проблем при создании ПО — заставить все части работать вместе. Если о ней забыть до окончания проекта, то потом решение проблемы займёт недели или месяцы работы. В худшем случае потребуется переопределение каких-то API и функций. А это, естественно, означает появление никем не запланированных задержек.
Из собственного опыта
Когда я пришёл в NuMega, единственным человеком, способным собрать продукт целиком, был один из талантливейших инженеров — Мэт Питрек. Даже когда команда и продукты ещё были небольшими, среда разработки была чрезвычайно сложной. Только Мэт знал, что делать. Чтобы собрать программу, он уходил в свой кабинет и закрывал дверь. Он как помешанный колдовал над тремя разными компиляторами и дюжиной сценариев, вручную редактировал конфигурационные и другие файлы. Затем, после 3-4 часов интенсивной работы, он взмахивал волшебной палочкой, и обычно у нас появлялась готовая сборка. Мы предполагали, что он не нашёл никаких проблем.
Конечно, новость об успехе всегда радовала, ведь потеря нашего ведущего инженера на полдня всего лишь для завершения сборки лишала нас возможности использовать модель параллельной разработки. Так что нужно было как можно скорее изменить такой порядок вещей.
При регулярном создании сборок разработчики могут проверять интеграцию кода. Интерфейсы API, файлы заголовков, параметры, типы данных и макросы — все должны быть в полностью рабочем состоянии, иначе сборка пройдёт некорректно. Сбой при сборке заставит разработчиков общаться друг с другом и при необходимости изменять программу. Но ведь это именно то, что вам нужно: искать и устранять проблемы на раннем этапе, а не в самом конце, скажем, за день до того, когда от вас требуется бета-версия.
Как их создавать
Далее приведён ряд рекомендаций о том, как сделать задачу создания сборки более простой и эффективной.
Утилита Make
Поддерживает набор правил сборки и отношений в программе для всего приложения или компонента. Описав эти правила, Make может решить, какие образы необходимо собрать и какие исходные файлы должны быть откомпилированы или скомпонованы.
Make существует уже несколько десятилетий, всё началось в UNIX, а затем она появилась практически на всех остальных платформах. В течение многих лет её улучшали, и последняя версия — Nmake — входит в состав Microsoft Visual Studio. Обязательно изучите утилиту Make в вашей среде разработки и используйте её для автоматизации задач сборки ПО.
Номера сборок
Разработчики используют номера для уникальной идентификации сборок. Номер сборки — это монотонно возрастающая целая величина, ни разу не повторяющаяся в истории создания приложения. Номер увеличивается на базовых уровнях, этапах и в каждом последующем выпуске ПО.
Когда сборка приложения происходит просто, в вашей среде разработки и тестирования, вероятно, будет большое число разных сборок.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73