Здравствуйте, mrTwister, Вы писали:
G>>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
T>Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
T>Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
Некоторые правила поменять проще, другие — сложнее. Используя термин "архитектурно значимые" ты как бы говоришь, что те правила, которые на первый взгляд проще поменять — менее важны. И их как бы не надо соблюдать.
Но это не так. Если наплевать на правило распределения по папкам и сборкам, у тебя, например, сломается паттерн Layer. Суть которого, в общем, и состоит в том, что ты раскладываешь код по модулям не абы как, а очень даже осмысленно. Соблюдение этого правила может довольно сильно влиять не только на положения файла в папке, но и на объектную декомпозицию. Которую, если забить на правило с папками, потом поменять может быть уже совсем не дешево.
И это вполне естественно, если принимать во внимание, что с точки зрения дизайна самое интересное происходит не внутри модулей, а между ними. Интерфейсы.
T>С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Некоторые правила соблюдать затратно, а некоторые — не очень. Правило наличия black-box тестов с самого начала было "архитектурой". Просто сначала его было не так затратно соблюдать. Так бывает. Чем дольше разрабатывается продукт, тем больше начинают мешать старые правила, и тем в целом затратнее становится их менять.
Обращать внимание (и считать "архитектурно значимыми") только на те правила, которые доставляют проблемы или которые дорого менять сейчас — не самый полезный способ думать, ИМХО. С таким подходом ты рискуешь все пропустить, и все всегда будет внезапно. А это не то, что мы хотим.
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Здравствуйте, Sinix, Вы писали:
S>По архитектуре — перечитай пост Gaperton-а по ссылке выше, он там предлагает не смешивать мух с котлетами (дизайн с архитектурой). И подробно расписывает, какое отношение имеет архитектура к используемым технологиям.
Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
Здравствуйте, 0x7be, Вы писали:
0>Слово весьма заезженное, его часто употребляют в наших профессиональных обсуждениях. Однако четкого определения мне мои коллеги дать не смогли.
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия?
формальное определение не дам, но субъективно под этим лично я понимаю зафиксированный документально свод информации, описывающий макроаспекты построения компонентов, обоснующий наличие каждого из них, и раскрывающий ключевые детали их сочетания и взаимодействия, а также основные технические рекомендации и ограничения на подходы к их реализации (иными словами, какие библиотеки третьих сторон, в т.ч. платные, могут быть использованы, что запрещено и проч.). в них могут и должны устанавливаться рамки ответственности разных сторон, вовлечённых в разработку.
основной контингент читающих — вовлечённые в разработку и приёмку (в широком смысле, т.е. включая аналитиков, разных поставщиков, тестировщиков и т.п., а также представителей заказчика и/или интегратора)
можно, естественно, говорить и об архитектурах более низкого уровня (раскрытие деталей конкретного компонента и проч.), но с ними доводится сталкиваться реже, т.к. чаще всего круг потребителей такой информации более узок, и он может разговаривать уже на ЯП. микроархитектуры, однако, полезны там, где может появляться соприкоснование сторон (например, разработчиков компонента и используемой для его реализации библиотеки)
0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
убеждён, что нужно. ключевой момент — потребители.
чем выше разнообразие вовлечённых потребителей, особенно по-разному заинтересованных экономически и/или политически, тем важнее им дать всю информацию из единого центра — это дисциплинирует, даёт возможность разговаривать на одном языке и избежать технического недопонимания на стадиях реализации; в начале — дать возможность поставщикам определить необходимые профили персонала, в процессе — определить порядок взаимодействия разных сторон и людей и организовать своевременную подготовку тестовых стендов, в конце — обеспечить формальной стороной интеграционную приёмку.
несколько дней назад консультировал проект, в котором общение со стороны заказчика-интегратора построено на внушении, а не документировании. архитектуру никто из поставщиков до конца не понимает, всё делается на лету, а на проекте есть решения, не позволяющие легко войти, и есть персонал, не готовый ни технически, ни морально к такому развитию событий. консультанты тоже ни к селу, ни к городу, т.к. их привлекают для решения проблем первого плана, осознанных сиюминутно, когда фактически им приходится отвечать на более фундаментальные вопросы.
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Я люблю использовать поразительные заголовки, лучшие из которых (как вот этот) несут важную информацию, неочевидную с первого взгляда. Помните второе определение Джонсона: "Архитектура – это набор решений, которые вы бы хотели принять верно на ранних этапах работы над проектом". Почему кто-то хочет, чтобы некоторые решения были правильными с самого начала? Конечно же потому, что они думают, что их будет сложно изменить позднее. Так, мы можем прийти к определению, что архитектура – это “решения, изменить которые считается сложным”.
...
Мне кажется, что одной из главных задач архитектора является удаление архитектуры путем устранения необратимости в дизайне ПО.
Здравствуйте, B0FEE664, Вы писали:
BFE>Допустим было принято решение писать приложение на Basic'е. Довольно трудно будет потом перейти в разработке приложения с Basic'а на Javа. Можно ли сказать, что язык — это архитектура приложения? Я думаю, что нет.
Выбор языка — это, разумеется, архитектурное решение.
BFE>Допустим было принято решение писать графический интерфейс приложения на wxWindows. Довольно трудно будет потом перейти в разработке приложения перейти с wxWindows на отрисовку, скажем, в OpenGL. Но даже после такого перехода архитектура приложения может сохраниться.
Библиотека для UI тоже может быть архитектурно значимым решением, причем как правило так и есть. В этом случае при смене UI библиотеки архитектура меняется, даже если структура приложения сохраняется. Структура приложения — это еще не архитектура.
Здравствуйте, ZevS, Вы писали:
G>>Кстати, в нашем случае ZS>>> Архитектура — выкокоуровневая структура, дизайн — процесс специфицирования структуры ну или сама спецификация. G>>это даже не интересно.
ZS>Ровно тоже самое написано в стандарте IEEE 1471 и заменившем его ISO/IEC 42010, и моему пониманию такое определение ближе, чем, скажем, определение Фаулера — "architecture is the set of design decisions that must be made early in a project". Про википедию, это был легкий троллинг))
Начнем с того, что разных определений одной и той же штуки может быть много. Например, в математическом анализе есть множество способов, как ввести действительные числа. Разные определения могут быть эквивалентны, и тогда никакое из них не ближе. Это в математике.
А когда мы говорим о сложных и непонятных штуках, встречающихся в реальной жизни, например — о физике, разные определения одного и того же могут быть не просто не эквивалентны, но противоречить друг другу. Опираясь, при этом, на разные аспекты одного и того же явления. Взять например, свет. В физике, он может определяться как поток частиц, или как волна.
Какое определение верное? Оба неверны. Ни одно из этих двух определений света не описывает свет исчерпывающим образом. И они оба верны, так как в совокупности описывают одно и то же явление.
“Чем богаче подлежащий определению предмет, то есть чем больше различных сторон он предоставляет рассмотрению, тем более различными оказываются даваемые ему дефиниции. Так, например, существует масса дефиниций жизни, государства и т. д. Геометрии, напротив, легко давать дефиниции, так как ее предмет, пространство, очень абстрактен”.
Гегель
Но мы отвлеклись. Теперь об "архитектуре". Проблема с этим, с позволения сказать, термином, в том, что его все употребляют, но никто толком не знает, что это такое. Определений невероятное количество. Их десятки. Многие из них верны. Но большинство бесполезно. Особенно те, которые присутствуют в комитетских стандартах. "Комитетские" определения сложных и противоречивых вещей (как и википедия) особенно плохи из-за тенденции группы людей при обсуждении фиксироваться на common knowledge, в то время, как в таких случаях самое интересное как правило лежит за его границами.
Взять определение Фаулера. "architecture is the set of design decisions that must be made early in a project" — это, да? Оно верно, но бесполезно чуть менее, чем полностью. Потому, что нас интересует осмысленный ответ на вопрос, какие решения должны быть приняты осознанно, и рано. Нам надо уметь их как-то отличать от тех других. Фаулер, между нами, вообще весь такой.
Другой философ, Диоген, ощипал цыпленка и бросил его к ногам Платона со словами: “Вот твой человек”. После этого Платон уточнил свое определение: человек — это двуногое бесперое существо с широкими ногтями.
Классическое определение, про "структуры", характерно тем, что оно понятно исключительно интуитивно. И больше никак. А как до дела доходит, оно также бесполезно, потому, что а-приори этот высокий или низкий уровень структуры на практике не различим. Какие-либо внятные критерии его различия отсутствует. Масштаб — относителен, и критерием быть не может, это пустышка, а не определение, так же, как и у фаулера. Ничего полезного для действия из этого определения не выводится.
Еще один философ охарактеризовал человека как существо с мягкой мочкой уха. По какому-то капризу природы оказалось, что из всех живых существ только у человека мягкая мочка уха.
Перечисленное выше приводит к тому, что слово "архитектура" на деле техническим термином не является, ничего определенного и понятного для собеседников не значит, и его полезнее попросту запретить к употреблению.
Помимо отграничения определяемых предметов, к определению обычно предъявляется также требование раскрывать сущность этих предметов.
Более внятный термин, чтобы описать явление и проблемы, о которых смутно бредят люди, произнося слово "архитектура" — это Common Design Principles. Вот есть Design. А есть — его Common Principles.
Наиболее практически полезное определение — про правила. У него, конечно, есть недостатки. Ну, например, его автор не Фаулер. И оно не написано в комитетском стандарте. Зато оно проводит наиболее точную и понятную границу с дизайном, описывает все известные эффекты, как пример с юнит-тестами, приведенный товарищем выше (отличный пример, структурные определения его не описывают), и включает в себя социальные аспекты архитектуры. Потому, что правила выполняются людьми. И, что более важно, люди склонны забывать на правила большой болт.
Это важно потому, что определение дает понимание, а понимание требуется для действия.
Но так как мы уже выяснили, что одного единственно верного определения для сложных явлений не бывает — каждый волен пользоваться своим любимым.
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, Gaperton, Вы писали:
G>>Только в математике определение определяет то, чем является объект или явление. G>>В жизни и пророде все не так — сложное явление является само, и плевать хотелo на все наши определения. Особенно — на откровенно неудачные. ZS>Архитектура это не явление, а абстрактное поняние. А понятие без определения не существует.
"понятие без определения не существует"
Цитирую:
Понятие множества обычно принимается за одно из исходных (аксиоматических) понятий, то есть несводимое к другим понятиям, а значит, и не имеющее определения;
Итого, с учетом сказаного тобой, "множеств не существует"
Здравствуйте, Gaperton, Вы писали:
G>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Здравствуйте, artelk, Вы писали:
A>Мне нравится Фаулервское объяснение: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Я полностью согласен с его подходом к определению, но исключительно сомневаюсь в реализуемости принципа устранения архитектуры
Здравствуйте, gandjustas, Вы писали:
G>4 года назад было такое же обсуждение G>Вот что тогда написал — http://gandjustas.blogspot.ru/2011/01/blog-post.html
Тут дело такое — меня интересует не сколько конкретное определение, сколько обоснование, почему так
Ну или, если хочешь, некий четкий критерий, который бы мог определить, является ли то или иное решение архитектурным или нет.
Лично я считаю, что архитектура — это всё то, что дорого поменять и, следовательно, в чем дорого ошибиться.
Соответственно, разработка архитектуры — это по сути управление рисками.
Соответственно, любое решение, которое потом передумать нам "по карману" не является архитектурным
Соответственно, определяющим является толщина кармана.
Как-то так.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, gandjustas, Вы писали:
G>>4 года назад было такое же обсуждение G>>Вот что тогда написал — http://gandjustas.blogspot.ru/2011/01/blog-post.html 0>Тут дело такое — меня интересует не сколько конкретное определение, сколько обоснование, почему так 0>Ну или, если хочешь, некий четкий критерий, который бы мог определить, является ли то или иное решение архитектурным или нет.
0>Лично я считаю, что архитектура — это всё то, что дорого поменять и, следовательно, в чем дорого ошибиться. 0>Соответственно, разработка архитектуры — это по сути управление рисками. 0>Соответственно, любое решение, которое потом передумать нам "по карману" не является архитектурным 0>Соответственно, определяющим является толщина кармана. 0>Как-то так.
Кроме толщины кармана есть еще time to value, то есть время до того, как потребитель получит ценность.
А еще есть другой аспект. Зачастую не все архитектурные решения принимает разработчик. В корпоративных системах или навороченных веб-сервисах архитектура может определяться другими компонентами. Поэтому очень важно чтобы то, что ты сделаешь в приложении вписалось в архитектуру системы.
Что касается управления рисками, то любое управление по сути управление рисками — будь то управление архитектурой или отделом продаж.
Здравствуйте, 0x7be, Вы писали:
0>Соответственно, разработка архитектуры — это по сути управление рисками.
Не только. В бОльшей степени — это отказ от принятия решений, принимать которые нет необходимости. Очень часто архитектурные ошибки заключаются в том, что были приняты необязательные архитектурные решения. Необязательные они в том смысле, что эти решения можно было бы и не принимать, но разработчики, часто ориентируясь на прошлый опыт, зачем-то их приняли и столкнулись с тем, что эти решения не соответствуют реалиям проекта.
Здравствуйте, mrTwister, Вы писали:
G>>Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
T>ИМХО, важнее то, сможем ли мы легко поменять MS SQL на что-то другое. Если сможем, то MS SQL — это не архитектура, а мелкая деталь реализации.
Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
А уж насколько конкретные правила (и существующий код, оформленный в соответствии с ними) мешают или помогают проектировать — это второй вопрос.
Здравствуйте, 0x7be, Вы писали:
0>Ладно, а что не является архитектурой, и в чем критерий, отделяющий архитектуру от не-архитектуры?
На мой взгляд, в данной формулировке вопрос бессмысленен, переформулирую. По-моему, ты хотел спросить, какую часть архитектуры и до какой степени детализации нужно специфицировать на ранней стадии проекта. Если так, то ответ уже в вопросе — на ранней стадии должно быть определенно то, что будет дорого или невозможно поменять на позже. Это могут быть языки программирования, ОС, транспорт, трех/двух-звенка, тип пользовательского интерфейса, протоколы взаимодействия.... Некоторые же вещи на ранней стадии специфицировать вообще невозможно. Для каждой системы набор будет свой.
Некоторое время назад со своими сотрудниками обсуждал вопрос о том, что такое архитектура.
Слово весьма заезженное, его часто употребляют в наших профессиональных обсуждениях. Однако четкого определения мне мои коллеги дать не смогли.
В связи с этим хочу провести тут опрос на эту тему. Пожалуйста, дайте ответы на следующие вопросы:
Что такое архитектура ПО?
Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия?
Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Обсуждение любых абстрактно-философских вещей наподобие паттернов и сфероконичной архитектуры в вакууме — это всегда очень много букв. Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто.
Здравствуйте, Sinix, Вы писали:
S>Взаимоисключающие параграфы вижу я
S>Обсуждение любых абстрактно-философских вещей наподобие паттернов и сфероконичной архитектуры в вакууме — это всегда очень много букв. Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто.
А почему обязательно это должны быть абстрактно-философские вещи?
Имхо, это признак незрелости нашей отрасли или отдельных людей.
Хочется как раз побольше конкретики и лапидарности
Здравствуйте, 0x7be, Вы писали:
S>>Обсуждение любых абстрактно-философских вещей наподобие паттернов и сфероконичной архитектуры в вакууме — это всегда очень много букв. Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто. 0>А почему обязательно это должны быть абстрактно-философские вещи?
Потому что для чего-то более приземлённого нужно учитывать язык программирования, инструментарий, используемый процесс разработки, уровень команды и тд и тп. Вот вам прекрасный пример обсуждения
. Как только переходим на конкретику — обсуждение сворачивается, потому что тут или знаешь, или нет, обсуждать нечего. А вот потрындеть за "что такое паттерн?" — это всегда пожалуйста
0>Имхо, это признак незрелости нашей отрасли или отдельных людей. 0>Хочется как раз побольше конкретики и лапидарности
Тогда велкам в книги по конкретной технологии. Для дотнета есть книга-исключение, "Framework Design Guidelines": сугубо практичные и проверяемые рекомендации, без воды и закидонов типа "так говорил Фаулер". Для других языков ничего подобного не попадалось, но я особенно и не искал.
Здравствуйте, Sinix, Вы писали:
S>Потому что для чего-то более приземлённого нужно учитывать язык программирования, инструментарий, используемый процесс разработки, уровень команды и тд и тп. Вот вам прекрасный пример обсуждения
. Как только переходим на конкретику — обсуждение сворачивается, потому что тут или знаешь, или нет, обсуждать нечего. А вот потрындеть за "что такое паттерн?" — это всегда пожалуйста
То есть ты считаешь, что само понятие архитектуры существует исключительно в контексте конкретной технологии?
Здравствуйте, 0x7be, Вы писали:
S>>Потому что для чего-то более приземлённого нужно учитывать язык программирования, инструментарий, используемый процесс разработки, уровень команды и тд и тп. 0>То есть ты считаешь, что само понятие архитектуры существует исключительно в контексте конкретной технологии?
Ну и где я такое говорил?
Вопрос был про "почему так много букв вместо пары абзацев", ответил выше:
Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто.
По архитектуре — перечитай пост Gaperton-а по ссылке выше, он там предлагает не смешивать мух с котлетами (дизайн с архитектурой). И подробно расписывает, какое отношение имеет архитектура к используемым технологиям.
Здравствуйте, artelk, Вы писали:
A>Мне нравится Фаулервское объяснение:
Там есть куда более интересный кусок от Ralph Johnson:
There is no theoretical reason that anything is hard to change about software.
If you pick any one aspect of software then you can make it easy to change,
but we don’t know how to make everything easy to change.
Making something easy to change makes the overall system a little more complex,
and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change.
Вот это тру-инженерный подход, в отличие от "мыши станьте ёжиками" Фаулера.
У последнего вообще любая выдернутая из контекста цитата выглядит как шикарное готовое решение. Которое на практике неизменно приводит к "никогда такого не было, и вот опять"
Впрочем, он сам признавался:
I love writing a startling heading [that] have an important meaning that’s not immediately obvious
Согласен.
IT>Хорошая аналогия у Гипертона — архитектура и дизайн соотносятся как стратегия и тактика.
Теперь объясняйте, что такое стратегия, тактика и где между ними происходит граница
UPD: а ведь между ними герр Мольтке ещё и оперативный уровень ввернул
A>Мне кажется, что одной из главных задач архитектора является удаление архитектуры путем устранения необратимости в дизайне ПО.
Я даже знаю как это сделать.
KISS
Сохраняёте её простой и мальенькой.
Если программа целиком умещается в голове программиста, то её всегда можно перестроить.
Здравствуйте, gandjustas, Вы писали:
G>Кроме толщины кармана есть еще time to value, то есть время до того, как потребитель получит ценность. G>А еще есть другой аспект. Зачастую не все архитектурные решения принимает разработчик. В корпоративных системах или навороченных веб-сервисах архитектура может определяться другими компонентами. Поэтому очень важно чтобы то, что ты сделаешь в приложении вписалось в архитектуру системы.
ИМХО, это не критерий отделения архитектуры от неархитектуры. Это просто требования и ограничения, которые надо учитывать при разработке, чтобы не сесть в лужу.
G>Что касается управления рисками, то любое управление по сути управление рисками — будь то управление архитектурой или отделом продаж.
Абсолютно согласен.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, artelk, Вы писали:
A>>Мне нравится Фаулервское объяснение: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf 0>Я полностью согласен с его подходом к определению, но исключительно сомневаюсь в реализуемости принципа устранения архитектуры
Полностью устранить архитектуру невозможно (как минимум, останутся платформа и язык программирования), но сводить её к минимуму можно и нужно
Здравствуйте, Gaperton, Вы писали:
G>Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
ИМХО, важнее то, сможем ли мы легко поменять MS SQL на что-то другое. Если сможем, то MS SQL — это не архитектура, а мелкая деталь реализации.
Здравствуйте, IT, Вы писали:
0>>Что такое архитектура ПО? IT>Не смотря на моё предвзятое отношение к Фаулеру, его определение архитектуры мне видится наиболее кратким и ёмким: IT>
IT>the decisions that are hard to change
Допустим было принято решение писать приложение на Basic'е. Довольно трудно будет потом перейти в разработке приложения с Basic'а на Javа. Можно ли сказать, что язык — это архитектура приложения? Я думаю, что нет.
Допустим было принято решение писать графический интерфейс приложения на wxWindows. Довольно трудно будет потом перейти в разработке приложения перейти с wxWindows на отрисовку, скажем, в OpenGL. Но даже после такого перехода архитектура приложения может сохраниться.
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Архитектура ПО-это и есть сама матрицасистема выполнения определённых задач. Ни больше ни меньше. Определяется
задачами, которые должна эта система выполнять, условиями в которых предпологается её функциониование, ЯП на котором
предпологается написание реализации, программно-аппаратной платформой, на которой будет базироваться эта система при
исполнении.
Не путать эту систему с системой процесса разработки и формирования реализации.
Архитектура системы — это набор фундаментальных принципов и свойств системы, выраженных в ее элементах и взаимосвязях между ними и принципах ее построения (дизайна) и эволюции. В применении к ПО, архитектура — это его статическая и динамическая структура (организация) в совокупности с видимым поведением и показателями качества.
Под дизайном же обычно понимают спецификацию какого-либо элемента ПО. Ну или сам процесс создания этой спецификаци.
Итого, архитектура — это "врожденное" свойство системы, дизайн — часть процесса разработки. У системы есть архритектура, даже если специально ее никто не разрабатывал. Спецификация архитектуры может быть результатом дизайна.
Здравствуйте, ZevS, Вы писали:
ZS>Архитектура системы — это набор фундаментальных принципов и свойств системы, выраженных в ее элементах и взаимосвязях между ними и принципах ее построения (дизайна) и эволюции. В применении к ПО, архитектура — это его статическая и динамическая структура (организация) в совокупности с видимым поведением и показателями качества. ZS>Под дизайном же обычно понимают спецификацию какого-либо элемента ПО. Ну или сам процесс создания этой спецификаци. ZS>Итого, архитектура — это "врожденное" свойство системы, дизайн — часть процесса разработки. У системы есть архритектура, даже если специально ее никто не разрабатывал. Спецификация архитектуры может быть результатом дизайна.
Какой критерий отнесения того или иного решения к архитектуре или дизайну?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Sinix, Вы писали:
S>>По архитектуре — перечитай пост Gaperton-а по ссылке выше, он там предлагает не смешивать мух с котлетами (дизайн с архитектурой). И подробно расписывает, какое отношение имеет архитектура к используемым технологиям.
G>Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
Здравствуйте, ZevS, Вы писали:
0>>Какой критерий отнесения того или иного решения к архитектуре или дизайну? ZS>Я написал что "спецификация архитектуры является результатом дизайна". Это ортогональные вещи, в моем понимании.
Что-то не уловил сначала
Ладно, а что не является архитектурой, и в чем критерий, отделяющий архитектуру от не-архитектуры?
Здравствуйте, ZevS, Вы писали:
ZS>А википедия уже не в почете?
Стенка, на которой каждый пионер может в любую секунду написать все, что ему придет в голову, может быть интересной. Но с какой стати она должна быть в почете?
Кстати, в нашем случае ZS> Архитектура — выкокоуровневая структура, дизайн — процесс специфицирования структуры ну или сама спецификация.
это даже не интересно.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, в нашем случае ZS>> Архитектура — выкокоуровневая структура, дизайн — процесс специфицирования структуры ну или сама спецификация. G>это даже не интересно.
Ровно тоже самое написано в стандарте IEEE 1471 и заменившем его ISO/IEC 42010, и моему пониманию такое определение ближе, чем, скажем, определение Фаулера — "architecture is the set of design decisions that must be made early in a project". Про википедию, это был легкий троллинг))
Рискну предположить: Архитектура — разбиение решения задачи на единицы для тестирования.
Удачное разбиение — уменьшение времени, необходимого для тестирования, более полное покрытие кода,
меньшее число оставшихся ошибок.
Здравствуйте, kokoriko, Вы писали:
K>Рискну предположить: Архитектура — разбиение решения задачи на единицы для тестирования. K>Удачное разбиение — уменьшение времени, необходимого для тестирования, более полное покрытие кода, K>меньшее число оставшихся ошибок.
А почему в качестве критерия разбивки выбрано именно тестирование?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, kokoriko, Вы писали:
K>>Рискну предположить: Архитектура — разбиение решения задачи на единицы для тестирования. K>>Удачное разбиение — уменьшение времени, необходимого для тестирования, более полное покрытие кода, K>>меньшее число оставшихся ошибок. 0>А почему в качестве критерия разбивки выбрано именно тестирование?
Существенным образом влияет на время разработки и полученное качество.
Здравствуйте, 0x7be, Вы писали:
0>Что-то не уловил сначала
0>Ладно, а что не является архитектурой, и в чем критерий, отделяющий архитектуру от не-архитектуры?
Я похоже тоже сначала не уловил вопрос. Меня запутала фраза "не-архитектуры", это может быть всем чем угодно. Но если выбирать только между тем, что влияет на структуру и поведение системы, то можно сказать, что в ахритектуру "попадает" только самое важное для системы с точки зрения ее структуры, использования и развития. А вот что важно, а что не очень, для каждой системы нужно определять каждый раз отдельно. Это не противоречит моему предыдущему ответу.
Здравствуйте, Gaperton, Вы писали:
G>Более внятный термин, чтобы описать явление и проблемы, о которых смутно бредят люди, произнося слово "архитектура" — это Common Design Principles. Вот есть Design. А есть — его Common Principles. G>Наиболее практически полезное определение — про правила. У него, конечно, есть недостатки. Ну, например, его автор не Фаулер. И оно не написано в комитетском стандарте. Зато оно проводит наиболее точную и понятную границу с дизайном, описывает все известные эффекты, как пример с юнит-тестами, приведенный товарищем выше (отличный пример, структурные определения его не описывают), и включает в себя социальные аспекты архитектуры. Потому, что правила выполняются людьми.
Если внимательно почитать, то в комитетском определении учтены "известные эффекты, как пример с юнит-тестами". Другое дело, что стандарт не про архитектуру, а про описание архитекруты, ее спецификацию. Про собственно архитектуру там, по-сути, только определение.
G>Но так как мы уже выяснили, что одного единственно верного определения для сложных явлений не бывает — каждый волен пользоваться своим любимым.
Сложное явление является ровно тем, что говорит определение, на то оно и определение. А отсутствие единства в том, что такое архитектура ПО просто показывает незрелость отрасли.
Здравствуйте, ZevS, Вы писали:
G>>Но так как мы уже выяснили, что одного единственно верного определения для сложных явлений не бывает — каждый волен пользоваться своим любимым. ZS>Сложное явление является ровно тем, что говорит определение, на то оно и определение.
Только в математике определение определяет то, чем является объект или явление.
В жизни и пророде все не так — сложное явление является само, и плевать хотелo на все наши определения. Особенно — на откровенно неудачные.
ZS>А отсутствие единства в том, что такое архитектура ПО просто показывает незрелость отрасли.
Странное дело, все-таки. В "отрасли" уже несколько поколений сменилось, а она все незрелее и незрелее
Здравствуйте, Gaperton, Вы писали:
G>Только в математике определение определяет то, чем является объект или явление. G>В жизни и пророде все не так — сложное явление является само, и плевать хотелo на все наши определения. Особенно — на откровенно неудачные.
Архитектура это не явление, а абстрактное поняние. А понятие без определения не существует.
ZS>>А отсутствие единства в том, что такое архитектура ПО просто показывает незрелость отрасли. G>Странное дело, все-таки. В "отрасли" уже несколько поколений сменилось, а она все незрелее и незрелее
Тут нужно дать определение зрелости отрасли
Прочитал по диагонали, но сам думаю так:
Архитектура — части системы, из которых создается программное окружение, архитектурный компонент можно выкинуть или заменить, внести значительные изменения маловероятно. Дизай это программная реализация модели реального мира в выбранном программном окружении.
Приведу граничные условия для ясности:
Например в проекте используется open source библиотека или билиотека другой команды — это архитектурный компонент, т.к. он не является реализацией нашей программной модели, а реализует свою модель реального мира и адаптировать его под себя сложно или невозможно, т.к. требования могут быть взаимо исключающими.
Считаю, что в архитектуре изначально следует предположить от чего необходимо асбтрагироваться( например транспорт), а к чему можно быть прибитым намертво (например Ось, БД).
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО?
Это набор практик организации кода, позволяющих продукту эволюционировать с сохранением его maintainability. Хорошую архитектуру, как и хорошего сисадмина, должно быть незаметно (UPD: в том смысле, что она не должна вставлять палки в колёса разработчикам).
Здравствуйте, mrTwister, Вы писали:
T>То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Наоборот, они именно влияли на код самого продукта — фичи не появились благодаря этим тестам, они препятствовали появлению в коде каких то фич.
В этом плане твои тесты являются тем самым архитектурным решением — они определяют принятие дальнейших решений, т.к. вводят неявные требования, ограничения и тд.
Здравствуйте, 0x7be, Вы писали:
0>В связи с этим хочу провести тут опрос на эту тему. Пожалуйста, дайте ответы на следующие вопросы:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Нужно брать готовые, понятные термины, лучше всего из военного дела. Например — стратегия и тактика. Стратегические и тактические решения.
Если принимаем решение "играть в постоянной атаке, аргессивно, подвижно, гибко" то ясно, что тактика создания мощных крепостей, долговременных укреплений, рытьё окопов и тд есть отстой. А если принято решение "играем от защиты", то ровно те же тактические решения становятся очень правильными. Примерно так же можно говорить о глобальном, локальном и тд решении.
При этом, как часто бывает, начинается всё без какого либо плана. Если какой то умник решил, условно, оборонительные вооружения применить "просто так, потому что они крутые", то фактически тем самым определил большую часть будущих проблем.
На софт всё это переносится один к одному. Архитектура(стратегия) есть явно и неявно принятые требования, ограничения и правила дизайна, которые учитывают достижение цели, решение проблемы и тд, в глобальном масштабе. Дизайн(тактика) — это определение и достижение локальных целей согласно стратегическим решениям.
Если нам не помогут, то мы тоже никого не пощадим.
