(В оригинале Use uncertainty as a driver)

Оказавшись перед выбором из двух альтернатив, большинство думает, что главное – это сделать правильный выбор между ними. В проектировании (ПО и не только) это не так. Наличие двух возможностей – индикатор того, что вам нужно подумать о внесении неопределенности в дизайн. Используйте неопределенность как повод определить, где вы можете отложить принятие решения, или где вы можете снизить значимость этого выбора. Если вы привяжете себя к первому пришедшему в голову варианту, скорее всего, поменять его потом будет сложно, в результате случайный выбор станет значимым и гибкость продукта снизится.

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

Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное – не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не всегда будет окончательным).

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

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

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

Автор оригинала - Kevlin Henney