97 этюдов для архитекторов программных систем

Сборка давно перестала играть роль «Большого взрыва» в разработке проектов. И архитекторы (как уровня приложения, так и корпоративного уровня) должны поощрять использование методов и инструментов непрерывной интеграции в каждом проекте.

Термин непрерывная интеграция (CI, Continuous Integration) впервые был предложен Мартином Фаулером в качестве шаблона проектирования. Он означает совокупность методов и инструментов, обеспечивающих регулярную автоматическую сборку и тестирование приложения через короткие промежутки времени (как правило, на интеграционном сервере, специально созданном для выполнения этих операций). Для любого современного программного проекта практика непрерывной интеграции, комбинирующая методы и инструменты модульного тестирования с инструментами автоматизированной сборки, становится обязательной.

Непрерывная интеграция воздействует на неотъемлемый элемент процесса разработки ПО — точку преобразования исходного кода в работающее приложение. В этой точке происходит объединение и тестирование составных частей проекта. Вам, вероятно, доводилось слышать принцип «Выполняйте сборку рано и часто» («Build early and often»); когда-то этот принцип служил методом снижения рисков, избавляя от неприятных сюрпризов в процессе разработки. В наши дни на смену «ранней и частой сборке» пришла непрерывная интеграция, которая также включает в себя сборку, но добавляет к ней возможности, улучшающие взаимодействие в команде разработчиков и повышающие ее координацию.

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

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

Дэйв Бартлетт (Dave Bartlett) — увлеченный своим делом профессионал. За 25 с лишним лет он успел побывать программистом, разработчиком, архитектором, руководителем, консультантом и преподавателем. В настоящее время он выполняет работы для клиентов Commotion Technologies, Inc. (частная консалтинговая компания), а также читает лекции в Высшей технической школе Пенсильванского университета. Его основные текущие проекты связаны с Федеральным резервным банком в Филадельфии, которому он помогает проектировать и создавать веб-приложения, порталы и комплексные приложения для взаимодействия с Федеральной резервной системой и Казначейством США.

Старайтесь не нарушать график Норман Карновейл

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

Идея о том, что путем сокращения графика можно снизить расходы или ускорить сдачу продукта, является очень распространенным заблуждением. Обычно для более быстрой сдачи продукта или для расширения функциональности без изменения срока сдачи прибегают к сверхурочной работе или жертвуют «менее важными задачами» (такими как модульное тестирование). Избегайте такого сценария любой ценой. Напомните тем, кто требует от вас подобных мер, следующие факты:

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