По просьбе коллег (см. здесь

Автор: -_*
Дата: 12.10.10

) пересоздаю тему

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

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

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

Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:

(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) на масштабный рефакторинг готового проекта.

Просьба высказывать свои варианты и свои точки зрения.