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

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

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

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

Эрик Готорн (Eric Hawthorne) профессионально занимается созданием архитектуры, проектированием и разработкой объектно-ориентированных программ и распределенных систем с 1998 года. Первые 10 лет его карьеры прошли в Macdonald Dettwiler — канадской системотехнической компании, где среди прочего он имел возможность поучиться архитектурным тонкостям у самого Филиппа Крачтена (Philippe Kruchten).

Подготовьте убедительное экономическое обоснование

И Чжоу

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

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

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

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

2. Предложите количественные метрики. Польза от предлагаемых вами решений должна быть измеримой (до разумной степени). Чем больше количественных показателей вы предъявите, тем убедительнее сможете обосновать свое утверждение о том, что предлагаемая архитектура обеспечит существенную отдачу. Чем раньше будут заданы метрики, тем проще вам будет управлять восприятием заинтересованных сторон — а это поможет вам убедить их в преимуществах своей архитектуры.

3. Увяжите свои данные с традиционными бизнес-метриками. Будет превосходно, если вы сумеете напрямую представить результаты технического анализа в денежном выражении. В конце концов, единственным неизменным параметром в традиционных бизнес-метриках являются деньги. Если вы недостаточно хорошо разбираетесь в финансовых тонкостях, возьмите себе в помощники бизнес-аналитика.

4. Знайте, где остановиться. Для этого необходимо подготовить план, в котором будут отражены ваши представления обо всех ключевых этапах работ и о том, какую ценность для бизнеса представляет каждый из них. Пусть заинтересованные стороны проекта сами решат, где следует остановиться. Если ценность каждого этапа для бизнеса будет значительной, вам, скорее всего, удастся добиться финансирования в полном объеме.

5. Выберите подходящий момент. Даже если вы выполните четыре предыдущих рекомендации и подготовите хорошее экономическое обоснование, ваша идея может провалиться из-за неудачного выбора момента ее подачи. Помню, одно из моих предложений долгое время не получало поддержки — до тех пор, пока другой проект не завершился полным крахом из-за плохой архитектуры. Разумно подходите к выбору момента.

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

Управляйте не только кодом, но и данными

ЧедЛавинь

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

1. Вы создаете список сценариев, которые необходимо выполнить в заданном порядке.

2. Вы отправляете сценарии конкретному администратору базы данных по электронной почте.

3. Администратор копирует сценарии в каталог, из которого они должны запускаться заданием cron.

4. Вы проверяете журнал выполнения сценариев и молитесь, чтобы все сценарии выполнились успешно, потому что не знаете точно, что произойдет при их повторном выполнении.

5. Вы запускаете сценарии проверки и осуществляете выборочную проверку данных.

6. Вы проводите регрессионное тестирование приложения и смотрите, что перестало работать.

7. Вы пишете сценарии для вставки отсутствующих данных и исправления ошибок.

8. Вы повторяете шаги с 1 по 7.

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

Сложная, запутанная процедура открывает много возможностей для сбоев. Ситуация усугубляется тем, что ошибки, вызванные изменениями схем или данных, не всегда обнаруживаются модульными тестами, которые являются частью ночной сборки. Эти ошибки любят заявлять о себе громко и эффектно сразу же после миграции. Решения проблем в базах данных сложнее проверить на правильность, а ручной «откат» базы данных — операция весьма трудоемкая. Ценность полностью автоматизированного процесса сборки, способного вернуть базу данных в известное состояние, становится особенно очевидной, когда вы используете его для исправления очень явных ошибок. Если вы не