(В оригинале - Try before choosing)

Написание ПО предполагает принятие множества решений. Это, например, выбор фреймворка или библиотеки, или же выбор конкретного паттерна проектирования. В любом случае ответственность за принятие решения лежит на архитекторе. Классический архитектор обычно старается собрать всю доступную информацию, «попереваривать» ее некоторое время, и после этого принять решение со своих академических высот, обязательное для выполнения разработчиками. Неудивительно, что существует путь получше.

В своей работе, посвященной Lean разработке, Mary и Tom Poppendieck описывают технику принятия решений. Они оспаривают подход, согласно которому нужно откладывать принятие решений как можно дольше, до самого последнего момента, когда дальше откладывать уже нельзя, когда в случае бездействия последствия будут необратимы. Это в общем благоразумно с той точки зрения, что чем позже принимается решение, тем больше доступно информации, на основе которой это решение и принимается. Однако часто больше информации еще не означает достаточно информации, к тому же известно, что лучшие решения основаны на прошлом опыте. Что же это значит для архитектора?

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

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

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

Автор оригинала - Erik Doernenburg