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

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

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

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

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

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

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

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

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

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

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

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

Джереми Мейер (Jeremy Meyer) занимается проектированием и разработкой программного обеспечения, а также преподаванием в течение почти 20 лет. В настоящее время он является ведущим консультантом Borland Software в области моделирования и проектирования.