Шаблоны

UML говорит, как изобразить объектно-ориентированный дизайн. Напротив, шаблоны представляют результат: примеры дизайна.

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

Рассмотрим пример. Предположим, что у вас есть некоторые объек­ты, запускаемые в процессе на рабочем столе, и они должны взаи­модействовать с другими объектами, запускаемыми во втором про­цессе. Возможно, второй процесс располагается также на вашем ра­бочем столе; возможно, он располагается в другом месте. Объекты вашей системы не должны искать другие процессы в сети или вы­полнять удаленные вызовы процедур.

Для удаленного объекта можно создать объект-посредник внутри локального процесса. Посредник имеет тот же самый интерфейс, что и удаленный объект. Локальный объект общается с посредни­ком при помощи рассылки обычных сообщений внутри процесса. При этом посредник отвечает за передачу сообщений реальному объекту независимо от его местоположения.

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

В начале 90-х годов специалисты начали приобретать такой опыт. Они образовали сообщество людей, заинтересованных в написании шаблонов. Эти специалисты спонсировали ряд конференций и вы­пустили несколько книг.

Наиболее известной публикацией по шаблонам, выпущенной этой группой, является книга «банды четырех* [21], в которой подробно рассмотрены 23 шаблона дизайна. Посредникам в этой книге по­священ десяток страниц, дающих детальное представление о том, как объекты работают друг с другом; кроме того, обсуждаются пре­имущества и ограничения шаблонов, общие варианты использова­ния и советы по реализации шаблонов.

Шаблон - это больше, чем модель. Шаблон должен также включать обоснование выбранного пути. Часто говорят, что шаблон - это ключ к решению проблемы. Шаблон должен четко идентифицировать проблему, объяснить, почему он решает проблему, а также объяс­нить, при каких условиях шаблон работает, а при каких нет.

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

Когда я начинал, меня удивляло, почему я должен все изобретать с нуля. Почему у меня нет руководства, в котором бы рассказыва­лось о том, как делать общие вещи? Сообщество пытается создать такую книгу.

В настоящее время издано множество книг по шаблонам, и они очень отличаются по качеству. Мои любимые - это [21], [36], [37], [13], [35] и, извините за нескромность, [16] и [19]. Кроме того, вы можете зайти на домашнюю страничку шаблонов: https://www.hill-side.net /patterns.

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

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

1. Сохранить, все, что работало правильно, и вы хотите это продол­
жить.

2. Проблемы: разделы, которые работали неправильно.

3. Испытать: изменения в процессе с целью его улучшения

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

В конце разработки проекта или его основной версии можно провести более формальный ретроспективный анализ проекта (project retro­spective), который может занять пару дней; более подробную инфор­мацию можно найти на https://www.retrospectives.com/ и в книге [26]. Больше всего меня раздражает, когда организации упорно игнориру­ют собственный опыт и постоянно совершают одни и те же ошибки.