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

Проследите за тем, чтобы разработчики обладали необходимыми навыками. Если разработчикам необходимо обучение, позаботьтесь о том, чтобы они могли его пройти. Покупайте книги и поощряйте активные обсуждения технологий. Трудовая жизнь разработчика должна быть занята практической деятельностью, но это не должно мешать активному повышению квалификации. Если вы располагаете достаточными средствами, отправляйте свою команду на технические презентации и конференции. Если нет — подключите команду к техническим спискам рассылки и следите за бесплатными мероприятиями в своем городе. По возможности участвуйте также в процессе отбора разработчиков. Ищите тех, кто жаждет учиться, у кого есть «искра» технической одаренности (но убедитесь в том, что они способны работать в команде…). Трудно добиться чего-то выдающегося от группы безликих работяг.

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

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

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

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

Тимоти Хай

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

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

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

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

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

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

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

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

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

• Она заставляет вас явным образом формулировать свои доводы, проверяя их надежность (см. следующий этюд «Сомневайтесь в допущениях — особенно в собственных»).

• Она дает отправную точку для переоценки решений в случае изменения условий, от которых эти решения зависят.

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

Биография автора приведена ранее.

Сомневайтесь в допущениях — особенно в собственных

Тимоти Хай

Закон отложенных решений Уэзерна гласит: «Допущения — корень всех провалов». Конечно, формулировка не очень серьезная, но когда предположения обходятся вам в несколько тысяч (а то и миллионов) долларов, становится не до смеха.

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

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

• «Продукты с открытым исходным кодом ненадежны».

• «От индексов на основе битовых карт больше хлопот, чем пользы».

• «Заказчик никогда не примет страницу, которая грузится по пять секунд».

• «IT-директор согласится покупать продукты только у крупных вендоров».

Очень важно, чтобы такие допущения формулировались явно и четко (ради тех, кто придет нам