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

КЛ>Здравствуйте, minorlogic, Вы писали:

M>>1. Предложить разбить на компоненты и связи обределенный функционал , не большой. Например игра шахматы, сервис взаимодействующий с GoogMap для отрисовки карт, и т.п. как можно ближе к прикладной области.

КЛ>Таким образом, один из критериев — архитектор должен уметь выполнять декомпозицию сложной и крупной задачи на легкие и небольшие, сложной системы — на подсистемы и взаимосвязи между ними. Однако этот критерий хорошо, когда ясно, по какому принципу проводить такую декомпозицию. Как понять, что декомпозиция проведена правильно? Какой принцип положить в её основе?

Я и написал в пункте 3
"3. Плавно поговорить о критериях как оценить то или иное решение, предложите оценить несколько разных решений. Как минимум он их должен "чувствовать"."

Т.е. после выполнения декомпозиции обсудить критерии по которым декомпозиция осуществлялась. Я не могу согласится что декомпозиция может быть только одна правильная и все остальные неправильные.

Кроме очевидных критериев таких как (компонент тут класс, модуль , библиотека и т.п. в зависимости от уровня детализации)
1. Сужение ответственности (функциональности ) компонента.
2. Сужение интерфейса компонента.
3. Упрощение графа зависимостей (в идеале дерево).
4. увеличение универсальности компонента.

Есть еще целый ряд специфических знаний и характеристик.


M>>4. Если фантазия не работает , предложите решить имеющиеся проблемы.

КЛ>Реальные задачи могут потребовать часы и дни для их решения. Не навино ли будет полагать, что кандидат в условиях стресса в течение 5 — 30 минут предложит работоспособное решение?

Поэтому я пердлагать в 1. небольшие подзадачи, объяснить и обсудить которые можно в течении получаса.

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

КЛ>Здравствуйте, minorlogic, Вы писали:

M>>1. повысить прозрачность системы (архитектура).
M>>2. повысить гибкость системы (архитектура).

КЛ>Это всё общие слова. Допустим, система обладает определенными недостатками — ряд функций, которые может выполнять сама, отдаёт на откуп пользователю. Эти конкретные недостатки и нужно исправить в следующей версии. А что такое "прозрачность" и "гибкость" — непонятно.

Достаточно понятно,
Прозрачность системы это когда каждый разработчик знает или может узнать за что отвечает каждый компонент системы.
Гибкость это гибкость, способность быстро меняться с минимальными усилиями для изменения функциональности.

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

A>3) Никакого булщита по поводу метрик, качества кода, 100% покрытия тестами и привержености паттернов (за каждое слово произнесенное в этом ключе я бы давал штрафные баллы).

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

Спасибо!

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

M>И на практике с трудом представляю , как проверить отдельно от остальных именно "навыки архитектора".

Мне представляется, что это всё-таки возможно. Попозже я изложу свой подход. Просто сейчас мне не хочется сбивать обсуждение — интересно узнать мнения коллег.

Спасибо!

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

G>>Это значит, что ты всех выслушиваешь и потом выбираешь того, кто тебе больше понравился.
_D>Экспертная оценка предполагает оценку на основе группового мнения...

У меня там кавычки были.

"экспертная оценка" в данном контектсе это ироничное название метода тыка

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


Опять, блин, никакой конкретики.

КЛ>Сколько времени нужно давать на решение задачи?
Зависит от задачи, конечно. Одни задачи можно решать за 5 мин, вторые несколько дней... Понравившемуся кандидату можно предложить взять задачу "домой".
Но главное в том, что вам не столь важно успел решить задачу кандидат или нет. Вам важно понять как он думает.

КЛ> Вы уверены, что в условиях собеседования кандидат сможет предложить рабочее решение, особенно, если учесть, что решение некоторых задач может занимать часы или даже дни?
Уверен. Даже если он не даст окончательного решения можно понять как он решает задачу. уже это многое может сказать о специалисте.
Кроме того, а вы уверены, что решение, которое нужно разрабатывать пару дней можно будет реализовать за месяц?

