При создании нового или не стандартного решения
архитектор/разработчик обычно ищет компромисс между тем что хочется
и тем, что нужно с учетом заданных ограничений. И всегда существует
возможность в конечном итоге сделать не то, что ожидалось или
получить далеко не оптимальное решение.
И если хотели как лучше, а получилось как всегда случается из-за
неучтенных или изменившихся требований, то это хотя бы можно
объяснить. Но порой и на старуху бывает проруха и становится
досадно пропустить детскую ошибку просто из-за замылившихся глаз
или из-за подводных камней реального использования модной
технологии.
И чтобы минимизировать возможность таких ошибок, во многих
компаниях существует практика защиты архитектурного решения перед
началом непосредственной разработки нового крупного проекта. Это
может быть организовано в виде собрания, проведения архитектурного
ревью или просто обсуждения в курилке. Тут все зависит от штатной
структуры и размера компании, а так же от поставленных процессов
разработки.
А что делать, если разработчиков в компании раз-два и обчелся, либо
их опыта недостаточно для экспертной оценки всего решения? Или у
них просто отсутствует время или желание вникать в чужие
трудности?
Наверно, вы уже догадались, что речь идет об использовании Хабра в
качестве площадки, где можно получить реальную помощь от знающий
людей.
И действительно, путем публичного обсуждения, можно получить
замечательную обратную связь. Причем, написание статьи для Хабра
значительно проще и удобнее, чем готовится к защите на
архитектурном комитете. Не нужно согласовывать дату и время, когда
можно оторвать людей от основного процесса. А им в свою очередь, не
нужно сразу включаться в контекст, чтобы иметь возможность
участвовать в обсуждении деталей.
В свое время мне довелось участвовать работе архитектурного
комитета крупной компании. И ощущение после завершения каждой
встречи всегда было двоякое. С одной стороны, очень здорово
получить новый опыт и зачастую реальную помощь. Но бывало и так,
что обычное обсуждение, казалось бы мелкого вопроса, превращалась в
словесную баталию, отголоски которой долетали по прошествии
нескольких дней.
Особенно мне запомнился опыт участия в процессе унификации
используемых компонентов. Согласование интерфейса и реализации
одного малюсенькой библиотеки заняло более полутора лет и
потребовало нескольких полных переделок всей реализации. В
результате куча убитого времени на приведение кода в юзабельное
состояние, которое бы удовлетворило всех потребителей и полностью
выгоревшее желание, делать еще раз, что либо подобное.
С этой стороны, статья на Хабре становится просто идеальным
вариантом, когда в компании недостаточно компетенции для
организации обсуждения сложного вопроса. И что самое главное, какое
бы решение и советы вы не получили в процессе обсуждения статьи,
вас никто не заставляет им следовать! :-)
|
Русский
|
|
|
Русский
|
|
English
|
