?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Gaperton on Software Architecture

Posted on 2009.03.10 at 20:38
Tags: ,

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

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

Надо расставить точки над i по крайней мере в моей позиции. Надо для начала определить, что такое "архитектура", и разобрать это определение на конкретных примерах. То, чего, почему-то, сильно не любит публика на РСДН. Странно, но по факту оказывается так. Ок, essense of software architecture минут за 10.

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

"Дизайн" понимают и как протяженный во время процесс, и как некий артефакт, в который можно ткнуть пальцем (хоть и сложно, но как-то само собой подразумевается, что можно). Цель "дизайна" (проектирования) как процесса - получить понимание того, как мы будем структурировать нашу систему, какова будет ее декомпозиция. Результат - собственно описание декомпозиции, из каких компонент система состоит, и каковы связи между ними.

Декомпозиция системы бывает структурная, и функциональная. Таким образом, к дизайну относятся модели вроде класс-диаграмм, схем зависимости модулей, а также dataflow-диаграмм, показывающих "поток данных", то есть данные, и функциональные зависимости между ними. В UML нет dataflow-диаграмм, и данная техника малознакома "объектно-ориентированной" публике. Однако, если вы нанесете на стрелки ассоциаций на диаграмме классов вызовы, которые дергаются по данной ассоциации, вы по смыслу получите практически ее, dataflow-model.

Если для того, чтоы понять, как мы будем структурировать систему, надо кодировать (такое бывает) - то это все равно "проектирование", а не кодирование, поскольку цель процесса на данном этапе - понять, как мы будем структурировать систему, а не получить работоспособную программу.

Полезно отделять "детальный дизайн" от "дизайна". Отличие очень простое - в детальном дизайне явно присутствует время, и/или точные спецификации структур/форматов данных, в то время как в описании просто "дизайна" явно не присутствуют ни структуры данных, ни временная последовательность - он, как уже отмечалось, статичен, и задает только структуру. Решениями уровня детального дизайна является выбор применяемых алгоритмов и структур данных, и наброски критичных алгоритмов. Модели уровня "детального дизайна" - это sequence диаграммы, описания конечных автоматов, блок-схемы алгоритмов, "псевдокод", описание форматов, структур, и типов данных (то есть header-файлы). Еще к детальному дизайну можно отнести деятельность по прототипированию proof of the concept.

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

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

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

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

Значит ли это, что не надо пытаться думать наперед? Тоже нет. Это значит, что не надо обманывать себя. Если для получения понимания надо написать код, пишите, начиная с самой непонятной части, продвигаясь маленькими шажками, держа в голове, что цель этой деятельности на раннем этапе - получить в первую очередь это самое понимание, а не отлаженный код.

Что же такое "архитектура", и почему это не "дизайн". Архитектура - это тот набор ограничений, специфичных для системы или проекта, набор своего рода "правил проектирования", которому вы следуете, когда делаете дизайн. В чем выражаются эти ограничения - используемые технологии, некоторые договоренности касательно структурирования кода (определенный набор слоев и/или сервисов например), и диктуемая этими ограничениями необходимость задействования некоторого кода (фреймворка, например), уже не так принципиально.

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

Короче говоря, "архитектура" - это когда вы думаете сильно вперед.

Является ли выбор базовых технологий архитектурным решением? Безусловно. Решая, что вы пользуетесь MS SQL, вы во-первых, выделяете слой хранения данных как отдельный слой, во-вторых - решаете, что у вас в этом слое будет реляционная модель. И сразу ограничиваете себе класс решаемых задач - MS SQL не заточен под большой поток быстрых look-up запросов. Дает вам это ограничение, кроме ясности, тоже много - вся мощь MS SQL, его движка обработки данных, и зранимых процедур.

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

Скажем, в задаче обработки биржевых котировок "вся мощь SQL" вам не особо поможет (join-ов почти нет), зато сильно поможет возможность реализации собственного алгоритма сжатия котировок (их реально много), и отсутствие оверхэда на передачу данных через границу процесса (он заметен, когда запрос возвращает примерно столько же данных, сколько на входе).

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

