Помоги проекту - поделись книгой:
Прежде чем браться за проект по разработке программного продукта, коммерческая компания обычно планирует и озвучивает желаемый показатель окупаемости инвестиций (ROI — Return on Investment). Архитектор должен принять этот показатель и вытекающие из него ограничения ценности создаваемого продукта для компании. Это поможет избежать таких технических решений, которые способны привести к перерасходу средств. Показатель окупаемости должен служить важным компонентом целевого контекста как при общении с руководством (в ходе поиска компромисса между ценностью той или иной функции и затратами на ее реализацию), так и при обсуждении технической архитектуры и реализации с командой разработчиков. В частности, перед командой разработки архитектор должен представлять интересы бизнеса, не соглашаясь на выбор технологии с неприемлемо высокими стоимостью лицензии и затратами на поддержку в фазе тестирования или реальной эксплуатации продукта.
Одна из сложных задач, возникающих, когда всем заправляет бизнес, — предоставлять достаточный объем сведений качественного характера о том, как движется разработка продукта, чтобы бизнес-руководство могло принимать обоснованные деловые решения. Здесь важнейшую роль играет прозрачность. Архитектор вместе с руководством проекта должен создать и усовершенствовать средства получения регулярной, оперативной обратной связи. Этой цели можно достичь, применяя различные приемы бережливой разработки ПО (lean software development): большие, заметные диаграммы, непрерывная интеграция, частые выпуски рабочих версий продукта и их передача бизнес-руководству уже на самых ранних стадиях проекта.
Разработка программного обеспечения в существенной степени представляет собой деятельность по проектированию, что подразумевает наличие непрерывного процесса принятия решений вплоть до того момента, когда готовая система запускается в эксплуатацию. Для разработчиков совершенно естественно принимать много решений, но эти решения обычно не относятся к деловой стороне вопроса. Однако в той степени, в которой бизнес-руководство пренебрегает своими обязанностями, не задавая команде разработчиков направление работы, не отвечая на их вопросы и не принимая бизнес-решений, оно фактически передает принятие деловых решений самим разработчикам. Для текущих микрорешений, принимаемых разработчиками, архитектор должен предоставить макроконтекст, донося информацию о программной архитектуре и бизнес-целях и защищая их. Он должен также добиваться того, чтобы разработчики не принимали бизнес-решений. Принятие технических решений в отрыве от обязательств, ожиданий и реалий бизнеса (которые должны регулярно озвучиваться деловой стороной в процессе работы над проектом) сводится к умозрительным догадкам и часто приводит к неоправданным затратам дефицитных ресурсов.
В долгосрочной перспективе интересы команды разработки лучше всего соблюдаются тогда, когда у руля стоит бизнес.
Простота лучше универсальности
Типичная проблема многих компонентных инфраструктур (framework), библиотек классов, базовых сервисов и прочего инфраструктурного кода заключается в том, что они проектируются с расчетом на универсальное применение, без привязки к конкретным приложениям. В результате мы получаем ошеломляющий набор возможностей и настроек, которые часто не используются вообще или используются не по назначению, а то и попросту оказываются бесполезными. Большинство разработчиков работает над конкретными системами, и стремление к неограниченной универсальности редко способно сослужить им хорошую службу. Лучший путь к универсальности пролегает через глубокое понимание известных конкретных примеров и анализ их сути с целью поиска фундаментального общего решения: простота как результат практического опыта, а не универсальность, опирающаяся на умозрительные догадки.
Приоритет простоты перед универсальностью помогает сделать выбор между двумя архитектурными альтернативами, равнозначными в остальных отношениях. Когда возможны два решения, отдавайте предпочтение более простому и ориентированному на конкретную потребность, а не более изощренному и претендующему на универсальность. Конечно, вполне может случиться (и не так уж редко случается), что более простое решение на практике окажется и более универсальным. Но, даже если этого не произойдет, легче изменить простое решение, когда вы хорошо представляете, что же вам требуется, нежели нужным образом адаптировать «универсальное» решение, которое, как назло, оказалось недостаточно универсальным.
Несмотря на благие намерения архитектора, многие решения, задуманные для универсального применения, в конечном итоге оказываются не пригодными ни для чего конкретного. Программные компоненты в первую очередь должны проектироваться для определенной задачи, и они должны хорошо справляться с этой задачей. Эффективная универсальность рождается из понимания, а понимание ведет к упрощению.
Обобщение иногда позволяет привести задачу к более фундаментальному виду; в созданном решении воплощаются закономерности нескольких известных примеров — четкие, компактные и хорошо обоснованные. Однако чрезмерное обобщение само превращается в задачу, которая ведет в противоположном направлении и повышает сложность, вместо того чтобы сокращать ее. Стремление к абстрактным обобщениям часто порождает решения, не привязанные к реалиям фактической разработки. Такие обобщения опираются на предположения, которые позднее оказываются неверными, предлагают варианты выбора, которые позже оказываются невостребованными, и создают балласт, который потом трудно или невозможно удалить. В конечном итоге это лишь повышает второстепенную сложность, с которой придется столкнуться будущим разработчикам и архитекторам.
Многие архитекторы высоко ценят универсальность, но такое отношение не должно быть безусловным. Как правило, люди не готовы платить за универсальность (или не нуждаются в ней): перед ними обычно стоит совершенно конкретная задача, и они ценят конкретное решение этой задачи. Универсальность и гибкость могут проявиться при создании конкретных решений, но если при этом мы слишком быстро снимемся с якоря и забудем о конкретике, то начнем дрейфовать в море безграничных возможностей — море, полном хитроумных настроек, громоздких (не просто обширных) списков параметров, бескрайних интерфейсов и неправомерных абстракций. В стремлении к абстрактной гибкости часто (случайно или намеренно) утрачиваются ценные свойства альтернативных, более простых решений.
Архитектор должен быть практиком
Хороший архитектор должен подавать личный пример другим. Он должен быть способен заменить любого члена своей команды и выполнить любую работу — от прокладки сети и настройки процесса сборки до написания модульных тестов и выполнения тестов производительности. Без хорошего понимания всего диапазона технологий архитектор мало чем отличается от обычного руководителя проекта. Члены команды могут обладать более глубокими знаниями в своих узких областях — это совершенно нормально, — но вряд ли они смогут доверять своему архитектору, если тот не разбирается в используемых технологиях. Как уже было сказано, архитектор — это интерфейс между технической командой и бизнесом, а значит, он должен понимать все технические аспекты, чтобы играть роль представителя команды перед бизнес-руководством, не обращаясь постоянно за помощью. Из тех же соображений архитектор должен понимать деловые аспекты организации, чтобы успешно привести разработчиков к цели — удовлетворению коммерческих интересов компании.
Работа архитектора сродни работе пилота самолета: он может не выглядеть занятым, но в действительности использует десятилетия накопленного опыта для постоянного наблюдения за ситуацией и немедленно вмешивается при возникновении нештатной ситуации. Руководитель проекта (второй пилот) обеспечивает повседневное управление, избавляя архитектора от рутины и управления персоналом. В конечном итоге архитектор должен отвечать за качество продукта и его своевременную сдачу. Эти задачи трудно решить без личного авторитета, который играет чрезвычайно важную роль в успехе любого проекта.
Лучший способ обучаться — наблюдать за другими; именно так мы учимся в детстве. Хороший архитектор должен уметь выявить проблему, собрать команду и, не занимаясь поисками виновных, объяснить суть проблемы, а затем предложить элегантное решение или обходной путь. При этом архитектор может попросить у команды помощи, нисколько не теряя авторитета. Разработчики должны ощущать свой вклад в решение задачи, но архитектор при этом направляет ход обсуждения и определяет правильный подход. Архитекторам следует присоединяться к команде уже на самых ранних стадиях проекта; они должны не сидеть в башне из слоновой кости, указывая оттуда путь вперед, а работать «в поле» вместе со всеми остальными. Вопросы выбора стратегического направления или технологии не следует превращать в самостоятельные исследования или новые проекты — к ним надо подходить прагматически, разыскивая ответ в ходе практической работы или обращаясь за советом к коллегам-архитекторам (все хорошие архитекторы знают друг друга).
Хороший архитектор обязан на уровне эксперта владеть как минимум одним из инструментов своей профессии, например интегрированной средой разработки (IDE); помните, что архитектор должен быть практиком. Вполне логично, что архитектору ПО следует хорошо знать IDE, архитектору баз данных — инструментарий построения диаграмм «сущность-связь» (ER-диаграмм), а информационному архитектору — инструменты XML-моделирования. Однако ведущий архитектор обязан уметь применять инструменты всех уровней, от контроля сетевого трафика с использованием Wireshark до моделирования сложных финансовых сообщений в XMLSpy, — для него не существует слишком низких или слишком высоких уровней.
Как правило, архитектор приходит с хорошим резюме и впечатляющим прошлым. Этим обычно несложно произвести впечатление на руководство и технический персонал, но без демонстрации своих умений на практике он вряд ли сумеет завоевать уважение команды. В такой ситуации команда будет испытывать трудности с обучением, а ее члены вряд ли смогут справиться с той задачей, для решения которой их наняли.
Обеспечьте непрерывную интеграцию
Сборка давно перестала играть роль «Большого взрыва» в разработке проектов. И архитекторы (как уровня приложения, так и корпоративного уровня) должны поощрять использование методов и инструментов непрерывной интеграции в каждом проекте.
Термин
Непрерывная интеграция воздействует на неотъемлемый элемент процесса разработки ПО — точку преобразования исходного кода в работающее приложение. В этой точке происходит объединение и тестирование составных частей проекта. Вам, вероятно, доводилось слышать принцип «Выполняйте сборку рано и часто» («Build early and often»); когда-то этот принцип служил методом снижения рисков, избавляя от неприятных сюрпризов в процессе разработки. В наши дни на смену «ранней и частой сборке» пришла непрерывная интеграция, которая также включает в себя сборку, но добавляет к ней возможности, улучшающие взаимодействие в команде разработчиков и повышающие ее координацию.
Самой известной частью практики непрерывной интеграции является сборка, которая обычно автоматизирована. Возможность ручной сборки остается, но можно автоматически запускать сборку каждую ночь или при внесении изменений в исходный код. При запуске процесса сборки из репозитория извлекается последняя версия исходного кода; инструмент непрерывной интеграции пытается собрать проект и затем протестировать его. Процесс завершается рассылкой уведомлений с описанием результатов. Уведомления могут рассылаться в разных форматах, в том числе по электронной почте или через системы обмена мгновенными сообщениями.
Непрерывная интеграция делает процесс разработки более стабильным и целенаправленным. Несомненно, вам как архитектору это придется по душе, но еще важнее другое: непрерывная интеграция повысит эффективность вашей компании и команд разработки.
Старайтесь не нарушать график
Программный проект может потерпеть неудачу по многим причинам. Одним из самых распространенных источников провала проекта является изменение графика работ в ходе выполнения проекта без надлежащего планирования. Таких неудач можно избежать, но это требует значительных усилий со стороны множества людей. Корректировка временной шкалы или добавление в проект ресурсов обычно особых проблем не создает. Проблемы начинаются тогда, когда от вас требуют выполнить больший объем работы за тот же срок или сокращают график без снижения нагрузки.
Идея о том, что путем сокращения графика можно снизить расходы или ускорить сдачу продукта, является очень распространенным заблуждением. Обычно для более быстрой сдачи продукта или для расширения функциональности без изменения срока сдачи прибегают к сверхурочной работе или жертвуют «менее важными задачами» (такими как модульное тестирование). Избегайте такого сценария любой ценой. Напомните тем, кто требует от вас подобных мер, следующие факты:
• Сокращение сроков проектирования приводит к некачественному дизайну и плохой документации, а также повышает вероятность проблем с контролем качества и риск того, что система не будет принята пользователем.
• Сокращение сроков кодирования или сдачи напрямую связано с количеством ошибок в конечном продукте.
• Сокращение сроков тестирования ведет к появлению плохо протестированного кода и напрямую связано с количеством проблем при тестировании.
• Все перечисленное влечет за собой проблемы на этапе эксплуатации, а устранение таких проблем обходится намного дороже.
В конечном итоге затраты не только не уменьшаются, но увеличиваются. Обычно именно здесь и кроется причина провала.
Вы как архитектор рано или поздно попадете в ситуацию, когда шансы на успех определяются тем, насколько быстро вы действуете. Выскажите свое мнение как можно раньше. Сначала попытайтесь обеспечить качество, сохранив изначально запланированный график. Если без сокращения графика не обойтись, попробуйте переместить некритичную функциональность в будущие версии. Разумеется, для этого потребуются хорошая подготовка, навыки ведения переговоров и умение убеждать в своей правоте. Начните оттачивать свое мастерство в этих областях прямо сегодня. Поверьте: вы об этом не пожалеете.
Архитектурные компромиссы
Каждый архитектор программного обеспечения должен знать и понимать, что нельзя получить все сразу. На практике невозможно спроектировать архитектуру, одновременно обладающую высокой производительностью, высокой доступностью, высоким уровнем безопасности и высоким уровнем абстракции. Существует одна реальная история, которую архитекторы программного обеспечения должны знать, понимать и рассказывать своим клиентам и коллегам. Я имею в виду историю корабля «Ваза».
В 1620 году шла война между Швецией и Польшей. Желая побыстрее завершить эту дорогостоящую войну, король Швеции приказал построить галеон, который назывался «Ваза». Это был необычный корабль. Требования к нему были не похожи на требования к любому другому кораблю того времени. Он должен был иметь длину более 60 метров, нести 64 пушки на двух батарейных палубах, а также брать на борт 300 солдат за раз для безопасной доставки в Польшу по морю. Время поджимало, денег не хватало (звучит знакомо, да?). Занимавшийся этим судном кораблестроитель еще никогда не проектировал такие корабли. Он специализировался на меньших, однопалубных судах. Тем не менее он взялся за проектирование и постройку «Вазы», полагаясь на свой прежний опыт. В итоге корабль, соответствующий этим спецификациям, был построен. Наступил день спуска на воду. Корабль гордо выплыл в гавань, отсалютовал из всех пушек… и вслед за тем затонул.
Проблема «Вазы» была очевидной; каждый, кто хоть раз видел палубу большого боевого корабля XVII века, знает, что палубы таких кораблей были переполнены и небезопасны, особенно во время сражения. Постройка корабля, который служил бы одновременно боевым и транспортным, было дорогостоящей ошибкой. Кораблестроитель, стремясь выполнить все пожелания короля, создал неустойчивое и плохо сбалансированное судно.
Архитектор ПО может почерпнуть из этой истории много полезного и учесть этот печальный опыт при проектировании архитектуры программных продуктов. Попытка выполнить все требования сразу (как в случае с «Вазой») создает неустойчивую архитектуру, которая не решает толком ни одну из поставленных задач. Хороший пример такого рода — требование заставить сервис-ориентированную архитектуру (SOA, service-oriented architecture) заодно функционировать в качестве решения «точка-точка». Обычно это вынуждает обходить различные уровни абстракции, создаваемые подходом SOA, и в результате возникает архитектура, напоминающая блюдо спагетти из итальянского ресторана. В распоряжении архитектора имеется несколько инструментов для определения тех компромиссов, на которые приходится идти при проектировании архитектур. Два популярных метода такого рода — АТАМ (Architecture Tradeoff Analysis Method) и CBAM (Cost Benefit Analysis Method). Дополнительную информацию об АТАМ и СВАМ можно найти на сайте SEI (Software Engineering Institute).
База данных как Крепость
В базе данных хранится вся информация — как вводимая сотрудниками, так и полученная от клиентов. Пользовательские интерфейсы, бизнес-логика и прикладная логика (и даже сотрудники) приходят и уходят, а данные остаются. Трудно выразить словами то, насколько важно в первые же дни работы над проектом построить надежную модель данных.
Огромная популярность методологий гибкой разработки привела многих к мысли, что приложения можно (и даже предпочтительно!) проектировать по ходу работы. Эпоха предварительного написания сложных, исчерпывающих технических спецификаций ушла навсегда! Новая школа призывает поставлять продукт рано и часто. Одна строка эксплуатируемого кода полезнее 10 строк у вас в голове. Звучит слишком хорошо, чтобы быть правдой… во всяком случае в том, что касается данных.
В то время как бизнес-логика и пользовательские интерфейсы эволюционируют довольно быстро, структурам данных и их отношениям это обычно не свойственно. Следовательно, очень важно с самого начала четко определить модель данных как на структурном, так и на аналитическом уровнях. Миграция данных из одной схемы в другую «на месте» в лучшем случае сложна, всегда занимает много времени и часто чревата ошибками. Если с ошибками уровня приложения еще можно какое-то время мириться, ошибки в базе данных могут привести к катастрофическим последствиям. Даже если вы нашли и исправили ошибку проектирования на уровне данных, это не восстановит поврежденную информацию.
Надежная модель данных — это такая модель, которая гарантирует безопасность сегодняшних данных и может расширяться для данных завтрашних. Гарантировать безопасность означает обеспечить неуязвимость для ошибок, которые все равно (сколько бы усилий вы ни приложили) проникнут в вечно изменяющийся прикладной уровень; поддерживать ссылочную целостность данных; задавать ограничения предметной области везде, где они известны; выбирать подходящие ключи, которые помогут обеспечить ссылочную целостность и соблюдение ограничений. Обеспечить расширяемость означает правильно нормализовать данные, чтобы модель данных можно было легко дополнить новыми архитектурными уровнями, не прибегая к использованию всевозможных лазеек и обходных путей.
База данных — последний страж, охраняющий ваши драгоценные данные. Прикладной уровень, эфемерный по своей природе, не может следить за собой сам. Для того чтобы база данных обеспечивала необходимую защиту, модель данных нужно спроектировать так, чтобы она отвергала неподходящие данные и не позволяла создавать отношения, не имеющие смысла. Ключи, отношения по внешнему ключу и ограничения предметной области, описанные в схеме, лаконичны, понятны, легко проверяются и в конечном итоге самодокументируемы. Правила предметной области, закодированные в модели данных, также имеют физический, долгосрочный характер; они не теряются при изменениях в логике приложения.
Чтобы извлечь из реляционной базы данных максимальную пользу, то есть сделать ее полноценной частью приложения, а не просто хранилищем данных приложения, необходимо с самого начала хорошо понимать, что же вы создаете. По мере развития вашего продукта будет совершенствоваться и уровень данных, но в каждой фазе развития он должен сохранять свой статус Крепости. И тогда вы сможете довериться ему и с уверенностью возложить на него ответственность за перехват ошибок с других уровней приложения — и он вас не разочарует.
Руководствуйтесь неопределенностью
Столкнувшись с альтернативными вариантами, люди обычно полагают, что самое важное — сделать правильный выбор. В проектировании (программных продуктов или любом другом) это не так. Наличие альтернативы — признак того, что необходимо проанализировать неопределенность в дизайне системы. Используйте неопределенность как определяющий фактор для выявления тех мест, где можно отложить переход к деталям или применить разбиение и абстракцию, чтобы снизить важность проектировочных решений. Если вы жестко «прошьете» в системе первое же решение, которое пришло вам в голову, оно, скорее всего, в дальнейшем свяжет вам руки. В результате случайные решения начнут играть важную роль, а гибкость программного продукта снизится.
Одно из самых простых и конструктивных определений архитектуры дал Гради Буч (Grady Booch): «Любая архитектура является результатом проектирования, но не любое проектирование направлено на создание архитектуры. Архитектура служит представлением важных проектировочных решений, формирующих систему, причем важность здесь определяется стоимостью изменений». Отсюда следует, что эффективной является та архитектура, которая в общем случае снижает важность решений, принятых в ходе проектирования. Неэффективная архитектура эту важность увеличивает.
Если проектировочное решение может повести по одному из двух путей, архитектор должен отступить на шаг. Вместо того чтобы выбирать между вариантами А и Б, он должен подумать над другим вопросом: «Как спроектировать решение, чтобы снизить важность выбора между А и Б?». В этой ситуации интересен не выбор между А и Б, а сам факт существования этого выбора (а также то, что правильный выбор необязательно очевиден или неизменен).
Иногда архитектору приходится ходить кругами, прежде чем его озарит и он распознает возникшую дихотомию. Вы стоите у доски, обсуждая (весьма энергично) разные варианты с коллегой? Вы задумчиво бормочете «М-м-м» и «Э-э-э» над кодом, бесконечно перебирая возможные реализации? Когда новое требование или уточнение существующего требования ставит под сомнение разумность текущей реализации, перед вами неопределенность. Как реагировать на нее? Подумайте, как с помощью разделения или инкапсуляции изолировать принимаемое решение от кода, который в конечном итоге зависит от этого решения. Альтернативой этому часто становится невнятный код, который, словно нервничающий человек на собеседовании, бормочет что-то невразумительное и пытается компенсировать неуверенность множеством догадок и общих фраз. А если выбор делается с твердой, но необоснованной уверенностью, то проект на полной скорости и без оглядки сворачивает на неверный путь.
Часто возникает искушение принять «решение ради решения». В таких ситуациях вам поможет опционное мышление.[11] Если существует неопределенность относительно различных путей, по которым может пойти разработка системы, примите решение не принимать решение. Отложите конкретное решение до того момента, когда его можно будет принять более ответственно на основании реальных знаний, но не слишком надолго, чтобы не попасть в ситуацию, когда эти знания уже бесполезны.
Архитектура и процесс разработки тесно переплетены; это главная причина, по которой архитектор должен отдавать предпочтение таким циклам разработки и архитектурным подходам, которые имеют эмпирическую природу и обеспечивают обратную связь, чтобы конструктивно использовать неопределенность для деления на части самой системы и графика ее разработки.
Проблемы могут быть больше, чем их отражение в зеркале[12]
Я работал над сотнями программных проектов. В каждом из них встречались проблемы, которые создавали больше неприятностей, чем ожидала команда разработчиков. При этом часто происходило следующее: некоторые члены команды замечали такие проблемы рано, однако большинство сотрудников отвергало или игнорировало все симптомы, поскольку не понимало их важности, пока не становилось слишком поздно.
Это случается по разным причинам:
• Проблемы, которые кажутся тривиальными на ранней стадии проекта, становятся критическими тогда, когда их уже поздно исправлять. История про сварившуюся лягушку, вероятно, является преувеличением, однако она прекрасно иллюстрирует то, что творится во многих проектах.
• Некоторые сотрудники часто сталкиваются с сопротивлением в тех случаях, когда другие члены команды не обладают сходным опытом или знаниями. Для преодоления этого сопротивления необходимы исключительная смелость, уверенность и настойчивость, а подобными качествами редко обладают даже высокооплачиваемые опытные консультанты, нанятые специально для предотвращения таких проблем.
• Большинство разработчиков — оптимисты. Горький жизненный опыт учит нас умерять свой оптимизм, но неофиты склонны смотреть на мир оптимистично. Люди, от природы пессимистичные, в командах обычно непопулярны, даже если раз за разом оказываются правы. Мало кто захочет рисковать своей репутацией и пойдет против большинства без очень серьезных оснований. Многим из нас знакомо ощущение «не нравится мне все это, но не могу объяснить почему», однако оно редко становится действенным доводом в споре.
• У всех членов команды есть собственное мнение о том, что важно, а что нет. При этом их внимание сфокусировано на том, за что они отвечают лично, а не на целях проекта.
• У каждого из нас есть свои «слепые пятна» — слабости и недостатки, которые нам трудно осознать или принять.
Вот возможные стратегии противодействия этим факторам:
• Выработайте организованный подход к управлению рисками. Одно из самых простых решений — следить за рисками так же, как вы это делаете с программными ошибками. Кто угодно может выявить какой-либо риск, а затем каждый риск отслеживается до тех пор, пока не перестанет быть риском. При изменении статуса рисков или при появлении новых сведений риски пересматриваются и заново ранжируются. Это помогает устранить из обсуждений лишние эмоции и напоминает о необходимости периодической переоценки рисков.
• Выступая против большинства, подумайте, как помочь другим участникам команды понять вас. В любой команде, членом которой вы являетесь, поощряйте свободу мнений и старайтесь максимально спокойно обсуждать спорные темы.
• Предчувствия типа «не нравится мне все это» заслуживают пристального внимания. Если достоверных фактов еще нет, попробуйте придумать простейший способ проверки, который их предоставит.
• Постоянно соотносите свое видение системы с представлениями команды и заказчика. Такие средства, как ранжированный по приоритету список неформальных требований, полезны, но не заменяют регулярного общения с заказчиком и открытости мышления.
• Увидеть свои «слепые пятна» трудно по определению. Люди, от которых вы готовы услышать неприятную правду, когда она вам нужна, — ваш драгоценный ресурс.
Повторное использование зависит не только от архитектуры
Казалось бы, удачно спроектированная инфраструктура или хорошо продуманная и умно реализованная архитектура идеально подходит для повторного использования в вашей организации. Однако в действительности даже самые красивые и элегантные архитектуры, инфраструктуры или системы будут повторно использоваться только теми людьми, которые:
…знают об их существовании
Разработчики и проектировщики вашей организации должны знать о существовании архитектуры, инфраструктуры, библиотеки или фрагмента кода и о том, где можно найти всю необходимую информацию об этих элементах (документацию, данные о версиях и совместимости). Простая и логичная истина: люди не рассматривают возможности, о существовании которых не знают. Вы можете рассчитывать на повторное использование тех или иных элементов, только если информация о них активно распространяется.
Есть множество способов распространения информации о повторно используемых элементах в пределах организации — от вики-сайта с RSS-потоком, содержащим информацию об обновлениях (полезен в очень больших командах), до электронной почты с оповещениями об изменениях версий в репозитории исходного кода. В совсем маленькой команде проектировщик или ведущий разработчик может информировать своих коллег в личном разговоре или просто громким объявлением на весь офис. В общем, способ распространения информации о повторно используемых элементах может быть любым — главное, чтобы он был. Не оставляйте распространение информации на волю случая.
…умеют ими пользоваться
Умение повторно использовать элементы зависит от навыков и квалификации. Конечно, существуют люди, способные (по выражению Дональда Кнута (Donald Knuth)) «попадать в резонанс» с программированием и проектированием. Все мы работали с такими людьми — одаренными разработчиками и архитекторами, которые обладают впечатляющей (и даже пугающей) скоростью и глубиной усвоения информации. Но такие люди встречаются редко. Остальные члены команды, вероятно, просто хорошие, надежные, разумные разработчики и проектировщики. Их необходимо учить.
Может оказаться, что разработчики и проектировщики не знают тот конкретный шаблон, который использован при проектировании, или не в полной мере понимают модель наследования, выбранную проектировщиком инфраструктуры. Необходимо предоставить им простой доступ к информации в виде актуальной документации, а еще лучше — посредством обучения. Небольшие усилия, потраченные на обучение, способны хорошо подготовить команду к повторному использованию тех или иных элементов.
…считают, что это лучше, чем сделать заново самим
Многие люди — и особенно разработчики — предпочитают решать проблемы самостоятельно, вместо того чтобы обращаться за помощью. Спрашивать о том, как что-то работает, кажется им признаком слабости или даже проявлением невежества. Во многом это зависит от уровня зрелости и склада личности отдельных членов команды — для разных людей слова «лучше, чем сделать заново» означают разные вещи. «Молодые стрелки» всегда предпочитают писать нужный код самостоятельно, потому что это тешит их самолюбие. Более опытные участники чаще готовы принять тот факт, что кто-то другой уже размышлял над такой задачей и способен предложить что-то для ее решения.
Поделиться книгой: