Gaperton on Software Architecture

[gaperton]

Что такое архитектура ПО, чем она отличается от "дизайна", и что же все-таки является входными данными для разработки архитектуры. Дискуссия на РСДН по данному вопросу была изумительна.

Оказывается, распространено мнение, что мол принципиальных отличий между "архитектурой" и "дизайном" нет. Некоторые идут дальше, и заявляют, что "архитектура"

Comments

[kmmbvnr]

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

[gaperton]

Вряд-ли единственный. Думаю, все согласятся с тем, что для любой задачи можно выйти с настолько кривым дизайном в рамках заданной архитектуры, что сроки затянутся неимоверно. :) А стало быть, дизайн таки на сроки все-таки может сильно влиять.

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

[alekciy]

Возник такой вопрос. Получается так, что дизайн по отношению к архитектуре первичен. Всегда ли это так? (да и так ли это?)

К примеру веб разработка, какая нибудь CMS. Авторы решили, что СУБД будет использоваться MySQL ("потому что стоит на любом хостинге"). Получается архитектурное решение. Но проектирование системы в плане дизайна производяет уже после выбора СУБД. Вроде как начинают думать над дизайном.

[gaperton]

"Возник такой вопрос. Получается так, что дизайн по отношению к архитектуре первичен. Всегда ли это так? (да и так ли это

[alekciy]

"Не наоборот, случайно? В примере вроде как наоборот."
Может я тогда что-то не так уловил... Выбор конкретной (Р)СУБД это архитектурное решение которое приводит нас к определенным ограничениям, так?

Просто я беру это как типичный пример. Еще ни строчки вообще ни какого кода не написано, еще ни какой декомпозиции не провели, но выбрали тот же MySQL только потому, что знаем его лучше. Разве не получается, что сначала было принято архитектурное решение и лишь потом мы беремся за дизайн? И если в будующем общие требования к производительности повысятся, а дизайн был спроектированн верно, то переход на другую СУБД будет выполнен малой кровью и потребуется переписать только часть кода который относится к работе с MySQL вместе переписывания системы в целом.

Ну может конечно пример сильно утрированный, но так мне проще понять.

[gaperton]

"Выбор конкретной (Р)СУБД это архитектурное решение которое приводит нас к определенным ограничениям, так

[alekciy]

Хм, ни когда не думал о стеке в таком контексте...

А вообще существует ли какой определенный набор признаков по которым я, рассматривая какую либо систему (которую не я писал), могу скачать, что вот это архитектурное решение, а вот тут дизайн? Потому что на примере стека я бы скорее подумал, что это дизайн. Разве мысль разделить системы на ряд слоев и создание OSI сетевой модели это не дизайнеркое решение? Ведь разработчики могли все запихать и в один протокол, вот DoD ограничился только 4-мя уровнями.

[gaperton]

Строгой границы нет, и помимо того термин "архитектура" чудовищно заезжен и размыт, как и "архитектор". Оперировать ими и не запутаться очень тяжело. Давайте перед ответом на вопрос сделаем вот что

[gaperton]

Вообще, TCP/IP достаточно запутанный пример. Потому, что даже детальное описание этого стека протоколов как единое целое, со всеми деталями, гхм, само является "архитектурным ограничением" для реализации данного стека. То есть, налицо некоторая "рекурсивность", когда то, что "архитектура", а что - нет - зависит от точки зрения.

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

Непонимание этого - также причина путаницы. Вот рядом меня спрашивает Локотков - есть ли архитектура у приложения, у которого пропали исходники? Занятный вопрос, не так ли? А вот я задам встречный вопрос - мы приложение еще не написали, но продумали - у него кода нет, а архитектура - есть или нет?

При понимании того, что "архитектура" на самом деле не "существительное", а "прилагательное" ;) такие вопросы не встают :).

[alekciy]

"есть ли архитектура у приложения, у которого пропали исходники

И еще

[gaperton]

"Короче, разница между design principle и design уже более проста, и интуитивно понятна. Описание принципа подразбиения на уровни в TCP/IP - это одно. Описание стека протоколов, реализующего этот принцип - это уже другое. Понимание _принципов устройства_ системы позволяет Вам легко ориентироваться в самом _устройстве_."

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