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

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

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

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

Наверно, вы уже догадались, что речь идет об использовании Хабра в качестве площадки, где можно получить реальную помощь от знающий людей.

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

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

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

С этой стороны, статья на Хабре становится просто идеальным вариантом, когда обсуждения сложного вопроса невозможно или просто не хочется организовать внутри компании. Но, что самое главное, какое бы решение и советы вы не получили в процессе обсуждения Хабро-статьи, вас никто не заставляет им следовать (в отличии от официального решения архитектурного комитета )!