Однако, в чем на практике выражается разница? Вот, допустим, кто-то не отделяет архитектуру от дизайна, и считает, что так и надо. К чему это приведет? Посмотрим на конкретном примере

Наша задача - написать media player. Допустим, под Linux. Ну, знаете, iTunes там, или Windows Media Player? Который, помимо прочего, сможет проигрывать цифровое эфирное телевидение в стандарте DVB. Т

ак вот, в основе архитектуры будет устройство Media Processing Engine, крупный безгуевый компонент, который обеспечит собственно декодирование медии, и поверх которого будет сделан ГУЙ. Это мы уже приняли архитектурное решение, разделив обработку медиапотока от управления и презентационного уровня. А прием цифрового ТВ будем делать посредством стандартной драйверной подсистемы LinuxDVB. Но фокус не в этом. Смотрим дальше - мы близки к моменту истины.

Существует множество разнообразных Media Engine, которые мы можем взять за основу. Или сделать свой собственный. Рассмотрим два кандидата - Helix DNA Client, и GStreamer, и проследим, какого рода последствия тот или иной выбор окажет на структуру нашей системы. Требования, внимание! - одни и те же! Наш Media Engine должен уметь показывать видео с нового типа источника - LinuxDVB, мы должны задействовать аппаратный декодер видео нашей разработки.

Итак. На первый взгляд по интересной нам функциональности они одинаковы. Детали: HelixDNAClient - построен на базе COM (!), содержит абстракцию от файловых систем, устройств, и API. GStreamer - построен на основе GObject и DBus, и в целом подталкивает нас к тому, чтобы строить плеер на основе GTK+. Ну, типа, особенности, ладно. Самое интересное будет, когда мы заглянем внутрь.

В HelixDNAClient первична обработка потокового аудио-видео, полученного по сети в реальном времени. Центром его архитектуры, стержнем, является получение нескольких медиапотоков по протоколу RTP, их декодирование, синхронизация, и показ на абстрактных устройствах вывода. Но он умеет проигрывать и файлы! Да-да! Сделано это вот как: когда вы читаете файл, вы разбираете его формат, формируете COM-объекты, соответствующие распарсеным RTP-пакетам (!) и они подсовываются внутрь движка, типа мы их с сети получили. При этом, обработка самих форматов файлов сделана зашибись как абстрактно, даже файловая система абстрагирована.

Как нам в рамках данной архитектуры научить его проигрывать DVB, получаемый с тюнера в реальном времени? Элементарно. :) Пользуясь его абстракциями, пишем свою "файловую систему", представляющую тюнер (или канал) в виде такого специального файла, свой "файловый формат", в котором - заворачиваем все в RTP-пакеты! :).

DVB File System Plugin -> (transport stram "file") -> DVB File Format PlugIn ->(RTP Packets) -> Helix Core -> ...

GStreamer построен не так. Пользуясь им, вы строите медиаконвейр, состоящий из элементов, увязанных в произвольный однонаправленный граф (без циклов). Элементы равноправны, и конфигурируются на лету. GStreamer проследит за синхронизацией потоков. Что нам надо сделать, чтобы он научился проигрывать DVB? Написать элемент-источник DVB, который воткнется в элемент-разборщик транспортного потока DVB (тоже написать), и, собственно, все. При запуске, сконфигурировать граф обработки так, что эта пара элементов будет стоять в начале графа.

DVB Source -> (transport stream) -> DVB Demux -> (audio), (video) ...

На самом деле, GStreamer уже умеет это делать, компоненты для DVB в ем есть. Но это не важно. Важно то, что GStreamer проще сам по себе. Helix DNA Client - кусок слипшегося дерьма, GStreamer - набор слабосвязанных компонент. И он делает вашу систему проще. Вам не надо изворачиваться, и изобретать способы, как добавить новую функциональность - это делается прямолинейно. Однако, у кого-то возникнут сомнения, ну по разному все делается немного, но и что, собственно?

