Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
С виду в задаче нет ничего уникального. От кандидата требуется иметь опыт реализации высоконагруженных серверных приложений работающих в режиме 24 * 7. Сложность только в том как понять, что человек не просто участвовал в разработке такой системы, а играл в этом ключевую роль. По идее проще всего это выяснить в беседе о том какие проблемы были встречены при реализации, как их решали, как производилось расширение и добавление функциональности.
КЛ>Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.
Чудес не бывает. Если у вас нет информации о произошедших изменениях в источнике, а пребразование информации очень длительное и тяжелое, то в любом случае все сведется к периодическому полному перестроению изображения (допустим, раз в сутки) + внеочередным перестроениям некоторых кусков по ручным заявкам.
КЛ>1) Просят рассказать о предыдущем опыте проектирования систем. КЛ>2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов. КЛ>3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.
Это очень плохой способ. Кандидата надо спрашивать о его предыдущей работе, а не о будущей. Т.к. за пять минут даже понять, что из себя представляет новая задача нельзя, не говоря уж о том, чтобы предложить обдуманное решение.
КЛ>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:
КЛ>(1) на разработку нового проекта с нуля;
Повторюсь. Требуется опыт реализации принципиально схожих вещей, т.е. в вашем случае высоконагруженных серверных приложений.
КЛ>(2) на масштабный рефакторинг готового проекта.
Опыт поддержки сложной системы написанной другими программистами, а также опыт постепенного переписывания отдельных частей такой системы. Лучше всего если кандидат объяснит какие куски в такой системе дорабатывались, какие затем были переписаны, по каким причинам это происходило и с какими сложностями столкнулись.
1. Важно чтобы был опыт в прикладной области.
2. 5 минут на наброски архитектуры крайне мало, за 5 минут даже требования тяжело представить
3. Лучше задачу близкую к прикладной области.
4. Можно давать задачу4 по серверам целиком и спросить варианты решения проблем.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>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>Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать. G>Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
Судя по статьям автора треда и его мессагам, он на самом деле спрашивает и про требования к архитектору Т.е. первое сообщение редуцируется к такому виду:
1. Какие требования к тимлиду-архитектору
2. Как эти требования проверять
Все это с учетом описаного им контекста.
Материал из Википедии — свободной энциклопедии, -_*
Re[2]: Как собеседовать архитектора (методические рекомендац
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:
Методика крайне формализована и, как следствие, совершенно непонятно как ответы на изложенные в ней вопросы приближают нас к решению реальной задачи. Соответственно опираясь на такую методику на собеседовании вы автоматом отсеете всех практиков, хотя казалось бы цель преследовали прямо противоположную:
Б.1.1. Понимает ли кандидат, что программа пишется не ради красивой иерархии классов и не для того, чтобы что-то хранить, а для того, чтобы что-то делать.
Соответственно хочется задать вопрос:
Понимает ли автор методики, что программисты существуют не для красивых ответов на абстрактные вопросы, а для того, чтобы решать реальные задачи?
, обсуждение которой пошло негладко. Поэтому у меня большая просьба к коллегам в данной теме высказываться по-существу — хотя бы для удобства людей, которые её будут читать.
Предыстория: Некая компания ищет архитектора на проект, который предполагает рефакторинг. Не исключено, что руководитель отдела разработки этой компании ошибается, и проекту в большей степени требуется грамотный технический лидер, нежели архитектор, или же и архитектор, и тех. лидер в одном лице.
Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:
(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) на масштабный рефакторинг готового проекта.
Просьба высказывать свои варианты и свои точки зрения.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
КЛ>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором.
Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать.
Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
-_*>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>>Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
КЛ>>>Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором.
G>>Специально оставил два предложения. Ты попадаешь в ту же ловушку, не формулируешь требования к архитектору, но при этом пытаешься его собеседовать. G>>Выпиши так же развернуто в чем ты видишь задачи архитектора и чем он будет отличаться от программиста\тимлида\аналитика\ПМа.
-_*>Судя по статьям автора треда и его мессагам, он на самом деле спрашивает и про требования к архитектору Т.е. первое сообщение редуцируется к такому виду:
-_*>
-_*>1. Какие требования к тимлиду-архитектору
-_*>2. Как эти требования проверять
-_*>Все это с учетом описаного им контекста.
-_*>
На это как-бы есть серьезные описания, найти можно тут, правда они не соответствуют тому что пытается узнать ТС.
Здравствуйте, gandjustas, Вы писали:
G>На это как-бы есть серьезные описания, найти можно тут, правда они не соответствуют тому что пытается узнать ТС.
Я как то плохо понимаю эти описания.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, 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>Чтобы решать задачу, озвученную ранее, нужен программист уровнем чуть выше среднего со знаниями в определенной области.
Про "определённую область" рассказано в предыстории. Но в реальности тяжело найти хорошего проектировщика со знаниями в "определённой области", ИМХО.
Здравствуйте, 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 раз?
Здравствуйте, Undying, Вы писали:
U>Методика крайне формализована и, как следствие, совершенно непонятно как ответы на изложенные в ней вопросы приближают нас к решению реальной задачи.
Ты имеешь в виду задачу проектирования? Вопрос закономерен, но ответ на него выходит за рамки данной темы. Если кратко, то ты уже заметил, что методика состоит из 6 частей:
(1) постановка задачи;
(2) построение модели функционирования системы;
(3) и т.д.
Каждая часть, в свою очередь, делится на несколько шагов.
Есть гипотеза, подтверждённая практикой: если проектировщик последовательно и добросовестно выполняет эти шаги, то на выходе получается адекватный дизайн системы.
Гипотеза проверена на разных продуктах: GPS-навигации, файловых базах данных, играх и т.д. Пока результат хороший. Чуть позже в своём блоге и здесь я продемонстрирую это на конкретных примерах.
U>Соответственно опираясь на такую методику на собеседовании вы автоматом отсеете всех практиков, хотя казалось бы цель преследовали прямо противоположную:
Не думаю. Цель методики — очертить круг вопросов для собеседования. Сколько из них задавать кандидату, в какой форме — в виде вопросов, в виде конкретизированных задач по каждому пункту или в виде наблюдения за тем, как решает задачу кандидат — дело человека, проводящего собеседование. Порог для прохождения тоже можно задавать индивидуально. Например, я счёл бы кандидата подходящим на должность проектировщика, если его ответы совпали бы с моими собственными не менее, чем в 30% случаев. Это, ИМХО, уже хороший результат.
U>Понимает ли автор методики, что программисты существуют не для красивых ответов на абстрактные вопросы, а для того, чтобы решать реальные задачи?
Не надо задавать кандидату абстрактные вопросы. Попросите его вам рассказать, как он решал какую-нибудь сложную задачу проектирования на прошлом рабочем месте, попросите его прокомментировать ход решения и сравните — есть ли совпадения с контрольными вопросами методики.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Предположим, существует идеальная методика, которая позволяет эффективно решать задачи проектирования.
КЛ>Предположим также, что с точки зрения методики совершенно неважно, какого рода приложения будут проектироваться – консольные игры или высоконагруженные сервера. Методика помогает для каждой ситуации выявлять необходимые задачи и их решать.
КЛ>Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:
КЛ>(1) Если архитектор в процессе проектирования следует рекомендациям методики, то мы считаем его квалифицированным.
КЛ>(2) Если архитектор в процессе проектирования не следует рекомендациям методики, то мы упрощаем себе жизнь и считаем его неквалифицированным.
КЛ>Попробуем предположить, какой должна быть эта методика.
Осталось доказать что такая методика дает "хороший дизайн кода". Только есть проблема — нету методики оценки хорошести этого самого дизайна.
Кстати указанная методика или аналогичные может (и должна) применяться всеми программистами. Роли архитектора я тут и не увидел.
Здравствуйте, Undying, Вы писали:
U>Это все правильно, но архитектурная сложность этих направлений довольно мала.
Согласен.
U>Соответственно для решения конкретно этих задач архитектор не нужен, достаточно толкового программиста, желательно способного писать достаточно сложные алгоритмы. Соответственно при собеседовании упор нужно делать насколько сложные преобразования данных кандидат писал.
Не исключаю, что подойдёт и такой вариант.
КЛ>>А вот это интересный момент. Можешь аргументировать свою точку зрения? Каким образом опыт создания "высоконагруженных серверных приложений" поможет решить указанную проблему?
U>Как я понимаю, ключевую роль в вашей системе играет серверный сервис, который время от времени опрашивает сервер источник карт, получает с него карты, перекодирует их в свой формат и затем позволяет забирать клиентам. Написание серверных приложений требует высокой надежности, работы с многопоточностью, полного отсутствия утечек ресурсов и т.п. специфики. Соответственно человек с опытом написания только десктопных программ не факт что окажется в этом силен, т.к. в этом отношении требования к десктопным программам как правило гораздо ниже.
Всё, что ты написал, в общем-то разумно, но это — общие соображения. Нить твоих рассуждений понятна:
Нужно сопровождать клиент-серверное приложение — следовательно, нужен специалист с опытом создания "высоконагруженных серверных приложений".
Однако ты так и не сказал, каким образом опыт создания "высоконагруженных серверных приложений" поможет в решении данной конкретной задачи.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Не думаю. Цель методики — очертить круг вопросов для собеседования. Сколько из них задавать кандидату, в какой форме — в виде вопросов, в виде конкретизированных задач по каждому пункту или в виде наблюдения за тем, как решает задачу кандидат — дело человека, проводящего собеседование.
Т.е. это не вопросы для собеседования, а призма через которую оцениваются ответы собеседуемого. Тогда я не прав, оценив их негативно.
В принципе идея методики интересная, но без раскрытия подпунктов приведенная методика зачастую выглядит набором банальностей. Например возьмем постановку задачи:
А.1. Выполняется ли процедура постановки задачи?
Естественно да, иначе откуда исполнитель узнает о поставленной задаче? Т.е. ключевое слово здесь процедура и то что под ней понимается. Как должна выглядеть процедура постановки задачи с твоей точки зрения? С моей это один листочек бумаги, на котором формулируется цель и общие требования к решению.
А.2. Подразумевает ли эта процедура декомпозицию исходной задачи на подзадачи?
Естественно да, физически невозможно всё делать одновременно.
А.3. Какие используются критерии для декопозиции?
Могу ответить только что-то вроде: "ну... эта... чтобы в итоге всё просто получилось", но думаю это не тот ответ, который ты хотел услышать. Какие критерии надо использовать с твоей точки зрения?
А.4. Каким образом гарантируется, что ни одна существенная подзадача не будет пропущена?
Затрудняюсь ответить. Какие образом это можно гарантировать с твоей точки зрения?
А.5. Выполняется ли ранжирование подзадач?
Естественно да, т.к. опять же нельзя все подзадачи делать одновременно.
А.5.1. Если да, то по каким критериям?
Это первый вопрос, на который я могу дать осмысленный ответ. Критерии следующие: 1) зависимость других подзадач от этой подзадачи 2) важность подзадачи 3) сложность подзадачи
Еще меня следующий вопрос заинтересовал:
В.4.2. Решена ли в данной модели проблема циклических ссылок?
Что такой циклические ссылки в разработке? Вроде ни разу не сталкивался. Можно пример привести?
КЛ>Нужно сопровождать клиент-серверное приложение — следовательно, нужен специалист с опытом создания "высоконагруженных серверных приложений".
КЛ>Однако ты так и не сказал, каким образом опыт создания "высоконагруженных серверных приложений" поможет в решении данной конкретной задачи.
В общем случае мою мысль надо перефразировать следующим образом. Для решения данной задачи очень желательно иметь опыт решения серверных задач, т.к. они достаточно специфичны. Однако не обязательно, чтобы этот опыт имел архитектор, при условии что уже есть ведущий специалист с таким опытом. В этом случае следует в первую очередь обращать внимание на собственно архитектурные способности кандидата, т.е. на умение делать сложное простым.
Здравствуйте, Undying, Вы писали:
U>В общем случае мою мысль надо перефразировать следующим образом. Для решения данной задачи очень желательно иметь опыт решения серверных задач, т.к. они достаточно специфичны. Однако не обязательно, чтобы этот опыт имел архитектор, при условии что уже есть ведущий специалист с таким опытом. В этом случае следует в первую очередь обращать внимание на собственно архитектурные способности кандидата, т.е. на умение делать сложное простым.
Ок. Но всё-таки я хотел бы обратить внимание вот на какое обстоятельство: ты попытался судить о навыках требуемого специалиста ДО декомпозиции задачи на части. Исходя из общих соображений. Это я пишу не в упрёк тебе, а просто потому что такая тактика нередко используется заказчиками. Она действительно имеет право на жизнь, но часто не приносит положительных результатов. Почему?
Чтобы ответить на этот вопрос, вернёмся к нашему примеру. Мы сформулировали
(1) найти способ встроиться в систему (1) с тем, чтобы получать уведомления об изменении данных;
(2) найти способ хранить в системе (2) информацию о данных в системе (1) в компактном виде так, чтобы периодически можно было отслеживать изменения;
(3) разобраться, почему генерация растрового изображения занимает так много времени.
Очевидно, что каждый из подходов предъявляет к разработчику разные требования.
Для примера рассмотрим более детально подход № 1. Типовая модель архитектуры JSP выглядит так:
Чтобы отследить изменения в БД, потенциально мы можем встроиться:
1) либо в какой-нибудь компонент этой цепочки, участвующий во взаимодействии;
2) либо между компонентами, модифицировав цепочку.
Мы можем встроиться:
1. в браузер — тогда нам нужен специалист, разбирающийся в том, как писать плагины и компоненты для имеющихся браузеров (IE, Chrome, Firefox, Opera, Safari);
2. в ОС пользователя — тогда нам нужен специалист, который имел опыт в написании фаерволов (т.е. умеет писать программы, которые перехватывают запросы пользователя);
3. в HTTP-сервер — нужен специалист по HTTP-серверам;
4. в сервлет-контейнер — нужен специалист по Tomcat'у;
5. в БД — нужен "баз-даннщик" .
В зависимости от выбранного подхода и конкретного варианта решения меняются и требования к специалисту.
Очевидно, если мы выберем третий подход, т.е. будем разбираться в том, почему растровое изображение генерируется так долго, то нам потребуется программист, хорошо подкованный в алгоритмах (это если пишем алгоритм заново), или же специалисты, имеющий опыт в проведении оптимизаций (это если решаем оставить текущий алгоритм, но решили устранить причины низкой скорости его работы).
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ок. Но всё-таки я хотел бы обратить внимание вот на какое обстоятельство: ты попытался судить о навыках требуемого специалиста ДО декомпозиции задачи на части. Исходя из общих соображений. Это я пишу не в упрёк тебе, а просто потому что такая тактика нередко используется заказчиками. Она действительно имеет право на жизнь, но часто не приносит положительных результатов. Почему?
В первую очередь я судил о навыках требуемого специалиста в условиях недостатка и противоречивости информации. С одной стороны изначально было сказано что требуется архитектор, с другой стороны чуть позже была приведена конкретную проблему, любое из решений которой архитектуру практически не затрагивает.
КЛ>В зависимости от выбранного подхода и конкретного варианта решения меняются и требования к специалисту.
Во многом согласен, но не понятно причем здесь архитектор.
Здравствуйте, AlexVinS, Вы писали:
AVS>Другое дело, что какая-то определённая методика (причем при решении различных задач, возможно, различная) должна каждым архитектором использоваться.
Об этом и речь. Наблюдая за тем, как архитектор решает задачу, можно составить представление о его методике проектирования и с помощью приведённых контрольных вопросов её качественно оценить.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, AlexVinS, Вы писали:
AVS>>Другое дело, что какая-то определённая методика (причем при решении различных задач, возможно, различная) должна каждым архитектором использоваться.
КЛ>Об этом и речь. Наблюдая за тем, как архитектор решает задачу, можно составить представление о его методике проектирования и с помощью приведённых контрольных вопросов её качественно оценить.
Вот тут я не согласен. Оценить методику можно только по результату целого проекта, остальное — сферические кони в вакууме. Другими словами, "контрольным вопросом" может быть только сам факт четкого следования определённой методике, а качественная оценка методики — это успешность ее использования в сходных проектах.
Умный человек знает не многое, но нужное
Re[5]: Как собеседовать архитектора (методические рекомендац
Здравствуйте, Undying, Вы писали:
U>Т.е. это не вопросы для собеседования, а призма через которую оцениваются ответы собеседуемого.
Да.
U>Естественно да, иначе откуда исполнитель узнает о поставленной задаче? Т.е. ключевое слово здесь процедура и то что под ней понимается. Как должна выглядеть процедура постановки задачи с твоей точки зрения? С моей это один листочек бумаги, на котором формулируется цель и общие требования к решению.
ИМХО, это всего лишь первый шаг в процедуре постановки задачи, который можно назвать "Описание задачи в постановке заказчика". Далее из получившегося описания нужно:
1) убрать всё лишнее (например, нередко заказчик мыслит не в терминах проблем, а в терминах решений, т.е. предлагает свои конкретные технические решения, которые часто не являются грамотными — нужно убрать из постановки эти "шумовые" решения);
2) заменить конкретные решения заказчика (см. п. 1) описанием имеющихся проблем;
3) произвести декомпозицию задачи на ряд конкретных технических и организационных подзадач;
4) упорядочить эти подзадачи.
U>А.3. Какие используются критерии для декопозиции?
U>Могу ответить только что-то вроде: "ну... эта... чтобы в итоге всё просто получилось", но думаю это не тот ответ, который ты хотел услышать. Какие критерии надо использовать с твоей точки зрения?
На мой взгляд, нужно использовать функциональный критерий. Т.е. важно понимать:
а) что проектируемая система будет делать?
б) для чего она это будет делать?
в) и каким образом она это будет делать?
На последний вопрос нужно ответить, хотя бы в первом приближении.
U>А.4. Каким образом гарантируется, что ни одна существенная подзадача не будет пропущена?
U>Затрудняюсь ответить. Какие образом это можно гарантировать с твоей точки зрения?
Чтобы не пропустить подзадачи, нужно:
1) выделить основные обязанности проектируемой системы;
2) затем — для каждой обязанности описать пошаговый алгоритм (юз-кейс) её выполнения — сначала на макро-уровне;
3) после чего этот алгоритм (юз-кейс) можно детализировать.
Общая рекомендация: выделяем ключевые обязанности и пытаемся представить, как проектируемая система будет их исполнять.
U>А.5.1. Если да, то по каким критериям?
U>Это первый вопрос, на который я могу дать осмысленный ответ. Критерии следующие: 1) зависимость других подзадач от этой подзадачи 2) важность подзадачи 3) сложность подзадачи
Согласен.
U>Еще меня следующий вопрос заинтересовал:
U>В.4.2. Решена ли в данной модели проблема циклических ссылок?
U>Что такой циклические ссылки в разработке? Вроде ни разу не сталкивался. Можно пример привести?
Простейший пример (хоть и не относящийся к архитектуре) — это когда мы пытаемся сформулировать конкретные требования к навыкам/знаниям/опыту кандидата до выполнения процедуры постановки задачи. У нас получается: с одной стороны, нам нужен опытный кандидат, чтобы решить сложную проблему, с другой стороны, мы не знаем, каким опытом он должен обладать, т.к непонятно, как будем эту проблему решать.
В такой постановке задача является циклической. Понятно, что причина цикличности заключается в том, что задача поставлена неправильно. Но исходно так и бывает. Поэтому нужна некоторая процедура по избавлению от цикличности.
Есть и "архитектурный" пример циклической задачи. Например, при проектировании GPS-навигационной системы команда разработчиков столкнулась с такой проблемой. Она касалась процедуры пересчета маршрута. Если пользователь слишком отдалялся от текущего маршрута, навигационная система должна была этот маршрут пересчитать. Но процедура пересчета маршрута не бесплатна. Она может занимать довольно-таки длительное время. А навигационная система должна показывать текущее местоположение, текущий маршрут, текущую навигационную рекомендацию (например, "следуйте прямо" или "вернитесь на маршрут").
Получалось, что, с одной стороны, маршрут должен быть всегда, с другой стороны — его нужно было пересчитать, с третьей стороны — решение о том, пересчитывать или нет маршрут, навигационная система должна была принимать после получения информации от GPS о текущем местоположении пользователя. Получался целый "клубок" проблем, которые нужно было распутать.
На примере проектирования игр о подобных проблемах я говорил на КРИ 2008:
— презентацию можно посмотреть здесь;
— запись выступления можно скачать здесь.
Здравствуйте, AlexVinS, Вы писали:
AVS>Вот тут я не согласен. Оценить методику можно только по результату целого проекта, остальное — сферические кони в вакууме. Другими словами, "контрольным вопросом" может быть только сам факт четкого следования определённой методике, а качественная оценка методики — это успешность ее использования в сходных проектах.
Зачастую успешный проект — это результат работы группы людей разных специальностей: маркетологов, рекламистов, продюсеров, менеджеров, архитекторов, проектировщиков, технологов, программистов. Ошибки, сделанные в архитектуре, могут быть скомпенсированы квалифицированной работой менеджера. И, наоборот, хороший дизайн системы может понизить требований к квалификации менеджера.
ИМХО, нужно учиться отделять работу людей одной специальности от работы людей другой специальности и оценивать результаты независимо.
Т.е. первое сообщение редуцируется к такому виду:
