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

Пробуйте, прежде чем сделать выбор Эрик Дорненбург

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

В своем труде, посвященном бережливой разработке (lean development), Мэри и Том Поппендик (Магу и Tom Poppendieck) описывают методику принятия решений. Они считают, что принятие окончательного решения следует откладывать до самого ответственного момента — той точки, когда отсутствие у команды решения приведет к тому, что решение будет принято за нее, а бездействие повлечет за собой необратимые (или труднообратимые) последствия. И это разумно: ведь чем позднее принимается решение, тем больше информации для его принятия. Однако во многих случаях «больше информации» не равносильно «достаточно информации», а лучшие решения, как всем хорошо известно, принимаются «задним числом». Что это означает для хорошего архитектора?

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

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

Этот подход применим как к простым, так и к серьезным задачам. С его помощью команда может решить, стоит ли использовать шаблоны Hibernate, предоставляемые инфраструктурой Spring, но с таким же успехом он поможет ответить на вопрос, какую инфраструктуру JavaScript следует выбрать для проекта. Разумеется, время созревания решения очень сильно зависит от сложности задачи.

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

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