R
Мне ещё не очень понятно, как можно решать архитектурные задачи, параллельно с написанием кода в продакшен и проведением код-ревью. Совершенно разный фокус, разные уровни абстракции
значит что-то нужно делегировать синьеру помидору
Size: a a a
2017 May 30
DB
А что по вашему "решение задач" без проверки идей кодом?
DB
Доказательство теорем?
GK
А что по вашему "решение задач" без проверки идей кодом?
Для проверки идей есть PoC
GK
Архитектор, на мой взгляд, вполне может разрабатывать прототипы и скелетоны, но во чтобы в продакшен писать, это вопрос
R
Архитектор, на мой взгляд, вполне может разрабатывать прототипы и скелетоны, но во чтобы в продакшен писать, это вопрос
что руководство в должностной инструкции прописало - то и должен делать)
GK
Из своей практики могу сказать, что очень хорошо работает такой процесс: делаю PoC, пишу скелетон (развиваемый прототип), провожу knowledge transfer, а дальше команда сама развивает решение и часто делает это отлично. На первых порах "приглядываю" за решением, отвечаю на вопросы.
E
Но роль архитектора возникает в следствии сложности бизнеса, а не IT
+1
GK
Иногда решение эволюционирует и прототип выбрасывают полностью
KB
Либо есть отдельный архитектор который шарится между разными командами
Да, я такой архитектор. +Связь команд с внешним миром ( в том числе и доброе вечное межкомандное велосипедное)
YK
Если подвести итог, архитекторы нужны в сложных доменах, возможно там, где есть стейкхолдеры, интересы и цели которых могут противоречить. Так?
Точно.
YK
Архитектор, на мой взгляд, вполне может разрабатывать прототипы и скелетоны, но во чтобы в продакшен писать, это вопрос
Зависит от вида архитектора. Ea, Sol, Soft. И только последний может такое лелать. Но опять же в зависимости от сложности домена.
AS
Из своей практики могу сказать, что очень хорошо работает такой процесс: делаю PoC, пишу скелетон (развиваемый прототип), провожу knowledge transfer, а дальше команда сама развивает решение и часто делает это отлично. На первых порах "приглядываю" за решением, отвечаю на вопросы.
Проблема в том, что навык разработки сугубо практический и практиковать нужно ежедневно. Польза от такого прототипа, только чтобы конкретизировать идею. А так хорошие разработчики справятся с задачей эффективнее. То есть для solution architect важно глубоко понимать суть разработки, но вряд ли имеет смысл погружаться в код, глубже чем для написания прототипов.
YK
Если домен сложный, то руки не дойдут.
AS
С другой стороны я не очень верю в архитекторов вышедших из чистых аналитиков и непонимающих базовых паттернов и принципов.
YK
С другой стороны я не очень верю в архитекторов вышедших из чистых аналитиков и непонимающих базовых паттернов и принципов.
Это уже другая проблема
GK
Проблема в том, что навык разработки сугубо практический и практиковать нужно ежедневно. Польза от такого прототипа, только чтобы конкретизировать идею. А так хорошие разработчики справятся с задачей эффективнее. То есть для solution architect важно глубоко понимать суть разработки, но вряд ли имеет смысл погружаться в код, глубже чем для написания прототипов.
Да. И не то что бы нет смысла погружаться глубоко в код, это даже вредно, так как фокус сужается и теряется видение всей картины, всего решения в комплексе
E
Это вообще отдельная тема - как растить архитектора. Из кого, чем удобрять и поливать...
E
И тема очень интересная :)
GK
И тема очень интересная :)
К ней нужно подходить политкорректно :)