IT>Обязан. Без непосредственного участия архитектора в кодировании у него через определенное время происходит разрыв с реальностью. Архитектор и девелоперы начинают разговаривать на разных языках и в результате дизайнерские решения и написанный код представляют собой две никак не связанные между собой вещи.

Вот, собственно, по поводу пункта 4.
Мой ответ — не да, ни нет В смысле, должнен время от времени, не особо погружаясь в кодирование.
Ибо проверено на собственном опыте и набиты соответствующие шишки в соответствующих местах.
Как только архитектор бросается с головой в разработку (причины: людей не хватает, "высочайшее повеление" либо неправильное позиционирование архитектора
в компании), так он начинает стремительно терять навыки архитектора, занимаясь жоцким дебагом и кодерством "на результат, патамушта нужно уже вчера".
Архитектура как таковая идет лесом, понимание текущего состояния системы и тенденций ее развития теряется, увы. Ну, если, конечно, у него не 3 головы, как у Змея Горыныча Вообще, рутина убивает в человеке все творческое начало
Однако ж и без кодирования жить невозможно. Действительно, не пишущий архитектор рожает такие решения, что страшно становится за судьбы Родины
Вывод — умело сочетать, но с упором на архитектуру. Где-то в соотношении 70%-архитектура (+ code review + постоянный реверсинжиниринг + короткие совещания + все, что нужно, чтобы держать ситуацию под контролем) и 30% — кодирование особо значимых частей. Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.
Собственно, вот такое мнение... Практика (личная) подсказывает, что это самый разумный выбор. По крайней мере, для меня.

Здравствуйте, vilner, Вы писали:

V>Помогите найти оптимальные ответы. (из расчета на будущие собеседования )

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

Здравствуйте, akarinsky, Вы писали:


IT>>Обязан. Без непосредственного участия архитектора в кодировании у него через определенное время происходит разрыв с реальностью. Архитектор и девелоперы начинают разговаривать на разных языках и в результате дизайнерские решения и написанный код представляют собой две никак не связанные между собой вещи.

A>Вот, собственно, по поводу пункта 4.
A>Мой ответ — не да, ни нет В смысле, должнен время от времени, не особо погружаясь в кодирование.
A>Ибо проверено на собственном опыте и набиты соответствующие шишки в соответствующих местах.
A>Как только архитектор бросается с головой в разработку (причины: людей не хватает, "высочайшее повеление" либо неправильное позиционирование архитектора
A>в компании), так он начинает стремительно терять навыки архитектора, занимаясь жоцким дебагом и кодерством "на результат, патамушта нужно уже вчера".
A>Архитектура как таковая идет лесом, понимание текущего состояния системы и тенденций ее развития теряется, увы. Ну, если, конечно, у него не 3 головы, как у Змея Горыныча Вообще, рутина убивает в человеке все творческое начало
A>Однако ж и без кодирования жить невозможно. Действительно, не пишущий архитектор рожает такие решения, что страшно становится за судьбы Родины
A>Вывод — умело сочетать, но с упором на архитектуру. Где-то в соотношении 70%-архитектура (+ code review + постоянный реверсинжиниринг + короткие совещания + все, что нужно, чтобы держать ситуацию под контролем) и 30% — кодирование особо значимых частей. Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.
A>Собственно, вот такое мнение... Практика (личная) подсказывает, что это самый разумный выбор. По крайней мере, для меня.

Полностью согласен.

Здравствуйте, akarinsky, Вы писали:


A>Как только архитектор бросается с головой в разработку (причины: людей не хватает, "высочайшее повеление" либо неправильное позиционирование архитектора
A>в компании), так он начинает стремительно терять навыки архитектора, занимаясь жоцким дебагом и кодерством "на результат, патамушта нужно уже вчера".
Неа. Мастерство не пропьешь

Здравствуйте, stump, Вы писали:

S>Здравствуйте, akarinsky, Вы писали:


A>>Как только архитектор бросается с головой в разработку (причины: людей не хватает, "высочайшее повеление" либо неправильное позиционирование архитектора
A>>в компании), так он начинает стремительно терять навыки архитектора, занимаясь жоцким дебагом и кодерством "на результат, патамушта нужно уже вчера".
S>Неа. Мастерство не пропьешь

