воскресенье, 17 октября 2010 г.

Проектирование архитектуры программы: постановка задачи

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

В своём сообщении коллега Undying сформулировал такие требования к кандидату:

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

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


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

Чтобы продемонстрировать это, вернёмся к нашему примеру. Мы сформулировали три подхода к решению:

1) найти способ встроиться в систему 1 с тем, чтобы получать уведомления об изменении данных;
2) найти способ хранить в системе 2 информацию о данных в системе 1 в компактном виде так, чтобы периодически можно было отслеживать изменения;
3) разобраться, почему генерация растрового изображения занимает так много времени.

Очевидно, что каждый из подходов предъявляет к разработчику разные требования.

Для примера рассмотрим более детально подход № 1. Типовая модель архитектуры JSP выглядит так:

Браузер <-> [Сервлет (контроллер), JSP (представление)] <-> JavaBean <-> БД

Эту схему можно детализировать:

Браузер <-> ОС пользователя <-> ОС сервера <-> HTTP-сервер <-> Сервлет-контейнер <-> [Сервелет, JSP] <-> JavaBean <-> БД

Чтобы отследить изменения в БД, потенциально мы можем встроиться:

1) либо в какой-нибудь компонент этой цепочки, участвующий во взаимодействии;
2) либо между компонентами, модифицировав цепочку.

Мы можем встроиться:

1. в браузер — тогда нам нужен специалист, разбирающийся в том, как писать плагины и компоненты для имеющихся браузеров (IE, Chrome, Firefox, Opera, Safari);
2. в ОС пользователя — тогда нам нужен специалист, который имел опыт в написании фаерволов (т.е. умеет писать программы, которые перехватывают запросы пользователя);
3. в HTTP-сервер — нужен специалист по HTTP-серверам;
4. в сервлет-контейнер — нужен специалист по Tomcat'у;
5. в БД — нужен "баз-даннщик" .

В зависимости от выбранного подхода и конкретного варианта решения меняются и требования к специалисту.

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