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

Не спешите решать задачи Збен Хьюит

Практически все архитекторы когда-то были разработчиками. Разработчикам платят за решение задач из области программирования, менее масштабных по сравнению с архитектурными задачами. Как правило, это мелкие каверзные алгоритмические задачи. Они часто представлены в книгах и учебных курсах так, словно существуют в отрыве от реальности, а их каверзность выглядит весьма вызывающе и соблазнительно. Со временем мы начинаем воспринимать такие задачи как данность — мы не спрашиваем, насколько осмысленна задача, интересна ли она, полезна, этична и так далее. Нам не платят за анализ роли задачи в более широком контексте. Мы приучены концентрироваться исключительно на самом решении; дело усугубляется тем, что решать сложные задачи действительно трудно. Мы привыкли брать быка за рога на собеседованиях, где перед нами по сути вываливают груду цветных леденцов, требуя рассортировать их в соответствии с некоторым набором ограничений. Нас приучают не сомневаться в этих ограничениях: они — учебный инструмент, при помощи которого мы должны самостоятельно открыть то, что уже известно учителю или экзаменатору.

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

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

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

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

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

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

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