При создании нового или не стандартного решения архитектор/разработчик обычно ищет компромисс между тем что хочется и тем, что нужно с учетом заданных ограничений. И всегда существует возможность в конечном итоге сделать не то, что ожидалось или получить далеко не оптимальное решение.
И если «хотели как лучше, а получилось как всегда» случается из-за неучтенных или изменившихся требований, то это хотя бы можно объяснить. Но порой и на старуху бывает проруха и становится досадно пропустить детскую ошибку просто из-за замылившихся глаз или из-за подводных камней реального использования модной технологии.
И чтобы минимизировать возможность таких ошибок, во многих компаниях существует практика защиты архитектурного решения перед началом непосредственной разработки нового крупного проекта. Это может быть организовано в виде собрания, проведения архитектурного ревью или просто обсуждения в курилке. Тут все зависит от штатной структуры и размера компании, а так же от поставленных процессов разработки.
А что делать, если разработчиков в компании раз-два и обчелся, либо их опыта недостаточно для экспертной оценки предлагаемого решения? Или у них просто отсутствует время или желание вникать в чужие трудности?
