Собеседование с архитектором: методические рекомендации

Предположим, существует идеальная методика, которая позволяет эффективно решать задачи проектирования.

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

Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:

(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 раз?