Чрезвычайно полезная стратегия реализации, проверки и совершенствования архитектуры приложения — начать с того, что Алистер Коберн (Alistair Cockburn) называет ходячим скелетом. Речь идет о минимальной реализации системы «от начала до конца», связывающей воедино все основные архитектурные компоненты. Начав с минимума — с рабочей системы, содержащей все коммуникационные каналы, — вы можете быть уверены в том, что движетесь в правильном направлении.

Когда скелет будет готов, можно переходить к наращиванию плоти, то есть постепенному, пошаговому добавлению конечной функциональности. Ваша цель — сохранять работоспособность системы, пока скелет обрастает мясом.

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

Чем крупнее система, тем важнее использовать эту стратегию. В небольшом приложении всю функциональность от начала до конца может относительно быстро реализовать один разработчик, но в более крупных системах такой подход становится непрактичным. Достаточно часто встречается ситуация, когда в реализации заняты несколько разработчиков из одной команды (и даже нескольких распределенных команд). Соответственно необходима более тесная координация. К тому же разработчики выдают результаты в разном темпе: одни успевают сделать много за небольшой промежуток времени, другие тратят уйму времени на небольшую задачу. Самые сложные и трудоемкие задачи должны выполняться на ранней стадии проекта.

Начните со скелета, заставьте его ходить, а затем постепенно наращивайте на него плоть.

Клинт Шенк (Clint Shank) — разработчик, консультант и преподаватель из Sphere of Influence, Inc., компании, предоставляющей услуги по проектированию и производству программных продуктов коммерческим и правительственным организациям.

Мы, разработчики, изначально воспринимаем программное обеспечение как систему команд, функций и алгоритмов. Такое «командно-ориентированное» представление помогает нам освоить построение ПО, но оно же начинает мешать, когда мы пытаемся создавать более масштабные системы.

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

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

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

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

Данные находятся в центре большинства задач. Задачи, относящиеся к предметной области, проникают в код через данные. Большинство ключевых алгоритмов хорошо изучены и проанализированы, а вот структура данных и связи между ними изменяются часто. Проблемы уже работающих систем (такие как обновление) также существенно усложняются, если затрагивают данные. Изменение кода или поведения — не такая уж серьезная проблема: нужно просто выпустить новую версию системы; но изменение структур данных может потребовать огромных усилий по преобразованию старой версии данных в новую.

И конечно, многие фундаментальные проблемы архитектуры программного обеспечения в действительности связаны с данными. Собирает ли система правильные данные в правильное время? Кто должен иметь возможность просматривать или изменять эти данные? Если данные уже существуют, насколько они качественны и как быстро растет их объем? Если данных пока нет, то какова их структура, откуда они поступят и насколько надежен их источник? А когда данные окажутся в системе, останется еще один вопрос: есть ли способ просмотра и/или редактирования конкретных данных или его необходимо добавить в систему?

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

Биография автора приведена ранее.

Архитекторы программного обеспечения решают множество очень сложных задач, но наряду с ними встречаются и относительно простые. А вот чего мы стремимся избежать, так это решения простых задач сложными методами. Каким бы очевидным ни казался этот совет, следовать ему порой нелегко. Проектировщики программного обеспечения — умные, очень умные люди. Однако весьма легко попасть в ловушку «простая задача — сложное решение», потому что все мы любим демонстрировать свои знания. Если вы почувствовали, что проектируете решение настолько умное, что оно со временем, того и гляди, проявит искру самосознания, остановитесь и подумайте. Соответствует ли такое решение поставленной задаче? При отрицательном ответе рассмотрите заново варианты дизайна системы. Простое должно быть простым. У вас будет масса возможностей продемонстрировать свой талант, когда вы столкнетесь со сложными задачами, а это непременно случится.

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

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