Добавляем фичу Time Shifting. При постановке на паузу живой трансляции, мы должны писать транспортный поток на диск. При снятии с паузы - продолжить воспроизведение с той точки, на которой встали, и все равно писать на диск то, что приходит с эфира.

Helix DNA Client. Элементарно! :) Врезаемся в "файл", если внутренний буфер переполняется, и из нас долго не читают - так мы эта, на диск вытесняем буфер.

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

В результате имеем. В GStreamer мы можем воткнуть TimeShifter куда угодно - и в тракт воспроизведения DVB, и в случае, если мы принимаем видео по IPTV (транспортный поток DVB внутри RTP). Только и делов - переконфигурировать граф. А это вдруг оказывается важным требованием - гибридные устройства, принимающие как эфирный цифровой сигнал, так и IP, нынче входят в моду.

В Helix - что надо сделать, чтобы реализованный нами Time Shifting работал в случае IPTV? Врезать его в другое место - в сам Helix Core? Валяйте, операция на спинном мозге без наркоза, учебники по хирургии уже купили :). После нее вам придется ломать голову, как реализовать цифровой видеомагнитофон (запись программы по расписанию, желательно в том же формате, в котором она приходит). :)

Архитектуры Helix DNA Client, и GStreamer являются отличными иллюстрациями к данной дискуссии. Не важно, выбираете ли вы сторонний компонент, или решаете делать свой - вы принимаете архитектурное решение тогда, когда выбираете общие правила структурирования системы - что будет ее "скелетом". Вы можете не думать об архитектуре, то есть - думать о ней как о дизайне, и строить ее на базе текущих требований. Получится примерно так, как у парней из RealMedia, авторов Helix. Ну, то есть на базе такого фреймворка можно будет реализовать широкий класс приложений, таких, которые будут называться RealOne Player. :) А ведь парни старались, между прочим.

Собственно, вот. Если и после такого примера что-то будет непонятно - ну тогда я уже не знаю как объяснить.


Comments:


thrust_breaker at 2009-03-10 19:27 (UTC) (Link)
1. Каким образом, не делая дизайн, узнать, что в системе в принципе должен быть некий "компонент"/технология/слой? И как провести границу между ним и другими компонентами/слоями?
2. На форме, которая позволяет подготовить и отправить сложный (или не очень) запрос в БД, вдруг решаем разместить кнопочку Undo. Относится ли это решение к уровню архитектуры?
3. Архитектура команд процессора -- это один из конечных продуктов дизайна или что-то иное? Если что-то иное, то что (философия, набор ограничений, стратегический дизайн и т.п.)?
4. Есть ли архитектура у существующей программы, от которой остался, скажем, только исполняемый бинарь?
Вадим Савкин
vsavkin at 2009-03-10 20:02 (UTC) (Link)
И стоило так много букв писать? :)
Имхо, споры о терминологии - самые глупейшие (если только они не ведутся в каком-нибудь комитете по стандартизации).
Термины "архитектура", "дизайн", "детальный дизайн" по своей природе размыты и нечётки, разные люди, или даже те же самые в разных ситуациях будут разный смысл вкладывать в них. Это данность, с этим ничего не поделаешь. Можно пытаться написать трактат на тему что и как правильно стоит называть, но это, имхо, бессмысленно, - врядли получится всех склонить к единому мнению (хотя бы потому, что не все это прочтут). Всё равно придётся каждый раз смотреть на контекст, чтобы понять, о чём идёт речь.
kmmbvnr
kmmbvnr at 2009-03-12 03:31 (UTC) (Link)
Стоит стоит. От размытых терминов мало толку.

Если у вас есть другой вариант _четкой_ декомпозиции терминов, тогда да можно поспорить.
alekciy
alekciy at 2009-03-10 21:08 (UTC) (Link)
А мне запись понравилась. Хотя учитывая, что конкретный пример идет в конце, то начало воспринимается как то размыто...
kmmbvnr
kmmbvnr at 2009-03-12 03:38 (UTC) (Link)
При таком определении терминов, мне теперь интересно, верно ли то что, варьируя дизайн сократить сроки разработки проекта практически невозможно. Изначально другая архитектура это единственный способ получить сокращение в разы?
Gaperton
gaperton at 2009-03-12 23:07 (UTC) (Link)
Вряд-ли единственный. Думаю, все согласятся с тем, что для любой задачи можно выйти с настолько кривым дизайном в рамках заданной архитектуры, что сроки затянутся неимоверно. :) А стало быть, дизайн таки на сроки все-таки может сильно влиять.

Другое дело, что влияние архитектурных решений на сроки разработки может на порядок превосходить эффект от "дизайнерских" ходов. С чем вероятно, также все согласятся :). Так что архитектура, возможно, не единственный, но однозначно наиболее сильно влияющий на сроки фактор из обсуждаемых.
alekciy
alekciy at 2009-05-09 01:37 (UTC) (Link)
Возник такой вопрос. Получается так, что дизайн по отношению к архитектуре первичен. Всегда ли это так? (да и так ли это?)

К примеру веб разработка, какая нибудь CMS. Авторы решили, что СУБД будет использоваться MySQL ("потому что стоит на любом хостинге"). Получается архитектурное решение. Но проектирование системы в плане дизайна производяет уже после выбора СУБД. Вроде как начинают думать над дизайном.
Gaperton
gaperton at 2009-05-09 12:37 (UTC) (Link)
"Возник такой вопрос. Получается так, что дизайн по отношению к архитектуре первичен. Всегда ли это так? (да и так ли это?)"

Не наоборот, случайно? В примере вроде как наоборот.

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

Люди могут начать с MySQL, уткнуться в принципиальные ограничения, и будут вынуждены сменить его на что-нибудь еще.

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

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

В данном случае, и так очевидно, что MySQL вполне подойдет, вот и все. Они могли предпочесть его по одной причине - они его знают лучше других - этой причины достаточно.
alekciy
alekciy at 2009-05-09 14:10 (UTC) (Link)
"Не наоборот, случайно? В примере вроде как наоборот."
Может я тогда что-то не так уловил... Выбор конкретной (Р)СУБД это архитектурное решение которое приводит нас к определенным ограничениям, так?

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

Ну может конечно пример сильно утрированный, но так мне проще понять.
Gaperton
gaperton at 2009-05-09 14:49 (UTC) (Link)
"Выбор конкретной (Р)СУБД это архитектурное решение которое приводит нас к определенным ограничениям, так?"

Конечно.

"Еще ни строчки вообще ни какого кода не написано, еще ни какой декомпозиции не провели, но выбрали тот же MySQL только потому, что знаем его лучше. Разве не получается, что сначала было принято архитектурное решение и лишь потом мы беремся за дизайн?"

Получается.

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

Думаю, если вы заранее закладываетесь на возможную замену СУБД - это тоже определенное архитектурное решение. Выливающееся, скажем, в отказе от использования Transact-SQL (если у вас не MySQL а MS SQL в начале), или в выделении и минимизации слоя, зависимого от СУБД в явном виде.

Короче, структура "слоев", из которых состоит приложение (layered architecture) - тоже относится к архитектуре. Вот, например, способ подразбиения стека протоколов TCP/IP на отдельные протоколы - это ни что иное как выделение слоев, дающих определенные группы сервисов, и это архитектурное решение.
alekciy
alekciy at 2009-05-10 12:01 (UTC) (Link)
Хм, ни когда не думал о стеке в таком контексте...

А вообще существует ли какой определенный набор признаков по которым я, рассматривая какую либо систему (которую не я писал), могу скачать, что вот это архитектурное решение, а вот тут дизайн? Потому что на примере стека я бы скорее подумал, что это дизайн. Разве мысль разделить системы на ряд слоев и создание OSI сетевой модели это не дизайнеркое решение? Ведь разработчики могли все запихать и в один протокол, вот DoD ограничился только 4-мя уровнями.
Gaperton
gaperton at 2009-05-10 12:36 (UTC) (Link)
Строгой границы нет, и помимо того термин "архитектура" чудовищно заезжен и размыт, как и "архитектор". Оперировать ими и не запутаться очень тяжело. Давайте перед ответом на вопрос сделаем вот что.

