, обсуждение которой пошло негладко. Поэтому у меня большая просьба к коллегам в данной теме высказываться по-существу — хотя бы для удобства людей, которые её будут читать.
Предыстория: Некая компания ищет архитектора на проект, который предполагает рефакторинг. Не исключено, что руководитель отдела разработки этой компании ошибается, и проекту в большей степени требуется грамотный технический лидер, нежели архитектор, или же и архитектор, и тех. лидер в одном лице.
Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:
(1) картографические данные, хранящиеся в БД на сервере;
(2) визуализация этих картографических данных, хранящаяся на другом сервере.
Дело в том, что с частью (1) работает огромное число пользователей. А наша система относится к части (2), с которой работает лишь небольшое подмножество пользователей части (1).
Основная проблема заключается в том, что пользователи части (2) вынуждены синхронизировать вручную визуальную информацию с актуальной картографической. Ситуация осложняется тем, что подобная синхронизация (== создание растрового изображения) занимает длительное время — несколько часов.
Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.
Подходы к решению:
1) Система (2) автоматически следит за данными в системе (1) и, если они обновились, перегенерирует растровое изображения изменённых участков. Недостаток: система (2) должна хранить данные из системы (1) для того, чтобы узнать, что они обновились.
2) Встроиться каким-либо образом между пользователями системы (1) и конечной базой данных для системы (1), чтобы отлавливать запросы на изменение данных. Если данные изменяются, то посылать уведомление системе (2) для того, чтобы она перегенерировала растровые изображения для изменённых данных.
3) Поработать над сокращением времени генерации растрового изображения.
Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
Как проводят собеседования кандидата:
1) Просят рассказать о предыдущем опыте проектирования систем.
2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов.
3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.
По п.п. 1 и 2 формально время не ограничивают. Но если за 5 минут кандидат не нарисует на бумаге дизайн системы, быстро теряют интерес и перебивают.
Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
Как следствие, не понимают:
(1) важность перевода задачи из формы, как она сформулирована заказчиком (например, "спроектируйте текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов") в форму, пригодную для выработки технического решения;
(2) важность написания юз-кейсов для выполнения п. (1).
Резюме: ИМХО, подобный вариант проведения собеседования с архитектором не является эффективным.
Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:
(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.
Просьба высказывать свои варианты и свои точки зрения.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
КЛ>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором.
Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать.
Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
1. Важно чтобы был опыт в прикладной области.
2. 5 минут на наброски архитектуры крайне мало, за 5 минут даже требования тяжело представить
3. Лучше задачу близкую к прикладной области.
4. Можно давать задачу4 по серверам целиком и спросить варианты решения проблем.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
КЛ>>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором.
G>Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать. G>Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
Судя по статьям автора треда и его мессагам, он на самом деле спрашивает и про требования к архитектору Т.е. первое сообщение редуцируется к такому виду:
1. Какие требования к тимлиду-архитектору
2. Как эти требования проверять
Все это с учетом описаного им контекста.
Материал из Википедии — свободной энциклопедии, -_*
-_*>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>>Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
КЛ>>>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором.
G>>Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать. G>>Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
-_*>Судя по статьям автора треда и его мессагам, он на самом деле спрашивает и про требования к архитектору Т.е. первое сообщение редуцируется к такому виду:
-_*>
-_*>1. Какие требования к тимлиду-архитектору
-_*>2. Как эти требования проверять
-_*>Все это с учетом описаного им контекста.
-_*>
На это как-бы есть серьезные описания, найти можно тут, правда они не соответствуют тому что пытается узнать ТС.
Здравствуйте, gandjustas, Вы писали:
G>На это как-бы есть серьезные описания, найти можно тут, правда они не соответствуют тому что пытается узнать ТС.
Я как то плохо понимаю эти описания.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>1) Просят рассказать о предыдущем опыте проектирования систем. КЛ>2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов.
Ну я конечно не совсем архитектор, но как-то круто это за 5 мин, область то специфичная (пару таких известных редакторов я видел изнутри и дорабатывал, там ужас был еще тот). КЛ>3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений. КЛ>По п.п. 1 и 2 формально время не ограничивают. Но если за 5 минут кандидат не нарисует на бумаге дизайн системы, быстро теряют интерес и перебивают.
А судьи кто? Кто оценивает дизайн? Их квалификация достаточна?
КЛ>Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
Если вы про редактор, то в п2 задача сформулирована в достаточном объеме для собеседования, и уточнять на собеседовании будут зануды или чисто чтобы до вас докопаться. ИМХО. Ну и это постановщика задачь дело.
В п3 вероятно конечно должны задавать доп. вопросы, но это другое.
А почему-бы в лоб не спросить на собеседовании, что вы будете делать с такой системой? И послушать что спросят и предложат.
Архитектор должен спросить, как минимум:
1) Примерный объем данных в БД?
2) Доступность этой БД?
3) Скорость загрузки данных из БД?
4) Как часто обновляются данные в БД?
5) Насколько критично для пользователей иметь самую последнюю версию?
6) Создаются растры фиксированных областей? Сколько времени генерится растр в среднем? Юзерам нужны все растры сразу или только часть?
7) Нагрузка на систему 2?
8) Что за БД в системе 1?
9) Может внедриться в систему 1 всеже можно, если сильно попросить ее владельцев?
Что должен предложить (очень сильно зависит от ответов на вопросы, я напишу все варианты что пришли в голову):
1) Генерить растры на лету, возможно кэшировать сгенеренные пока не устареют по времени
2) Сделать себе реплику БД, которую постоянно сравнивать с оригиналом и обновлять как БД, так и растры. Либо генерить на лету как в п1 но с реплики (возможно скорость повысится, если удаленая БД — тонкое место)
3) Пересмотреть GUI того места где используются растры, что даст возможность использовать п1
4) Ускорить генерацию растров (вы писали)
5) Внедриться в систему 1 для отлова изменений (вы писали)
6) Распределить нагрузку
Если будут адекватные ответы, потом уже погонять на предмет его возможностей реализовать это в жизнь.
Здравствуйте, gandjustas, Вы писали:
G>Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать.
В данном обсуждении мне хотелось бы остановиться на функции проектирования (== конструирования) систем, посложнее класса.
G>Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
Возможно, он будет, помимо проектирования, ещё играть роли тимлида и/или ПМа. Но в данном обсуждении мне бы не хотелось это рассматривать.
Здравствуйте, minorlogic, Вы писали:
M>1. Важно чтобы был опыт в прикладной области.
Нередко трудно найти человека, который разбирается в прикладной области и удовлетворяет остальным требованиям (например, умеет проектировать сложные системы "с нуля").
Приведу примеры из реальной жизни.
Пример 1. Одна из питерских игровых компаний решила открыть новое направление — разработку 3D-игр для консоли Nintendo Wii. На тот момент, когда направление открывалось, специалистов по разработке игр для Wii в Питере просто не было. Такого человека можно было искать годами с заранее известным результатом.
Пример 2. Другая питерская компания получила заказ на разработку GPS-навигационной системы для мобильного телефона одного из производителей. Опыта разработки таких систем у компании не было. Специалистов по разработке таких систем в Питере в те годы можно было пересчитать по пальцам. Более того, для того времени встраивание GPS-навигации не в смартфон, а в обычный сотовый телефон — было вообще пионерным направлением. Сколько времени эта компания искала бы себе сотрудников, если бы ориентировалась на "опыт в прикладной области"?
M>2. 5 минут на наброски архитектуры крайне мало, за 5 минут даже требования тяжело представить M>3. Лучше задачу близкую к прикладной области. M>4. Можно давать задачу4 по серверам целиком и спросить варианты решения проблем.
ИМХО, за 5 минут такие задачи не решаются. Чтобы предложить какие-то более-менее работоспособные варианты решения реальных промышленных задач, нужно выполнить этап постановки задачи, который переводит исходную проблему из формулировки заказчика в упорядоченный набор технических задач. Кто-то приводил цитату, что грамотная поставленная задача — это уже наполовину решённая задача.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Нередко трудно найти человека, который разбирается в прикладной области и удовлетворяет остальным требованиям (например, умеет проектировать сложные системы "с нуля").
И что это меняет? Если у тебя будет выбор между кандидатом с опытом в прикладной области и без, кому ты отдашь предпочтение при прочих равных? А если выбора нет, то прочие критерии никто не отменяет. А еще есть такой критерий как положительное личное знакомство (по прошлым работам, через знакомых), который может пересилить многие профильные.
Вообще, я думаю, что общий подход тут выработать не получится. Максимум — базовые принципы, которые нужно подстравивать под каждый конкретный случай. Пример ты привел сам, и, очевидно, можешь еще привести немало. Ограничения приведенные тобой —
интересен общий подход к проведению собеседования с архитектором:
(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.
сужают задачу, но не на столько, что бы можно было уверенно обобщать. К ним можно добавить:
(1) доступность специалистов на рынке труда
(2) размер предлагаемой компенсации
(3) сроки
(4) характер проекта: стартап, "одноразовый" проект, долгосрочный проект с последующим сопровождением, легаси...
(5) размер проекта
(6) дополнительные обязанности кандидата: тим лидерство, бизнес-анализ...
(7) еще что-то...
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать. КЛ>В данном обсуждении мне хотелось бы остановиться на функции проектирования (== конструирования) систем, посложнее класса.
А почему он называет тогда "архиектором", а не просто программистом? Любой программист уровнем выше начинающего должен это уметь.
G>>Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа. КЛ>Возможно, он будет, помимо проектирования, ещё играть роли тимлида и/или ПМа. Но в данном обсуждении мне бы не хотелось это рассматривать.
Круто блин, архитектор, тимлид и менеджер в одном лице... Если об этом сказать на собеседовании, то любой здравомыслящий человек откажется.
Кстати вопрос про отличия архитектора от других ролей остался неотвеченным, а он очень важный чтобы понимать круг обязанностей этого самого архитектора.
Здравствуйте, ZevS, Вы писали:
ZS>И что это меняет? Если у тебя будет выбор между кандидатом с опытом в прикладной области и без, кому ты отдашь предпочтение при прочих равных?
Вся фишка в том, что "прикладная область" — понятие растяжимое. Нередко в одном проекте переплетены разные прикладные области. И трудно найти кандидата, знания которых перекрывали бы все эти области или большую часть из них. В этом случае, бывает так, что заказчик ищет кандидата со знаниями прикладной области, которая ему (заказчику!) представляется наиболее проблемной. Условно назовём эту область "А". Но в ходе работы над проектом может оказаться, что наиболее проблемной окажется другая прикладная область — "Б", о которой заказчик совсем не подозревал или же думал, что она не представляет проблемы, а с прикладной областью "А" вообще не оказалось никаких проблем.
Получается "циклическая ссылка". С одной стороны, чтобы снизить риск проекта, нужны специалисты в отдельных прикладных областях, которые знают, как решать задачи, специфичные для своих областей. С другой стороны, чтобы понять, какие вообще нужны специалисты и какие задачи (==прикладные области) будут главными, нужно, чтобы был человек, который бы посмотрел на весь проект в целом и сделал хотя бы предварительную декомпозицию задач, но, опять-таки, хотелось бы, чтобы этот человек разбирался хотя бы в части прикладных областей.
На мой взгляд, данная "циклическая ссылка" разруливается таким образом:
(1) Ищется человек с опытом проектирования сложных программных систем (не важно, из какой области). Этот человек делает декомпозицию исходной глобальной задачи на серию более мелких и более конкретных технических задач.
(2) Для решения сформулированных задач набираются специалисты соответствующего профиля.
ZS>Вообще, я думаю, что общий подход тут выработать не получится. Максимум — базовые принципы, которые нужно подстравивать под каждый конкретный случай. Пример ты привел сам, и, очевидно, можешь еще привести немало. Ограничения приведенные тобой — ZS>сужают задачу, но не на столько, что бы можно было уверенно обобщать. К ним можно добавить:
Мне бы хотелось проверить такое качество кандидата, как умение проектировать системы, посложнее класса.
Здравствуйте, gandjustas, Вы писали:
G>А почему он называет тогда "архиектором", а не просто программистом? Любой программист уровнем выше начинающего должен это уметь.
Дело ведь не в названии, а в выполняемых функциях, правильно?
G>Кстати вопрос про отличия архитектора от других ролей остался неотвеченным, а он очень важный чтобы понимать круг обязанностей этого самого архитектора.
Давай сконцентрируемся в данном обсуждении на одной обязанности — проектирование, а про остальные — забудем, хорошо? Иначе мы просто рискуем расширить тему обсуждения так, что с ней не справимся.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>А почему он называет тогда "архиектором", а не просто программистом? Любой программист уровнем выше начинающего должен это уметь. КЛ>Дело ведь не в названии, а в выполняемых функциях, правильно?
Вот и уже черт знает какой раз спрашиваю о функциях, которые нужны и которые не нужны.
G>>Кстати вопрос про отличия архитектора от других ролей остался неотвеченным, а он очень важный чтобы понимать круг обязанностей этого самого архитектора.
КЛ>Давай сконцентрируемся в данном обсуждении на одной обязанности — проектирование, а про остальные — забудем, хорошо?
Ок, забудем. Что есть "проектирование" как оно должно выражаться?
В каких пределах человек должен заниматься проектированием? Если касается только проектирования частей программы по заранее сформулированным требованиям, то это обычный программист и тем про найм программистов куча. Чтобы решать задачу, озвученную ранее, нужен программист уровнем чуть выше среднего со знаниями в определенной области.
Здравствуйте, gandjustas, Вы писали:
КЛ>>Давай сконцентрируемся в данном обсуждении на одной обязанности — проектирование, а про остальные — забудем, хорошо? G>Ок, забудем. Что есть "проектирование" как оно должно выражаться?
Подозреваю, что, получив ответ на этот вопрос, можно будет составить адекватный тест с гораздо меньшими усилиями. В этом и состоит задача.
G>В каких пределах человек должен заниматься проектированием? Если касается только проектирования частей программы по заранее сформулированным требованиям, то это обычный программист и тем про найм программистов куча.
Подозреваю, что в реальной жизни не бывает "заранее сформулированных требований". Обычно требования к системе изменяются в процессе проектирования.
G>Чтобы решать задачу, озвученную ранее, нужен программист уровнем чуть выше среднего со знаниями в определенной области.
Про "определённую область" рассказано в предыстории. Но в реальности тяжело найти хорошего проектировщика со знаниями в "определённой области", ИМХО.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
С виду в задаче нет ничего уникального. От кандидата требуется иметь опыт реализации высоконагруженных серверных приложений работающих в режиме 24 * 7. Сложность только в том как понять, что человек не просто участвовал в разработке такой системы, а играл в этом ключевую роль. По идее проще всего это выяснить в беседе о том какие проблемы были встречены при реализации, как их решали, как производилось расширение и добавление функциональности.
КЛ>Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.
Чудес не бывает. Если у вас нет информации о произошедших изменениях в источнике, а пребразование информации очень длительное и тяжелое, то в любом случае все сведется к периодическому полному перестроению изображения (допустим, раз в сутки) + внеочередным перестроениям некоторых кусков по ручным заявкам.
КЛ>1) Просят рассказать о предыдущем опыте проектирования систем. КЛ>2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов. КЛ>3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.
Это очень плохой способ. Кандидата надо спрашивать о его предыдущей работе, а не о будущей. Т.к. за пять минут даже понять, что из себя представляет новая задача нельзя, не говоря уж о том, чтобы предложить обдуманное решение.
КЛ>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:
КЛ>(1) на разработку нового проекта с нуля;
Повторюсь. Требуется опыт реализации принципиально схожих вещей, т.е. в вашем случае высоконагруженных серверных приложений.
КЛ>(2) на масштабный рефакторинг готового проекта.
Опыт поддержки сложной системы написанной другими программистами, а также опыт постепенного переписывания отдельных частей такой системы. Лучше всего если кандидат объяснит какие куски в такой системе дорабатывались, какие затем были переписаны, по каким причинам это происходило и с какими сложностями столкнулись.
Здравствуйте, Undying, Вы писали:
U>Чудес не бывает. Если у вас нет информации о произошедших изменениях в источнике, а пребразование информации очень длительное и тяжелое, то в любом случае все сведется к периодическому полному перестроению изображения (допустим, раз в сутки) + внеочередным перестроениям некоторых кусков по ручным заявкам.
На мой взгляд, в поисках решения можно "покопать" в трёх направлениях:
(1) найти способ встроиться в систему (1) с тем, чтобы получать уведомления об изменении данных;
(2) найти способ хранить в системе (2) информацию о данных в системе (1) в компактном виде так, чтобы периодически можно было отслеживать изменения;
(3) разобраться, почему генерация растрового изображения занимает так много времени.
U>Это очень плохой способ. Кандидата надо спрашивать о его предыдущей работе, а не о будущей. Т.к. за пять минут даже понять, что из себя представляет новая задача нельзя, не говоря уж о том, чтобы предложить обдуманное решение.
Согласен. За пять минут такие задачи не решаются...
U>Повторюсь. Требуется опыт реализации принципиально схожих вещей, т.е. в вашем случае высоконагруженных серверных приложений.
А вот это интересный момент. Можешь аргументировать свою точку зрения? Каким образом опыт создания "высоконагруженных серверных приложений" поможет решить указанную проблему?
U>Опыт поддержки сложной системы написанной другими программистами, а также опыт постепенного переписывания отдельных частей такой системы. Лучше всего если кандидат объяснит какие куски в такой системе дорабатывались, какие затем были переписаны, по каким причинам это происходило и с какими сложностями столкнулись.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>На мой взгляд, в поисках решения можно "покопать" в трёх направлениях:
КЛ>(1) найти способ встроиться в систему (1) с тем, чтобы получать уведомления об изменении данных; КЛ>(2) найти способ хранить в системе (2) информацию о данных в системе (1) в компактном виде так, чтобы периодически можно было отслеживать изменения; КЛ>(3) разобраться, почему генерация растрового изображения занимает так много времени.
Это все правильно, но архитектурная сложность этих направлений довольно мала.
Т.е. в любом случае система будет состоять из очереди внеочередных запросов и периодического пересоздания всей карты. Просто если удастся реализовать первый пункт, то очередь внеочередных запросов будет формироваться не в ручную, а автоматически. Если второй, т.е. удастся допустим добиться, что проверка изменений в компактном формате будет в десять раз быстрее, чем перестроение, то перестраивать надо будет только измененные куски, соответственно полное перестроение карты можно будет производить не раз в сутки, а скажем раз в 3 часа. Если удастся ускорить генерацию изображения, то в архитектуру вообще никаких изменений вносить будет не нужно, просто можно будет перестраивать карту чаще.
Соответственно для решения конкретно этих задач архитектор не нужен, достаточно толкового программиста, желательно способного писать достаточно сложные алгоритмы. Соответственно при собеседовании упор нужно делать насколько сложные преобразования данных кандидат писал.
КЛ>А вот это интересный момент. Можешь аргументировать свою точку зрения? Каким образом опыт создания "высоконагруженных серверных приложений" поможет решить указанную проблему?
Как я понимаю, ключевую роль в вашей системе играет серверный сервис, который время от времени опрашивает сервер источник карт, получает с него карты, перекодирует их в свой формат и затем позволяет забирать клиентам. Написание серверных приложений требует высокой надежности, работы с многопоточностью, полного отсутствия утечек ресурсов и т.п. специфики. Соответственно человек с опытом написания только десктопных программ не факт что окажется в этом силен, т.к. в этом отношении требования к десктопным программам как правило гораздо ниже.
Re: Как собеседовать архитектора (методические рекомендации)
Предположим, существует идеальная методика, которая позволяет эффективно решать задачи проектирования.
Предположим также, что с точки зрения методики совершенно неважно, какого рода приложения будут проектироваться – консольные игры или высоконагруженные сервера. Методика помогает для каждой ситуации выявлять необходимые задачи и их решать.
Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:
(1) Если архитектор в процессе проектирования следует рекомендациям методики, то мы считаем его квалифицированным.
(2) Если архитектор в процессе проектирования не следует рекомендациям методики, то мы упрощаем себе жизнь и считаем его неквалифицированным.
Попробуем предположить, какой должна быть эта методика.
Часть А. Постановка задачи.
А.1. Выполняется ли процедура постановки задачи?
А.2. Подразумевает ли эта процедура декомпозицию исходной задачи на подзадачи?
А.3. Какие используются критерии для декопозиции?
А.4. Каким образом гарантируется, что ни одна существенная подзадача не будет пропущена?
А.5. Выполняется ли ранжирование подзадач?
А.5.1. Если да, то по каким критериям?
Часть Б. Построение функциональной модели системы.
Б.1. Выявляются ли функциональные требования к системе?
Б.1.1. Понимает ли кандидат, что программа пишется не ради красивой иерархии классов и не для того, чтобы что-то хранить, а для того, чтобы что-то делать.
Б.2. Каким образом выявляются функциональные требования?
Б.3. Упорядочиваются ли функциональные требования каким-либо образом?
Б.3.1. Если да, то каким?
Б.4. Как решается проблема, если функциональных требований слишком много?
Б.5. Как решается проблема, когда функцональных требований слишком мало?
Б.6. Как решается проблема, когда в задании вообще нет функциональных требований?
Часть В. Проектирование технологического процесса.
В.1. Создаётся ли модель функционирования системы?
В.2. С какой точки зрения описывается эта модель?
В.2.1. С точки зрения внешнего пользователя?
В.2.2. С точки зрения проектируемой системы?
В.3. Насколько детально составлена данная модель?
В.3.1. Если первоначально модель составлена поверхностно, то выполняется ли в дальнейшем процедура детализации?
В.3.1.1. Что она из себя представляет?
В.4. Насколько технологична данная модель?
В.4.1. Решена ли в данной модели проблема сложности?
В.4.1.1. Если решена, то каким образом?
В.4.2. Решена ли в данной модели проблема циклических ссылок?
Примечание: Циклическая ссылка возникает, когда для выполнения операции Б нужно сначала выполнить операцию А, а для выполнения операции А – нужно предварительно выполнить операцию Б.
В.4.2.1. Если решена, то каким образом?
В.4.3. Как решается проблема производительности?
В.4.3.1. Присутствуют ли в модели длительные операции, которые по времени выполнения сильно отличаются от времени выполнения остальных операций?
В.4.3.2. Если такие операции присутствуют, то предполагается ли борьба с ними? Каким образом?
В.4.4. Имеются ли противоречивые требования к модели со стороны внешних систем?
В.4.4.1. Если да, то как они устраняются?
Часть Г. Проектирование компонент и взаимосвязей.
Г.1. На основе каких критериев выделяются компоненты?
Г.1.1. На основе объектов предметной области? (Неправильно)
Г.1.2. На основе обязанностей? (Правильно)
Г.2. На основе каких критериев компоненты объединяются в блоки (например, классы – в иерархии)?
Г.2.1. На основе общности свойств и атрибутов? (Неправильно)
Г.2.2. На основе общности функций? (Правильно)
Г.3. Каким образом распределяются обязанности между компонентами?
Г.4. Каким образом решается проблема циклических ссылок между компонентами?
Г.4.1. Решается ли она вообще?
Г.5. Из каких соображений проектируется интерфейс компонента?
Г.6. Проектируются ли передаточные звенья?
Примечание: Под передаточными звеньями здесь понимаются структуры данных, используемые для связи между взаимодействующими компонентами?
Часть Д. Проектирование структуры компонента.
Д.1. Каким образом проектируется внутренняя структура компонента?
Д.2. На основе каких критериев различные свойства объединяются в компонент/класс?
Д.2.1. На основе принадлежности одному объекту [предметной области]? (Неправильно)
Д.2.2. На основе функциональной значимости (используются в функциях компонента)? (Правильно)
Д.3. Соответствует ли внутренняя структура компонента его обязанностям (его функциональной модели)?
Д.4. Соответствует ли внутренняя структура компонента требованиям по производительности?
Д.5. Предъявляют ли разные функции компонента противоречивые требования к данным?
Д.5.1. Если да, то как эти противоречия разрешаются?
Часть Е. Проверка.
Е.1. Выполняется ли проверка решения на функциональную расширяемость? Насколько сильно изменится дизайн системы, если потребуется выполнение дополнительных функций?
Е.2. Выполняется ли проверка решения на объектную расширяемость? Как изменится система, если потребуется поддержать новые объекты, например, данные в новом формате?
Е.3. Выполняется ли проверка решения на количественную расширяемость? Что произойдёт с архитектурой системы, если количество обрабатываемых объектов увеличть в 10 – 100 – 1000 раз?
Т.е. первое сообщение редуцируется к такому виду:
