avl (avl) wrote,
avl
avl

Category:

29. Попробуйте альтернативы перед принятием решения

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

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

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

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

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

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

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

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know
Subscribe

  • Про интерфейсы

    Была у нас в офисе микроволновка. Старая, самая простая, вот такая: Весь интерфейс — два поворотных регулятора. Один задает…

  • О ценности и цене

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

  • Первопричины политических взглядов

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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments