Джон Дэвис (John Davies) в настоящее время является ведущим архитектором в фирме Revolution Money (США). Недавно основал новую компанию Incept5.
Обеспечьте непрерывную интеграциюДэвид Бартлетт
Сборка давно перестала играть роль «Большого взрыва» в разработке проектов. И архитекторы (как уровня приложения, так и корпоративного уровня) должны поощрять использование методов и инструментов непрерывной интеграции в каждом проекте.
Термин непрерывная интеграция (CI, Continuous Integration) впервые был предложен Мартином Фаулером в качестве шаблона проектирования. Он означает совокупность методов и инструментов, обеспечивающих регулярную автоматическую сборку и тестирование приложения через короткие промежутки времени (как правило, на интеграционном сервере, специально созданном для выполнения этих операций). Для любого современного программного проекта практика непрерывной интеграции, комбинирующая методы и инструменты модульного тестирования с инструментами автоматизированной сборки, становится обязательной.
Непрерывная интеграция воздействует на неотъемлемый элемент процесса разработки ПО — точку преобразования исходного кода в работающее приложение. В этой точке происходит объединение и тестирование составных частей проекта. Вам, вероятно, доводилось слышать принцип «Выполняйте сборку рано и часто» («Build early and often»); когда-то этот принцип служил методом снижения рисков, избавляя от неприятных сюрпризов в процессе разработки. В наши дни на смену «ранней и частой сборке» пришла непрерывная интеграция, которая также включает в себя сборку, но добавляет к ней возможности, улучшающие взаимодействие в команде разработчиков и повышающие ее координацию.
Самой известной частью практики непрерывной интеграции является сборка, которая обычно автоматизирована. Возможность ручной сборки остается, но можно автоматически запускать сборку каждую ночь или при внесении изменений в исходный код. При запуске процесса сборки из репозитория извлекается последняя версия исходного кода; инструмент непрерывной интеграции пытается собрать проект и затем протестировать его. Процесс завершается рассылкой уведомлений с описанием результатов. Уведомления могут рассылаться в разных форматах, в том числе по электронной почте или через системы обмена мгновенными сообщениями.
Непрерывная интеграция делает процесс разработки более стабильным и целенаправленным. Несомненно, вам как архитектору это придется по душе, но еще важнее другое: непрерывная интеграция повысит эффективность вашей компании и команд разработки.
Дэйв Бартлетт (Dave Bartlett) — увлеченный своим делом профессионал. За 25 с лишним лет он успел побывать программистом, разработчиком, архитектором, руководителем, консультантом и преподавателем. В настоящее время он выполняет работы для клиентов Commotion Technologies, Inc. (частная консалтинговая компания), а также читает лекции в Высшей технической школе Пенсильванского университета. Его основные текущие проекты связаны с Федеральным резервным банком в Филадельфии, которому он помогает проектировать и создавать веб-приложения, порталы и комплексные приложения для взаимодействия с Федеральной резервной системой и Казначейством США.
Старайтесь не нарушать графикНорман Карновейл
Программный проект может потерпеть неудачу по многим причинам. Одним из самых распространенных источников провала проекта является изменение графика работ в ходе выполнения проекта без надлежащего планирования. Таких неудач можно избежать, но это требует значительных усилий со стороны множества людей. Корректировка временной шкалы или добавление в проект ресурсов обычно особых проблем не создает. Проблемы начинаются тогда, когда от вас требуют выполнить больший объем работы за тот же срок или сокращают график без снижения нагрузки.
Идея о том, что путем сокращения графика можно снизить расходы или ускорить сдачу продукта, является очень распространенным заблуждением. Обычно для более быстрой сдачи продукта или для расширения функциональности без изменения срока сдачи прибегают к сверхурочной работе или жертвуют «менее важными задачами» (такими как модульное тестирование). Избегайте такого сценария любой ценой. Напомните тем, кто требует от вас подобных мер, следующие факты:
• Сокращение сроков проектирования приводит к некачественному дизайну и плохой документации, а также повышает вероятность проблем с контролем качества и риск того, что система не будет принята пользователем.
• Сокращение сроков кодирования или сдачи напрямую связано с количеством ошибок в конечном продукте.
• Сокращение сроков тестирования ведет к появлению плохо протестированного кода и напрямую связано с количеством проблем при тестировании.
• Все перечисленное влечет за собой проблемы на этапе эксплуатации, а устранение таких проблем обходится намного дороже.
В конечном итоге затраты не только не уменьшаются, но увеличиваются. Обычно именно здесь и кроется причина провала.
Вы как архитектор рано или поздно попадете в ситуацию, когда шансы на успех определяются тем, насколько быстро вы действуете. Выскажите свое мнение как можно раньше. Сначала попытайтесь обеспечить качество, сохранив изначально запланированный график. Если без сокращения графика не обойтись, попробуйте переместить некритичную функциональность в будущие версии. Разумеется, для этого потребуются хорошая подготовка, навыки ведения переговоров и умение убеждать в своей правоте. Начните оттачивать свое мастерство в этих областях прямо сегодня. Поверьте: вы об этом не пожалеете.
Норман Карновейл (Norman Carnovale) — IT-архитектор проектов, связанных с национальной безопасностью, выполняющий работу для Lockheed Martin Professional Services. Ранее работал консультантом в области программного обеспечения, преподавателем и архитектором в компании Davalen, LLC (http://www.davalen.com), которая является ведущим бизнес-партнером IBM и специализируется на проектах WebSphere Portlet Factory, WebSphere Portal и Lotus Domino.
Архитектурные компромиссыМарк Ричардс
Каждый архитектор программного обеспечения должен знать и понимать, что нельзя получить все сразу. На практике невозможно спроектировать архитектуру, одновременно обладающую высокой производительностью, высокой доступностью, высоким уровнем безопасности и высоким уровнем абстракции. Существует одна реальная история, которую архитекторы программного обеспечения должны знать, понимать и рассказывать своим клиентам и коллегам. Я имею в виду историю корабля «Ваза».
В 1620 году шла война между Швецией и Польшей. Желая побыстрее завершить эту дорогостоящую войну, король Швеции приказал построить галеон, который назывался «Ваза». Это был необычный корабль. Требования к нему были не похожи на требования к любому другому кораблю того времени. Он должен был иметь длину более 60 метров, нести 64 пушки на двух батарейных палубах, а также брать на борт 300 солдат за раз для безопасной доставки в Польшу по морю. Время поджимало, денег не хватало (звучит знакомо, да?). Занимавшийся этим судном кораблестроитель еще никогда не проектировал такие корабли. Он специализировался на меньших, однопалубных судах. Тем не менее он взялся за проектирование и постройку «Вазы», полагаясь на свой прежний опыт. В итоге корабль, соответствующий этим спецификациям, был построен. Наступил день спуска на воду. Корабль гордо выплыл в гавань, отсалютовал из всех пушек… и вслед за тем затонул.
Проблема «Вазы» была очевидной; каждый, кто хоть раз видел палубу большого боевого корабля XVII века, знает, что палубы таких кораблей были переполнены и небезопасны, особенно во время сражения. Постройка корабля, который служил бы одновременно боевым и транспортным, было дорогостоящей ошибкой. Кораблестроитель, стремясь выполнить все пожелания короля, создал неустойчивое и плохо сбалансированное судно.
Архитектор ПО может почерпнуть из этой истории много полезного и учесть этот печальный опыт при проектировании архитектуры программных продуктов. Попытка выполнить все требования сразу (как в случае с «Вазой») создает неустойчивую архитектуру, которая не решает толком ни одну из поставленных задач. Хороший пример такого рода — требование заставить сервис-ориентированную архитектуру (SOA, service-oriented architecture) заодно функционировать в качестве решения «точка-точка». Обычно это вынуждает обходить различные уровни абстракции, создаваемые подходом SOA, и в результате возникает архитектура, напоминающая блюдо спагетти из итальянского ресторана. В распоряжении архитектора имеется несколько инструментов для определения тех компромиссов, на которые приходится идти при проектировании архитектур. Два популярных метода такого рода — АТАМ (Architecture Tradeoff Analysis Method) и CBAM (Cost Benefit Analysis Method). Дополнительную информацию об АТАМ и СВАМ можно найти на сайте SEI (Software Engineering Institute).
Биография автора приведена ранее.
База данных как КрепостьДэн Чак
В базе данных хранится вся информация — как вводимая сотрудниками, так и полученная от клиентов. Пользовательские интерфейсы, бизнес-логика и прикладная логика (и даже сотрудники) приходят и уходят, а данные остаются. Трудно выразить словами то, насколько важно в первые же дни работы над проектом построить надежную модель данных.
Огромная популярность методологий гибкой разработки привела многих к мысли, что приложения можно (и даже предпочтительно!) проектировать по ходу работы. Эпоха предварительного написания сложных, исчерпывающих технических спецификаций ушла навсегда! Новая школа призывает поставлять продукт рано и часто. Одна строка эксплуатируемого кода полезнее 10 строк у вас в голове. Звучит слишком хорошо, чтобы быть правдой… во всяком случае в том, что касается данных.