Ну, значит немного не так выразился: перестаешь делать упор на красивую (суть — легко поддерживаемую и багоустойчивую) архитектуру и кодишь быстрее, "шоб слезли". Это у некоторых режиссеров получается еще и сниматься в своем фильме в главной роли, а у меня на такое энергии не хватает

Здравствуйте, kaa.python, Вы писали:

V>>Помогите найти оптимальные ответы. (из расчета на будущие собеседования )
KP>человек, который претендует на подобную позицию, но не в состоянии ответить на подобные вопросы не может быть архитектором в принципе. т.е. ему до это позиции еще расти и расти. и для него же будет лучше, если его просто не возьмут, чем потом, после того как он не справится со своими обязанностями уволят.

Свои ответы я привел, читать надо внимательнее.
За сим откланиваюсь. Большое спасибо stump and IT.

Здравствуйте, akarinsky, Вы писали:

A>Вывод — умело сочетать, но с упором на архитектуру. Где-то в соотношении 70%-архитектура (+ code review + постоянный реверсинжиниринг + короткие совещания + все, что нужно, чтобы держать ситуацию под контролем) и 30% — кодирование особо значимых частей.

70/30 это, наверное, минимум. 50/50 — максимум. Хотя всё зависит. В том числе и от стадий проекта. Например, в начале проекта, когда полным ходом идёт прототипирование и проба пера работа архитектора может состоять исключительно из кодирования. В самом конце, когда уже всё понятно, осталось только наколбасить кода и архитектору нечего делать, тоже можно помочь команде.

A>Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.

Думаю, это без разницы.

Здравствуйте, vilner, Вы писали:

V>Сегодня ходил на собеседование. Было весело. Нормальных вопросов не было ни одного. Или откровенно тупые — типа расскажите чем .NET 1.1 отличается от 2.0 и реализована ли там сборка мусора до выкручивания рук. Вот список запавших в душу

V>1. Что такое архитектура и как вы ее понимаете применительно к софт. проектам.

А — Способ построения системы, который обеспечивает ее логическую, бизнес , компонентную целостность.

V>2. Какие обязанности архитектора вы видите. (здесь и далее — архитектор проекта)

Обеспечивать целостность разрабатываемой системы

V>3. Какими инструментами должен пользоваться архитектор.

Он никому ничего не должен (хотя не знать UML, в наше время, — моветон). Все зависит от того

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

Кроме этого архитектор должен ориентироватся в подходах при разработке ПО. Например если РУП, то определить минимальный набор артефактов, нужных проекту. Если проект подразумевает больше 2х участников, то упиратся рогом, если кто-то будет предлагать СКРУМ и прочую лабуду.

V>4. Должен ли архитектор уметь кодировать. Обоснуйте ответ.

Если подразумевается архитектор-технический лидер да. Если архитектор — системный/бизнес аналитик — нет. Но в наше время в ИТ не так много людей, кто кодировать не умеет. Я бы задал это вопрос так — ДОЛЖЕН ли кодировать архитектор. Я лично думаю, что нет. Ему лучше бизнес область изучать.

V>5. Что такое фреймворк в понимании архитектора.

Интересный вопрос по своей постановке. Значит в понимании разработчика, тим лидера, менеджера проекта фрейворк это одно, а в понимании архитектора что-то другое. Можно ответить так инструмент, помогающий обеспечить целостность системы

V>Помогите найти оптимальные ответы. (из расчета на будущие собеседования )

Оптимальный ответ будет зависить от собеседующего

A>Вывод — умело сочетать, но с упором на архитектуру. Где-то в соотношении 70%-архитектура (+ code review + постоянный реверсинжиниринг + короткие совещания + все, что нужно, чтобы держать ситуацию под контролем) и 30% — кодирование особо значимых частей. Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.
Тут забыт такой момент, как прототипирование. Архитектуру тоже обычно нужно как-то проверять. Не всё укладывается в предыдущий опыт, а необоснованные фантазии — это бич нынешних архитектур.

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

Ошибаешься И не такие на должностях архитектора сидят.

Здравствуйте, VGn, Вы писали:

A>>Вывод — умело сочетать, но с упором на архитектуру. Где-то в соотношении 70%-архитектура (+ code review + постоянный реверсинжиниринг + короткие совещания + все, что нужно, чтобы держать ситуацию под контролем) и 30% — кодирование особо значимых частей. Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.
VGn>Тут забыт такой момент, как прототипирование. Архитектуру тоже обычно нужно как-то проверять. Не всё укладывается в предыдущий опыт, а необоснованные фантазии — это бич нынешних архитектур.

А вот и не забыт, а цинично проигнорирован
Подразумевалось, что прототипирование — часть работы над архитектурой. Так что сначала рожаем очередную идейку, постом с С# в цепких лапах проверяем ее жизнеспособность и смотрим, как она вписывается в концепцию, потом пробуем ее интегрировать с основным проектом (с тестовой веткой, конечно).
Если все вписывается и т.п. — готовим документацию, требования, тестовые сценарии и находим крайнего
Но все это тема для другого топика

Здравствуйте, Basil B, Вы писали:

BB>По-моему, архитектура — это комплекс методов по которым описывается система. То есть, компоненты и связи между ними — это уже дизайн, а принципы, которыми руководствуется дизайнер — это архитектура.

http://www.sorlik.ru/swebok/3-2-software_engineering_design.pdf

V>>3. В идеале — чистый лист бумаги. Все остальное — навороты и прибабахи .
P>Ну на листе не всегда удобно делать исправления + лист должен быть большой, да и в пользоваться им не очень удобно
Лучше использовать белую доску и разноцветные маркеры (если доска еще и магнитная, то вообще супер)...

Здравствуйте, vilner, Вы писали:

G>>Может напишешь что сам ответил?
V>Напишу
V>1. Архитектура определяет компоненты и их взаимодействие на основе бизнес-анализа.
V>Тема на 3 часа. Лично для меня архитектура _проекта_ это набор артефактов, определяющих сущности взаимодействия компонентов.

Тема на 10 мин. (при условии, что опоненты сами знают ответ). А от понимания понятия архитектуры зависят ответы на остальные вопросы. Об архитектуре см. здесь и здесь

Здравствуйте, vilner, Вы писали:

Интересно, а кто такие вопросы задает? Главный Архитектор? Казалось бы разумнее интересоваться опытом и внешними отзывами по предыдущим проектам.

Здравствуйте, IT, Вы писали:

A>>Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.

IT>Думаю, это без разницы.

Думаю есть разница, потому как за Software Quality Attributes в ответе архитектор. А наведение блеска -- это и есть концентрация на высококачественном коде.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, vilner, Вы писали:

V>>Помогите найти оптимальные ответы. (из расчета на будущие собеседования )

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

Человек, претендующий на такую позицию должен прежде всего правильно грамматически писать название позиции. Видел нескольких ArchiteKtov, можно даже время не тратить на техническое интервью с такими.

Здравствуйте, Dr.Gigabit, Вы писали:

A>>>Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.

IT>>Думаю, это без разницы.

DG>Думаю есть разница, потому как за Software Quality Attributes в ответе архитектор. А наведение блеска -- это и есть концентрация на высококачественном коде.

Видишь ли в чём дело, я вообще не понимаю что такое наведение блеска. Код должен блестеть всегда. Каждая строчка. Не важно архитектор ты или нет. Грязь и тяп-ляп в коде — это прежде всего грязь и тяп-ляп в головах. Я так думаю.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Dr.Gigabit, Вы писали:

A>>>>Причем стоит избегать дебага и вообще наведения блеска, для этого разумно использовать делегирование обязанностей.

IT>>>Думаю, это без разницы.

DG>>Думаю есть разница, потому как за Software Quality Attributes в ответе архитектор. А наведение блеска -- это и есть концентрация на высококачественном коде.

IT>Видишь ли в чём дело, я вообще не понимаю что такое наведение блеска. Код должен блестеть всегда. Каждая строчка. Не важно архитектор ты или нет. Грязь и тяп-ляп в коде — это прежде всего грязь и тяп-ляп в головах. Я так думаю.

Согласен,но проследи логику.
Исходный посыл
A>>>>Причем стоит избегать [дебага и вообще] наведения блеск
Т.е. стоит избегать наведения блеска (true)
Ты говоришь, IT>>>Думаю, это без разницы.
Т.е. or (true) == true следовательно ты думаешь что исходный посыл true :-D

Здравствуйте, Dr.Gigabit, Вы писали:

DG>Т.е. or (true) == true следовательно ты думаешь что исходный посыл true :-D

Я ответил про без разницы, чтобы не обижать автора предыдущего поста