КЛ>Следует ли кандидату дать время на обдумывание задачи и оставить его одного?
КЛ>Следует ли кандидата перебивать во время решения, как-то направлять? Или же дать ему время получить результат и оценивать уже результат, а не ход решения, если этот ход решения Вам не понятен?
Вот это полностью зависит от кандидата. Одним нужен покой, другим, наоборот, собеседник/оппонент. Мне, лично, нужен собеседник.
Будет хорошо если собеседующий архитектор не будет иметь готового решения. Тогда он сможет включится в процесс.

КЛ>Или же лучше попросить его комментировать ход решения (т.е. попросить его рассказать, что он делает по шагам)? И, таким образом, оценить подход к решению задачи?
Вам важен нужен результат или ход достижения результата? Вполне возможно сам человек не сможет сказать почему он принял какое-либо решение.
Если результат есть, то пусть объясняет почему он выбрал именно это решение. Как/чем это решение поможет сделать нужные изменения в кратчайшие сроки.
Если решения нет, то должны быть хоть какие-то промежуточные результаты. Пусть расскажет какие принципы он хотел заложить в будущий дизайн, какие цели преследовал при его разработке /* например: у нас есть три похожих требования, нужно сделать так-то и так-то чтобы их легко было реализовать. Вот тут у вас хрень какая-то надизайнена, а изменений много. Поэтому сразу же выкидываем кусок нафик/делаем отдельный модуль, интегрируем его так-то и так-то... */.
В общем

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


КЛ>С этим полностью согласен. Остальные критерии — важны, но они косвеные. Нужен механизм для оценки архитектурных решений или подхода к получению этих решений.
Что считать косвенным, а что нет?
Если сделать акцент на знаниях кандидата и забыть про горящий проект, то да, согласен, косвенные.
А если все же спасти проект важнее, то наоборот.


СУВ, Aikin

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

M>Т.е. после выполнения декомпозиции обсудить критерии по которым декомпозиция осуществлялась. Я не могу согласится что декомпозиция может быть только одна правильная и все остальные неправильные.
Допустим, существует не одна, а несколько правильных декомпозиций. Какие критерии могут быть заложены в их основе?

M>Кроме очевидных критериев таких как (компонент тут класс, модуль , библиотека и т.п. в зависимости от уровня детализации)
M>1. Сужение ответственности (функциональности ) компонента.
M>2. Сужение интерфейса компонента.
(1) Разве интерфейс компонента не зависит от его функциональности?