Все станет гораздо проще и понятнее, если Вы откажетесь от употребления слова "архитектура", заменив его достаточно устойчивым, но более конкретным термином Common Design Principles. Понятия не имею, как это хорошо перевести на русский - как Вам нравится. (А термин "архитектор" - на не несущий лишнего смысла термин "technical lead")

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

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

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

Разработчики микропроцессоров имеют дело с той же проблемой, и поэтому выделяют терминологически "архитектуру системы команд" (instruction set architecture), и "микроархитектуру" (устройство проца, реализующего систему команд). Как пример - ISA SPARCv8 допускает самые разные "микроархитектуры" - начиная от простого процессора для встраиваемых приложений Leon3, и заканчивая зверской Сановской Ниагарой, не имеющего с Leon3 вообще ничего общего. Кроме системы команд. Правда, у ниагары SPARCv9.

Короче, не надо пользоваться термином "архитетура" лучше :). Во избежание.
Gaperton
gaperton at 2009-05-10 12:48 (UTC) (Link)
Вообще, TCP/IP достаточно запутанный пример. Потому, что даже детальное описание этого стека протоколов как единое целое, со всеми деталями, гхм, само является "архитектурным ограничением" для реализации данного стека. То есть, налицо некоторая "рекурсивность", когда то, что "архитектура", а что - нет - зависит от точки зрения.

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

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

При понимании того, что "архитектура" на самом деле не "существительное", а "прилагательное" ;) такие вопросы не встают :).
alekciy
alekciy at 2009-05-10 13:43 (UTC) (Link)
"есть ли архитектура у приложения, у которого пропали исходники?"

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

"А вот я задам встречный вопрос - мы приложение еще не написали, но продумали - у него кода нет, а архитектура - есть или нет?"
Как я понимаю, если мы не задались конкретными реализациями, то еще нет. Т.е. пока имеем абстрактную модель архитектуры нет. Как только мы решаем, что вот эта часть системы у нас будет реализованна на готовом решинии ХХ (данные храним в РСУБД MS SQL, к примеру), то архитектура появляется. По крайне мере я это понял так.

"При понимании того, что "архитектура" на самом деле не "существительное", а "прилагательное" ;) такие вопросы не встают :)."
Ну вот именно так об этом думать достаточно трудно...
Gaperton
gaperton at 2009-05-10 12:52 (UTC) (Link)

И еще

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

С другой стороны, выделение этих принципов в явном виде, размышление над ними, и следование им при дизайне - позволяет Вам сделать устройство системы более простым, логичным, понятным, и не запутаться при этом.
Daniel Ginsburg
dbg at 2009-03-12 09:08 (UTC) (Link)
Правильно понимаешь и хорошо формулируешь. Одобряю :)
Енотинька
raccoon at 2009-03-17 00:45 (UTC) (Link)

противным голосом

Дяденька gaperton, смени account на базовый.
А то мне под твоей статьей по архитектуре рекламу показали просто божественную: "ЖЖЖ - только для девочек"
Это несправедливо - так сегрегировать аудиторию читателей статей про системную архитектуру по гендерному признаку. Мальчики, может, тоже хотят про это почитать, а тут им - полный облом.
Teo
teo_bon at 2011-02-18 17:06 (UTC) (Link)

Re: противным голосом

Лучше платный аккаунт, чтоб expand работал для комментариев. Потому что комментарии иногда не менее ценные, чем сама статья.
nomen at 2009-04-06 08:18 (UTC) (Link)
где тут кнопа "хороший, годный пост"? %))
troollface
troollface at 2011-03-04 15:09 (UTC) (Link)
интересно читать
Previous Entry  Next Entry