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

1. Что такое архитектура и как вы ее понимаете применительно к софт. проектам.
2. Какие обязанности архитектора вы видите. (здесь и далее — архитектор проекта)
3. Какими инструментами должен пользоваться архитектор.
4. Должен ли архитектор уметь кодировать. Обоснуйте ответ.
5. Что такое фреймворк в понимании архитектора.

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

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

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

Со шпаргалной пойдете?

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

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

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

L>Со шпаргалной пойдете?
По теме есть что сказать?

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

V>Сегодня ходил на собеседование. Было весело. Нормальных вопросов не было ни одного. Или откровенно тупые — типа расскажите чем .NET 1.1 отличается от 2.0 и реализована ли там сборка мусора до выкручивания рук. Вот список запавших в душу
Хорошо, а что считается нормальными вопросами на позицию архитектора? Вот эти вполне нормальны по-моему, собенно в качестве защиты от деятелей, вчера на ночь прочитавших книжку про UML, и решивших пойти в кр00тые архитекторы. И, это, задавать "нормальные" вопросы начинают видя, что кандидат хорошо справляется с тупыми, или из резюме понятно что кандидат хорошо справлялся с подобными обязанностями на предыдущем месте.

V>1. Что такое архитектура и как вы ее понимаете применительно к софт. проектам.
А, действительно, что такое архитектура ПО?

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

L>>Со шпаргалной пойдете?
V>По теме есть что сказать?
в поиск!

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

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

Головой

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

Должен

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

То же, что и в понимании программиста

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

А ты сам не знаешь?

Здравствуйте, vilner, Вы писали:
V>1. Что такое архитектура и как вы ее понимаете применительно к софт. проектам.
V>2. Какие обязанности архитектора вы видите. (здесь и далее — архитектор проекта)
V>3. Какими инструментами должен пользоваться архитектор.
V>4. Должен ли архитектор уметь кодировать. Обоснуйте ответ.
V>5. Что такое фреймворк в понимании архитектора.

Может напишешь что сам ответил?

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

G>Здравствуйте, vilner, Вы писали:
V>>1. Что такое архитектура и как вы ее понимаете применительно к софт. проектам.
V>>2. Какие обязанности архитектора вы видите. (здесь и далее — архитектор проекта)
V>>3. Какими инструментами должен пользоваться архитектор.
V>>4. Должен ли архитектор уметь кодировать. Обоснуйте ответ.
V>>5. Что такое фреймворк в понимании архитектора.

G>Может напишешь что сам ответил?
Напишу
1. Архитектура определяет компоненты и их взаимодействие на основе бизнес-анализа.
Тема на 3 часа. Лично для меня архитектура _проекта_ это набор артефактов, определяющих сущности взаимодействия компонентов.
2. Такие же как и обязанности архитектора домов. Сбор требований и переваривание их в удобную для строителей (программистов) форму.
3. В идеале — чистый лист бумаги. Все остальное — навороты и прибабахи .
4. Хм. Думаю, что ожидается ответ "должен". На самом деле знаю архитектора, который работал первые 5 лет педиатором,
потом ушел в ИТ и до сих пор успешно работает архитектором в оч. крупной конторе, не написав ни строчки кода. Что ответить — не знаю.
5. Продукт другого архитектора, который можно применить в своей работе.

По поводу вакансии, на которую я проходил собеседование. Это позиция на должность со-архитектора проекта с 270-ю девелоперами в Цюрихе.
(Я живу в Швейцарии)
Т.е. не все так просто.

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

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

V>2. Такие же как и обязанности архитектора домов. Сбор требований и переваривание их в удобную для строителей (программистов) форму.
Сбор требований скорее обязанность аналитика, хотя могу ошибаться.

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

V>4. Хм. Думаю, что ожидается ответ "должен".
Я бы тоже ответил, что должен.

V>На самом деле знаю архитектора, который работал первые 5 лет педиатором,
V>потом ушел в ИТ и до сих пор успешно работает архитектором в оч. крупной конторе, не написав ни строчки кода. Что ответить — не знаю.
Возможно, что понятие "архитектор" у них несколько отличается от общепринятого. Если там архитектор занимается сбором требований, то почему нет.

V>5. Продукт другого архитектора, который можно применить в своей работе.
Ну в общем случае не одного архитектора, а ряда персонажей.

V>По поводу вакансии, на которую я проходил собеседование. Это позиция на должность со-архитектора проекта с 270-ю девелоперами в Цюрихе.
V>(Я живу в Швейцарии)
V>Т.е. не все так просто.
Желаю удачи

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


P>Это Вы своими словами сказали? Ощущение, что определение взято из книги с некачественным переводом.
Возможно это некачественный перевод с моего немецкого. Но суть идеи думаю понятна.

V>>2. Такие же как и обязанности архитектора домов. Сбор требований и переваривание их в удобную для строителей (программистов) форму.
P>Сбор требований скорее обязанность аналитика, хотя могу ошибаться.
Ок, не совсем точное определение — не сбор, а получение требований. Которые кто-то уже собрал и систематизировал. Тот же аналитик или юзабилити тим.
Хотя в Европе роли аналитика и архитектора часто совмещают. И даже архитектора и ПМ.


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


P>Желаю удачи
Спасибо

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

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


P>>Это Вы своими словами сказали? Ощущение, что определение взято из книги с некачественным переводом.
V>Возможно это некачественный перевод с моего немецкого. Но суть идеи думаю понятна.

Больше похоже на поток сознания с использованием терминов, прочитанных однажды в описании RUP (артефакты, например).

