Проблемы ИТ-архитектуры

[Emelian]

Сами потребители не знают что хотят, пробуют выразить свое желание через фразу «Нарисуй мне архитектуру». На вопрос «Какую именно?», могут растерянно ответить «Техническую» или «Логическую», а вот попытка выяснить какую технику или логику там хотят увидеть, а главное зачем, уже вызывает заметные сложности.

Разве это правильная постановка вопроса?

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

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

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

1. Архитектор создает прототип проекта, в котором разрабатываемые модули (по сути,, классы) имеют чисто формальные реализации., т.е., набор публичных функций с пустым телом. При этом, вызовы этих публичных функций в главном модуле приложения (для проектов на C++ / WTL это будет CMainFrame), за разработку которого отвечает архитектор, должны быть зафиксированы явно (скажем, в обработчиках сообщений либо в функциях потоков).

2. Этот проект, с «пустыми» модулями (классами) компилируется, но, по сути, ничего, особо не делает. Только отображение главного окна, его полного меню, но без реальной работы (разве что, просто вывод мессаджбокса с указанием выбранного пункта меню), тулбара и статусбара.

3. Этот прототип проекта раздается всем членам команды, с указанием, кому, какой модуль (класс) развивать, т.е., заменять пустые тела функций их реальным содержимым. При необходимости, программисты-исполнители могут добавлять приватные функции и данные, на свое собственное усмотрение.

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

5. Архитектор, делает замену формального модуля на реальный и осуществляет общее тестирование. При необходимости, вносит изменения в работу команды.

6. Принятый, в первом приближении, реальный модуль может стать доступным для всех членов команды и тестировщиков.

7. Если реальный модуль обновляется, то его новая версия замещает старую, путем простой замены файлов.

8. Задача архитектора состоит в том, чтобы эта схема, либо аналогичная, принятая всеми членами команды, работала.

Как-то так.

Когда я создам, по этому принципу, вторую версию своей обучающей программы, то, вероятно, напишу статью на эту тему.

[Kishuomi]

Мне нравится ваше предложение, особенно если речь идет об архитекторе уровня приложения (application architect). Если его ещё обернуть в что-то типа ADR, то вообще отлично.

[Emelian]

Если его ещё обернуть в что-то типа ADR, то вообще отлично.

Но, сначала надо провести эксперимент, потом появятся новые идеи.