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

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

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

Тимоти Хай (Timothy High) — архитектор программного обеспечения, у которого за плечами более чем 15-летний опыт разработки с использованием веб-технологий, создания, многоуровневых клиент-серверных систем и применения, технологий интеграции приложений. В настоящее время, работает архитектором программного обеспечения в компании Sakonnet Technologies, которая является лидером в области создания программ для управления сделками и рисками в сфере энергетики (ETRM — Energy Trading and Risk Management).

Записывайте свои обоснования

Тимоти Хай

В сообществе разработчиков существует немало разногласий по поводу ценности документации, особенно в том, что касается архитектуры программного продукта. Разногласия эти обычно связаны с субъективными взглядами на ценность «тщательного предварительного проектирования» и теми сложностями, которые возникают при постоянном обновлении проектной документации в соответствии с изменениями в базе кода.

Одна из разновидностей документации, которая почти не устаревает, не требует особых усилий по подготовке и почти всегда окупается, — запись обоснований, стоящих за теми или иными архитектурными решениями. Как объясняет Марк Ричардс в этюде «Архитектурные компромиссы», создание архитектуры программного продукта по сути сводится к поиску разумных компромиссов между различными характеристиками качества, затратами, временем и другими факторами. Вам, руководству, разработчикам и другим заинтересованным в проекте сторонам должно быть абсолютно ясно, почему одному решению отдано предпочтение перед другим и к каким компромиссам это привело. (Вы пожертвовали горизонтальной масштабируемостью ради сокращения затрат на оборудование и лицензии? Проблемы безопасности настолько серьезны, что оправдывают увеличение времени отклика ради шифрования данных?)

Формат такой документации зависит от специфики проекта и может варьироваться от кратких заметок в текстовом документе, вики или блоге до формальных шаблонов, отражающих все аспекты каждого архитектурного решения. Независимо от вида и формата этот документ должен отвечать на следующие основные вопросы: «В чем суть принятого решения?» и «Почему мы приняли такое решение?». Еще один частый вопрос, ответ на который следует там отразить: «Какие альтернативные решения рассматривались и почему они были отвергнуты?» (на самом деле чаще спрашивают: «Почему не сделали так, как предлагал я?»). Документация должна предусматривать возможность поиска, чтобы при необходимости можно было легко найти требуемую информацию.

Такая документация может быть полезна во многих ситуациях:

• Чтобы проинформировать разработчиков о важных архитектурных принципах, которые должны соблюдаться в работе.

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

• Чтобы продемонстрировать руководству и заинтересованным сторонам те причины, в силу которых программный продукт строится именно так, а не иначе (например, почему необходимо какое-нибудь дорогостоящее оборудование или программный компонент).

• Чтобы передать проект новому архитектору (сколько раз, получая в наследство программный продукт, вы пытались понять, почему архитекторы поступили именно ТАК?).

Однако самые важные преимущества этой практики состоят в следующем: