Здравствуйте, 0x7be, Вы писали:
0>Соответственно, разработка архитектуры — это по сути управление рисками.
Не только. В бОльшей степени — это отказ от принятия решений, принимать которые нет необходимости. Очень часто архитектурные ошибки заключаются в том, что были приняты необязательные архитектурные решения. Необязательные они в том смысле, что эти решения можно было бы и не принимать, но разработчики, часто ориентируясь на прошлый опыт, зачем-то их приняли и столкнулись с тем, что эти решения не соответствуют реалиям проекта.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, artelk, Вы писали:
A>>Мне нравится Фаулервское объяснение: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf 0>Я полностью согласен с его подходом к определению, но исключительно сомневаюсь в реализуемости принципа устранения архитектуры
Полностью устранить архитектуру невозможно (как минимум, останутся платформа и язык программирования), но сводить её к минимуму можно и нужно
Здравствуйте, Gaperton, Вы писали:
G>Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
ИМХО, важнее то, сможем ли мы легко поменять MS SQL на что-то другое. Если сможем, то MS SQL — это не архитектура, а мелкая деталь реализации.
Здравствуйте, mrTwister, Вы писали:
G>>Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
T>ИМХО, важнее то, сможем ли мы легко поменять MS SQL на что-то другое. Если сможем, то MS SQL — это не архитектура, а мелкая деталь реализации.
Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
А уж насколько конкретные правила (и существующий код, оформленный в соответствии с ними) мешают или помогают проектировать — это второй вопрос.
Здравствуйте, Gaperton, Вы писали:
G>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Здравствуйте, IT, Вы писали:
0>>Что такое архитектура ПО? IT>Не смотря на моё предвзятое отношение к Фаулеру, его определение архитектуры мне видится наиболее кратким и ёмким: IT>
IT>the decisions that are hard to change
Допустим было принято решение писать приложение на Basic'е. Довольно трудно будет потом перейти в разработке приложения с Basic'а на Javа. Можно ли сказать, что язык — это архитектура приложения? Я думаю, что нет.
Допустим было принято решение писать графический интерфейс приложения на wxWindows. Довольно трудно будет потом перейти в разработке приложения перейти с wxWindows на отрисовку, скажем, в OpenGL. Но даже после такого перехода архитектура приложения может сохраниться.
Здравствуйте, B0FEE664, Вы писали:
BFE>Допустим было принято решение писать приложение на Basic'е. Довольно трудно будет потом перейти в разработке приложения с Basic'а на Javа. Можно ли сказать, что язык — это архитектура приложения? Я думаю, что нет.
Выбор языка — это, разумеется, архитектурное решение.
BFE>Допустим было принято решение писать графический интерфейс приложения на wxWindows. Довольно трудно будет потом перейти в разработке приложения перейти с wxWindows на отрисовку, скажем, в OpenGL. Но даже после такого перехода архитектура приложения может сохраниться.
Библиотека для UI тоже может быть архитектурно значимым решением, причем как правило так и есть. В этом случае при смене UI библиотеки архитектура меняется, даже если структура приложения сохраняется. Структура приложения — это еще не архитектура.
Здравствуйте, mrTwister, Вы писали:
G>>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
T>Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
T>Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
Некоторые правила поменять проще, другие — сложнее. Используя термин "архитектурно значимые" ты как бы говоришь, что те правила, которые на первый взгляд проще поменять — менее важны. И их как бы не надо соблюдать.
Но это не так. Если наплевать на правило распределения по папкам и сборкам, у тебя, например, сломается паттерн Layer. Суть которого, в общем, и состоит в том, что ты раскладываешь код по модулям не абы как, а очень даже осмысленно. Соблюдение этого правила может довольно сильно влиять не только на положения файла в папке, но и на объектную декомпозицию. Которую, если забить на правило с папками, потом поменять может быть уже совсем не дешево.
И это вполне естественно, если принимать во внимание, что с точки зрения дизайна самое интересное происходит не внутри модулей, а между ними. Интерфейсы.
T>С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Некоторые правила соблюдать затратно, а некоторые — не очень. Правило наличия black-box тестов с самого начала было "архитектурой". Просто сначала его было не так затратно соблюдать. Так бывает. Чем дольше разрабатывается продукт, тем больше начинают мешать старые правила, и тем в целом затратнее становится их менять.
Обращать внимание (и считать "архитектурно значимыми") только на те правила, которые доставляют проблемы или которые дорого менять сейчас — не самый полезный способ думать, ИМХО. С таким подходом ты рискуешь все пропустить, и все всегда будет внезапно. А это не то, что мы хотим.
Здравствуйте, 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". Про википедию, это был легкий троллинг))
Здравствуйте, 0x7be, Вы писали:
0>Ладно, а что не является архитектурой, и в чем критерий, отделяющий архитектуру от не-архитектуры?
На мой взгляд, в данной формулировке вопрос бессмысленен, переформулирую. По-моему, ты хотел спросить, какую часть архитектуры и до какой степени детализации нужно специфицировать на ранней стадии проекта. Если так, то ответ уже в вопросе — на ранней стадии должно быть определенно то, что будет дорого или невозможно поменять на позже. Это могут быть языки программирования, ОС, транспорт, трех/двух-звенка, тип пользовательского интерфейса, протоколы взаимодействия.... Некоторые же вещи на ранней стадии специфицировать вообще невозможно. Для каждой системы набор будет свой.
Рискну предположить: Архитектура — разбиение решения задачи на единицы для тестирования.
Удачное разбиение — уменьшение времени, необходимого для тестирования, более полное покрытие кода,
меньшее число оставшихся ошибок.
Здравствуйте, kokoriko, Вы писали:
K>Рискну предположить: Архитектура — разбиение решения задачи на единицы для тестирования. K>Удачное разбиение — уменьшение времени, необходимого для тестирования, более полное покрытие кода, K>меньшее число оставшихся ошибок.
А почему в качестве критерия разбивки выбрано именно тестирование?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, kokoriko, Вы писали:
K>>Рискну предположить: Архитектура — разбиение решения задачи на единицы для тестирования. K>>Удачное разбиение — уменьшение времени, необходимого для тестирования, более полное покрытие кода, K>>меньшее число оставшихся ошибок. 0>А почему в качестве критерия разбивки выбрано именно тестирование?
Существенным образом влияет на время разработки и полученное качество.
