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

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

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

Вместо того чтобы немедленно приступать к решению задачи в том виде, в котором вы ее получили, подумайте, нельзя ли изменить саму задачу. Спросите себя: как бы выглядела архитектура, если бы этой задачи просто не было? Такой подход может дать в итоге более элегантное и сбалансированное решение. Бизнес-задачу все равно придется решать, но, возможно, не так, как казалось изначально.

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

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

Стройте zuhanden-системы Кейт Брайтуэйт

Мы СОЗДАЕМ ИНСТРУМЕНТЫ. Создаваемые нами системы служат единственной цели (не считая того, что нам за них платят) — помогать кому-то (обычно кому-то другому) что-либо делать.

Мартин Хайдеггер (Martin Heidegger), известный немецкий философ XX века, исследовал, как люди воспринимают инструменты (и вообще «оборудование»). Человек использует инструмент для достижения определенной цели, причем сам инструмент является всего лишь вспомогательным средством.

Для успешного применения инструмент должен быть zuhanden («подручным», то есть «ложащимся в руку»). Иначе говоря, такой инструмент воспринимается непосредственно, он используется инстинктивно, без размышлений и полемики. Мы просто берем инструмент и используем его для достижения нашей цели. В ходе такого использования инструмент исчезает, он фактически становится продолжением нашего тела и не воспринимается как нечто отдельное. Одним из признаков zuhanden-инструмента является то, что он становится как бы невидимым, неосязаемым, незаметным.

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

Возможна и другая ситуация (обычно она свидетельствует о возникших проблемах): пользователь воспринимает инструмент как vorhanden («наличествующий», то есть «находящийся в руке»). Инструмент отделяется от цели; он находится перед вами, требуя вашего внимания. Он становится объектом отдельного исследования. Пользователь уже не может двигаться к цели; он должен разобраться с инструментом, прежде чем тот сможет хоть как-то приблизить его к ней. Нам как техническим специалистам свойственно воспринимать создаваемые нами для пользователей системы как vorhanden-инструменты — и в ходе работы над ними, и позднее, когда мы получаем сообщения о дефектах. Инструмент вполне закономерно является для нас объектом рассмотрения, предметом размышлений, исследовательской задачей. Это нечто требующее изучения.

Однако (и это очень важно!) пользователи смогут добиться успеха, применяя наш продукт, только в том случае, если для них это zuhanden-инструмент. Спроектированы ли ваши системы так, чтобы становиться «невидимыми» при использовании? Насколько естественно «ложится в руку» пользовательский интерфейс? Или же ваша система постоянно требует внимания, отвлекая пользователя от его цели?

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

Найдите и удерживайте энтузиастов Чед Лавинь

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