M>3. Упрощение графа зависимостей (в идеале дерево).
(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций?

M>4. увеличение универсальности компонента.
(3) Если под универсальностью компонента понимать ограничение на функциональность компонента (например, 1 компонент == 1 функция), но одновременно снятие всяческих ограничений на количество и разнородность обрабатываемых этим компонентом объектов (например, 1 компонент == N объектов == M разных видов объектов), то... см. (4).

(4) Разве (1), (2) и (3) не свидетельствуют о том, что в основу декомпозиции должен быть положен функциональный критерий? Иными словами, перед тем, как проектировать структуру системы, хорошо бы сначала построить её функциональную модель...

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

A>Вам важен нужен результат или ход достижения результата? Вполне возможно сам человек не сможет сказать почему он принял какое-либо решение.
Я смотрю на это дело с точки зрения работодателя (или заказчика). Допустим, я не могу оценить качество архитектурных решений, предложенных кандидатом. Тогда я могу попытаться оценить методологию получения этих решений.

ИМХО, ни одна сложная задача, к которым, безусловно, относится задача проектирования программной системы, не может быть решена без отлаженной методологии. Конечно, нередко архитектор сам до конца не осознает её и применяет интуитивно. Однако наблюдая за ходом решения, особенно, если кандидат будет комментировать свои шаги и обосновывать, почему он поступил так, а не иначе, можно будет составить представление о данной методологии. И о том, позволяет ли она решать необходимые задачи.

Понятно, что методология должна удовлетворять определённым критериям. И эти критерии ведущий собеседование должен понимать. Но в данном случае ему не нужно вникать глубоко в суть методологии, применённой кандидатом. Ему достаточно понять, удовлетворяет ли данная методология нужным критериям.

P.S.: Именно поэтому мне не кажется хорошим вариантом, когда кандидата собеседует опытный архитектор. Дело в том, что у двух гуру могут быть разные подходы к проектированию. В этом случае ведущий собеседование специалист будет оценивать кандидата через призму своего опыта — и просто завалит кандидата, если подход к решению задачи (в простейшем случае, последовательность шагов для получения решения) будет не такой, как у него.

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

КЛ>Здравствуйте, minorlogic, Вы писали:

M>>Т.е. после выполнения декомпозиции обсудить критерии по которым декомпозиция осуществлялась. Я не могу согласится что декомпозиция может быть только одна правильная и все остальные неправильные.
КЛ>Допустим, существует не одна, а несколько правильных декомпозиций. Какие критерии могут быть заложены в их основе?

Кирилл? Я же написал какие ниже.

M>>Кроме очевидных критериев таких как (компонент тут класс, модуль , библиотека и т.п. в зависимости от уровня детализации)
M>>1. Сужение ответственности (функциональности ) компонента.
M>>2. Сужение интерфейса компонента.
КЛ>(1) Разве интерфейс компонента не зависит от его функциональности?

Зависит но не определяет. Одну и ту же функциональность можно представить разными интерфейсами.

M>>3. Упрощение графа зависимостей (в идеале дерево).
КЛ>(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций?

Возможно так, мне сложно судить о "правильным распределением функций". Тяжело понять что вы подразумеваете по этим.

M>>4. увеличение универсальности компонента.
КЛ>(3) Если под универсальностью компонента понимать ограничение на функциональность компонента (например, 1 компонент == 1 функция), но одновременно снятие всяческих ограничений на количество и разнородность обрабатываемых этим компонентом объектов (например, 1 компонент == N объектов == M разных видов объектов), то... см. (4).

КЛ>(4) Разве (1), (2) и (3) не свидетельствуют о том, что в основу декомпозиции должен быть положен функциональный критерий? Иными словами, перед тем, как проектировать структуру системы, хорошо бы сначала построить её функциональную модель...

Что такое "функциональный критерий" и функциональную модель в вашей терминологии мне неизвестно. Но очевидным для меня , что приступать к архитектуре надо очень хорошо представлять функциональность будущей системы. Но мы то рассматриваем задачу когда функциональность системы хорошо известна ? Или нет ?

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

M>Кирилл? Я же написал какие ниже.
Ок.

КЛ>>(1) Разве интерфейс компонента не зависит от его функциональности?
M>Зависит но не определяет. Одну и ту же функциональность можно представить разными интерфейсами.

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

M>>>3. Упрощение графа зависимостей (в идеале дерево).
КЛ>>(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций?
M> Возможно так, мне сложно судить о "правильным распределением функций". Тяжело понять что вы подразумеваете по этим.

В данном случае, я подразумеваю распределение полезных функций (== обязанностей) между компонентами. Например:

1. Мы можем делегировать 1-му классу Фигура 3 полезных функции:

(1) Загрузка (например, из файла).
(2) Визуализация.
(3) Сохранение.

2. А можем — делегировать каждую из этих функций своему классу:

(1) загрузку — Загружальщику,
(2) визуализацию — Рисовальщику,
(3) сохранение — Сохраняльщику.

M>Что такое "функциональный критерий" и функциональную модель в вашей терминологии мне неизвестно. Но очевидным для меня , что приступать к архитектуре надо очень хорошо представлять функциональность будущей системы. Но мы то рассматриваем задачу когда функциональность системы хорошо известна ? Или нет ?

При проектировании или "рефакторинге" (например, в ФСА) обычных технических систем строят как структурную, так и функциональную модели системы.

(1) Структурная модель системы описывает то, из каких компонентов, состоит система, и взаимосвязи между этими компонентами.
(2) Функциональная модель системы описывает то, какие полезные функции выполняет система. В общем случае, это просто список функций или список функций, выстроенных в определённом порядке, например, в порядке их выполнения.

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

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

КЛ>Здравствуйте, minorlogic, Вы писали:

M>>Кирилл? Я же написал какие ниже.
КЛ>Ок.

КЛ>>>(1) Разве интерфейс компонента не зависит от его функциональности?
M>>Зависит но не определяет. Одну и ту же функциональность можно представить разными интерфейсами.

КЛ>Хорошо. Но Вы согласны с утверждением, что если компонент выполняет больше полезных функций (== обязанностей) из некоторого списка, то и интерфейс у него будет шире, чем у компонента, который выполняет, допустим, одну обязанность из точно того же списка?

Утверждение часто корректное, но бывают и ситуации когда грамотно выбраная функциональность и интерфейс сильно сильно расширяют функциональность компонента. Например функциональность описанная как "методы обхода 25 разных коллеций и последовательностей" можно реализовать очень толсто и очень гетерогенно. А можно использовать интерфейс "итератор" с компактной функциональностью и узким интерфейсом.


M>>>>3. Упрощение графа зависимостей (в идеале дерево).
КЛ>>>(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций?
M>> Возможно так, мне сложно судить о "правильным распределением функций". Тяжело понять что вы подразумеваете по этим.

КЛ>В данном случае, я подразумеваю распределение полезных функций (== обязанностей) между компонентами. Например:

КЛ>1. Мы можем делегировать 1-му классу Фигура 3 полезных функции:

КЛ>(1) Загрузка (например, из файла).
КЛ>(2) Визуализация.
КЛ>(3) Сохранение.

КЛ>2. А можем — делегировать каждую из этих функций своему классу:

КЛ>(1) загрузку — Загружальщику,
КЛ>(2) визуализацию — Рисовальщику,
КЛ>(3) сохранение — Сохраняльщику.

Тогда нет, неверно. Декомпозиция на компоненты и затем распределение функциональности по ним , не должно быть разделено на этапы. Это один и тот же этап. Отделяя компонент из системы мы отделяем его уже по той ответственности которую он несет. Компонент это не его "название" это его ответственность.

M>>Что такое "функциональный критерий" и функциональную модель в вашей терминологии мне неизвестно. Но очевидным для меня , что приступать к архитектуре надо очень хорошо представлять функциональность будущей системы. Но мы то рассматриваем задачу когда функциональность системы хорошо известна ? Или нет ?

КЛ>При проектировании или "рефакторинге" (например, в ФСА) обычных технических систем строят как структурную, так и функциональную модели системы.

КЛ>(1) Структурная модель системы описывает то, из каких компонентов, состоит система, и взаимосвязи между этими компонентами.
КЛ>(2) Функциональная модель системы описывает то, какие полезные функции выполняет система. В общем случае, это просто список функций или список функций, выстроенных в определённом порядке, например, в порядке их выполнения.

КЛ>Очевидно, что для того, чтобы создать структурную модель вновь проектируемой системы, для неё сначала необходимо построить функциональную модель, т.к. система создаётся для выполнения неких полезных функций, а не просто так.

Очевидно.

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

КЛ>P.S.: Именно поэтому мне не кажется хорошим вариантом, когда кандидата собеседует опытный архитектор. Дело в том, что у двух гуру могут быть разные подходы к проектированию. В этом случае ведущий собеседование специалист будет оценивать кандидата через призму своего опыта — и просто завалит кандидата, если подход к решению задачи (в простейшем случае, последовательность шагов для получения решения) будет не такой, как у него.

Плохой интервьюер завалит кандидата, т.к. будет требовать какую то особенную методологию, подход к решению и тд.

Не архитектор завалит архитектора, а плохой интервьюер завалит кандидата.

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

M>Утверждение часто корректное, но бывают и ситуации когда грамотно выбраная функциональность и интерфейс сильно сильно расширяют функциональность компонента. Например функциональность описанная как "методы обхода 25 разных коллеций и последовательностей" можно реализовать очень толсто и очень гетерогенно. А можно использовать интерфейс "итератор" с компактной функциональностью и узким интерфейсом.

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

Чтобы сделать код последовательного обхода коллекции независимым от типа коллекции, нужно, чтобы кто-то предоставлял такие функции:

(1) Получение текущего элемента коллекции
(2) Переход к следующему элементу коллекции
(3) Проверка, достигли ли мы определенного элемента коллекции

Собственно, эти функции и предоставляет компонент итератор.

M>Тогда нет, неверно. Декомпозиция на компоненты и затем распределение функциональности по ним , не должно быть разделено на этапы. Это один и тот же этап. Отделяя компонент из системы мы отделяем его уже по той ответственности которую он несет. Компонент это не его "название" это его ответственность.

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

(1) Создаю функциональную модель
(2) Упорядочиваю функции в порядке выполнения (т.е. описываю процесс, в котором программа или подсистема будет делать то, ради чего создаётся)
(3) Делегирую функции отдельным компонентам, которые, на первых парах, обзываю именами, производными от названия функций
(4) Мысленно проверяю, как будет работать система, не будет ли каких-то сбоев при взаимосвязи между компонентами
(5) Вношу изменения в п.п. 3 и 4 и повторяю п. 5. Иногда, при этом, приходится возвращаться к п. 1, т.к. уточняется/изменяется функциональная модель системы

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

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

КЛ>Здравствуйте, minorlogic, Вы писали:

M>>Утверждение часто корректное, но бывают и ситуации когда грамотно выбраная функциональность и интерфейс сильно сильно расширяют функциональность компонента. Например функциональность описанная как "методы обхода 25 разных коллеций и последовательностей" можно реализовать очень толсто и очень гетерогенно. А можно использовать интерфейс "итератор" с компактной функциональностью и узким интерфейсом.

КЛ>На мой взгляд, грамотное решение этой задачи кроется не в интерфейсе, а в грамотном определении функций (== обязанностей) и делегировании их соответствующим компонентам.

КЛ>Чтобы сделать код последовательного обхода коллекции независимым от типа коллекции, нужно, чтобы кто-то предоставлял такие функции:

КЛ>(1) Получение текущего элемента коллекции
КЛ>(2) Переход к следующему элементу коллекции
КЛ>(3) Проверка, достигли ли мы определенного элемента коллекции

КЛ>Собственно, эти функции и предоставляет компонент итератор.

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

M>>Тогда нет, неверно. Декомпозиция на компоненты и затем распределение функциональности по ним , не должно быть разделено на этапы. Это один и тот же этап. Отделяя компонент из системы мы отделяем его уже по той ответственности которую он несет. Компонент это не его "название" это его ответственность.

КЛ>Отчасти — согласен, а отчасти — нет. Обычно я проектирую систему в таком порядке:

КЛ>(1) Создаю функциональную модель
КЛ>(2) Упорядочиваю функции в порядке выполнения (т.е. описываю процесс, в котором программа или подсистема будет делать то, ради чего создаётся)
КЛ>(3) Делегирую функции отдельным компонентам, которые, на первых парах, обзываю именами, производными от названия функций
КЛ>(4) Мысленно проверяю, как будет работать система, не будет ли каких-то сбоев при взаимосвязи между компонентами
КЛ>(5) Вношу изменения в п.п. 3 и 4 и повторяю п. 5. Иногда, при этом, приходится возвращаться к п. 1, т.к. уточняется/изменяется функциональная модель системы

КЛ>Всё это, конечно, не точный алгоритм, но некоторое приближение к нему.

Описанный процесс выглядит разумным. В пункте 4 вы тоже не описали по каким критериям вы будете сравнивать те варианты которые получились а пункте 3.

КЛ>Мысль, которую я хотел бы подчеркнуть, заключается в том, что процесс выявления функций, делегирования их отдельным компонентам, а затем — перераспределения функций между компонентами — итеративный. И скорее всего, распределение функций между компонентами нельзя выполнить удовлетворительно за один проход. Обязательно нужен этап мысленного моделирования того, как система будет функционировать, чтобы найти возможные сбои.

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

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

M>Конечно, звучит разумно. Но инсайт в этом решении не в самом итераторе, а в том чтобы допустить саму возможность "код последовательного обхода коллекции независимым от типа коллекции". Т.е. самое это допущение и есть великолепное архитектурное решение.

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

В самом деле, можно рассуждать двумя способами:

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

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

(Б) Имеется функция итерации по некоей коллекции. Нужно подумать, к каким коллекциям она может быть применена.

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

КЛ>>Отчасти — согласен, а отчасти — нет. Обычно я проектирую систему в таком порядке:

КЛ>>(1) Создаю функциональную модель
КЛ>>(2) Упорядочиваю функции в порядке выполнения (т.е. описываю процесс, в котором программа или подсистема будет делать то, ради чего создаётся)
КЛ>>(3) Делегирую функции отдельным компонентам, которые, на первых парах, обзываю именами, производными от названия функций
КЛ>>(4) Мысленно проверяю, как будет работать система, не будет ли каких-то сбоев при взаимосвязи между компонентами
КЛ>>(5) Вношу изменения в п.п. 3 и 4 и повторяю п. 5. Иногда, при этом, приходится возвращаться к п. 1, т.к. уточняется/изменяется функциональная модель системы

КЛ>>Всё это, конечно, не точный алгоритм, но некоторое приближение к нему.

M>Описанный процесс выглядит разумным. В пункте 4 вы тоже не описали по каким критериям вы будете сравнивать те варианты которые получились а пункте 3.

Критериев, обычно несколько. Например:

(1) Если усложнить функциональную модель, например, добавить еще одну полезную функцию, не придется ли задавать иной порядок выполнения функций (п. 2)? И не "разлетится ли к чертям" созданная компонентная модель? Т.е. проверяю архитектуру на функциональную расширяемость.

(2) Если поддержать в программе обработку дополнительных объектов (например, генерацию отчетов другого вида или поддержку других форматов входных и выходных данных), то насколько устойчивой окажется построенная модель? Т.е. проверяю архитектуру на объектную расширяемость.

Есть, конечно, и другие критерии.

M>Попытки создать дизайн приложения 1 раз начисто, я бы назвал наивными, или я не достиг таких высот. Мне обычно еще и прототипировать приходится по нескольку раз, то или иное решение. А так же проходить дизайн ревью с коллегами, которые часто указывают на ляпы и ошибки.

Согласен.

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

КЛ>Посмотрите здесь

Автор: Кирилл Лебедев
Дата: 08.10.10

.

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

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

КЛ>Итак, какие будут предложения?

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

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

ZS>Уважаемый Кирилл Лебедев, да пойми, что решать задачу в рамках ее постановки — не в традициях русской школы программирования. Цель российского программиста — не решение задачи, а счастье для всех и мир во всем мире. А ты упорно соврачиваешь все к найму архитектора, хотя к счастью этот путь не ведет, о чем не раз было сказано в ответах.

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

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

КЛ>Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект.
Я давно понял, что ты форумом ошибся

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

КЛ>Здравствуйте, ZevS, Вы писали:

ZS>>Уважаемый Кирилл Лебедев, да пойми, что решать задачу в рамках ее постановки — не в традициях русской школы программирования. Цель российского программиста — не решение задачи, а счастье для всех и мир во всем мире. А ты упорно соврачиваешь все к найму архитектора, хотя к счастью этот путь не ведет, о чем не раз было сказано в ответах.

КЛ>Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект.

А может всетаки потрудишься объяснить что ты понимаешь под архитектором. Потому что видима у большинства это понимание не совпадает.