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

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

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

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

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

• Увидеть свои «слепые пятна» трудно по определению. Люди, от которых вы готовы услышать неприятную правду, когда она вам нужна, — ваш драгоценный ресурс.

Дэйв Куик (Dave Quick) — владелец, главный архитектор, уборщик и единственный работник Thoughtful Arts. Эта фирма разрабатывает программы для музыкантов и предоставляет консультации в области проектирования ПО компаниям, выпускающим программные продукты для создания музыки или произведений изобразительного искусства.

Повторное использование зависит не только от архитектуры Джереми Мейер

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

…знают об их существовании

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

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

…умеют ими пользоваться

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

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

…считают, что это лучше, чем сделать заново самим