Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:
Методика крайне формализована и, как следствие, совершенно непонятно как ответы на изложенные в ней вопросы приближают нас к решению реальной задачи. Соответственно опираясь на такую методику на собеседовании вы автоматом отсеете всех практиков, хотя казалось бы цель преследовали прямо противоположную:
Б.1.1. Понимает ли кандидат, что программа пишется не ради красивой иерархии классов и не для того, чтобы что-то хранить, а для того, чтобы что-то делать.
Соответственно хочется задать вопрос:
Понимает ли автор методики, что программисты существуют не для красивых ответов на абстрактные вопросы, а для того, чтобы решать реальные задачи?
Re[3]: Как собеседовать архитектора (методические рекомендац
Здравствуйте, 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>Вот тут я не согласен. Оценить методику можно только по результату целого проекта, остальное — сферические кони в вакууме. Другими словами, "контрольным вопросом" может быть только сам факт четкого следования определённой методике, а качественная оценка методики — это успешность ее использования в сходных проектах.
Зачастую успешный проект — это результат работы группы людей разных специальностей: маркетологов, рекламистов, продюсеров, менеджеров, архитекторов, проектировщиков, технологов, программистов. Ошибки, сделанные в архитектуре, могут быть скомпенсированы квалифицированной работой менеджера. И, наоборот, хороший дизайн системы может понизить требований к квалификации менеджера.
ИМХО, нужно учиться отделять работу людей одной специальности от работы людей другой специальности и оценивать результаты независимо.