Вот как определение дано в стандарте IEEE 1471-2000: "фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие".

Кратко и емко.

V>>>2. Такие же как и обязанности архитектора домов. Сбор требований и переваривание их в удобную для строителей (программистов) форму.
P>>Сбор требований скорее обязанность аналитика, хотя могу ошибаться.
V>Ок, не совсем точное определение — не сбор, а получение требований. Которые кто-то уже собрал и систематизировал. Тот же аналитик или юзабилити тим.
V>Хотя в Европе роли аналитика и архитектора часто совмещают. И даже архитектора и ПМ.

Как вы себе представляете: обязанность архитектора — получение требований? Это как обязанность сотрудника — получение зарплаты? Задача архитектора — спроектировать архитектуру системы таким образом, чтобы она (система) удовлетворяла поставленным функциональным и не функциональным требованиям.

V>>>3. В идеале — чистый лист бумаги. Все остальное — навороты и прибабахи .

Помимо головы, я бы упомянул, как минимум, набор типовых решений.

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

V>1. Архитектура определяет компоненты и их взаимодействие на основе бизнес-анализа.

Слишком специфично. Не всегда есть компоненты и бизнес-аналих.

V>2. Такие же как и обязанности архитектора домов. Сбор требований и переваривание их в удобную для строителей (программистов) форму.

Абсолютно неверно. То, что ты описал — задача бизнес-аналитика. Задача архитектора (software architect в буржуйском варианте), как это не банально звучит, разработка архитектуры программы.

V>4. Хм. Думаю, что ожидается ответ "должен". На самом деле знаю архитектора, который работал первые 5 лет педиатором,
V>потом ушел в ИТ и до сих пор успешно работает архитектором в оч. крупной конторе, не написав ни строчки кода.

Может он все таки не архитектор вовсе, а тот самый бизнес-аналитик?

V>5. Продукт другого архитектора, который можно применить в своей работе.

Хм.

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

T>Вот как определение дано в стандарте IEEE 1471-2000: "фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие".

T>Кратко и емко.

Бессмысленно и беспощадно. Шутка.

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

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

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

V>>1. Архитектура определяет компоненты и их взаимодействие на основе бизнес-анализа.

AVK>Слишком специфично. Не всегда есть компоненты и бизнес-аналих.

Так обобщите, если не составит труда

V>>2. Такие же как и обязанности архитектора домов. Сбор требований и переваривание их в удобную для строителей (программистов) форму.

AVK>Абсолютно неверно. То, что ты описал — задача бизнес-аналитика. Задача архитектора (software architect в буржуйском варианте), как это не банально звучит, разработка архитектуры программы.

А что такое "разработка архитектуры программы"?

V>>5. Продукт другого архитектора, который можно применить в своей работе.

AVK>Хм.
Может мысль продолжите?

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

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

Архитектура — это решения, которые трудно изменить. (c) кажется Фаулер и компания.

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

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

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

Если имеется в виду какая-нибудь рисовалка типа Visio, то без разницы какая, лишь бы была.

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

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

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

Фреймворк — это вспомогательный софт + инфраструктура, предназначенные для построения целевого софта (других фреймворков или непосредтсвенно безнес логики). К сожалению, чёткую грань между фремворками и бизнес логикой провести достаточно сложно, поэтому лучше представлять это в виде линии, соединяющей с одной стороны чистую бизнес логику, с другой — максимально универсальный фреймворк. Весь софт находится где-то на этой линии. Так же полезно понимать, что к концам этой линии предъявляются принципиально разные требования, т.е. разработка фреймворков требудет иной техники, чем разработка бизнес логики.

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

AVK>>Слишком специфично. Не всегда есть компоненты и бизнес-аналих.

V>Так обобщите, если не составит труда

Тут уже привели хорошее определение.

AVK>>Абсолютно неверно. То, что ты описал — задача бизнес-аналитика. Задача архитектора (software architect в буржуйском варианте), как это не банально звучит, разработка архитектуры программы.

V>А что такое "разработка архитектуры программы"?

Это разработка архитектуры программы. Какое из этих трех русских слов тебе непонятно?

V>>>5. Продукт другого архитектора, который можно применить в своей работе.

AVK>>Хм.
V>Может мысль продолжите?

А если я сам фреймворк разрабатываю, то это уже не фреймворк?

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

V>>1. Что такое архитектура и как вы ее понимаете применительно к софт. проектам.
EK>А, действительно, что такое архитектура ПО?

Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению.(здесь)

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

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

T>>Вот как определение дано в стандарте IEEE 1471-2000: "фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие".

T>>Кратко и емко.

BB>Бессмысленно и беспощадно. Шутка.

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

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

Здравствуйте, IT, Вы писали:
Спасибо, очень понравились ваши ответы.

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

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

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

V>4. Хм. Думаю, что ожидается ответ "должен". На самом деле знаю архитектора, который работал первые 5 лет педиатором,
V>потом ушел в ИТ и до сих пор успешно работает архитектором в оч. крупной конторе, не написав ни строчки кода. Что ответить — не знаю.

Это не возможно или эта должность не архитектора, ибо в идеале нужно знать не один язык, самому реализовывать сложные участки кода, понимать и рефакторить код ...

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

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

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

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

Прошу прощение за офф-топ.
Стало интересно, а что бы спрашивал кандидата на позицию архитектора?

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

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

подозреваю, что автор написал по-немецки Architect

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

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

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

Прошу прощения за оффтоп, не заметил, что автору уже сделали замечание по поводу правильного написания.