Сообщение Re[12]: [Опрос, холивар?]: Что такое архитектура? от 31.03.2015 14:39
Изменено 31.03.2015 14:45 Gaperton
Здравствуйте, mrTwister, Вы писали:
G>>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно.
Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
T>Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
T>Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
Некоторые правила поменять проще, другие — сложнее. Используя термин "архитектурно значимые" ты как бы говоришь, что те правила, которые на первый взгляд проще поменять — менее важны. И их как бы не надо соблюдать.
Но это не так. Если наплевать на правило распределения по папкам и сборкам, у тебя, например, сломается паттерн Layer. Суть которого, в общем, и состоит в том, что ты раскладываешь код по модулям не абы как, а очень даже осмысленно. Соблюдение этого правила может довольно сильно влиять не только на положения файла в папке, но и на объектную декомпозицию. Которую, если забить на правило с папками, потом поменять может быть уже совсем не дешево.
T>С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Некоторые правила соблюдать затратно, а некоторые — не очень. Правило наличия black-box тестов с самого начала было "архитектурой". Просто сначала его было не так затратно соблюдать. Так бывает. Чем дольше разрабатывается продукт, тем больше начинают мешать старые правила, и тем в целом затратнее становится их менять.
Обращать внимание (и считать "архитектурно значимыми") только на те правила, которые доставляют проблемы или которые дорого менять сейчас — не самый полезный способ думать, ИМХО. С таким подходом ты рискуешь все пропустить, и все всегда будет внезапно. А это не то, что мы хотим.
G>>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно.
Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.T>Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
T>Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
Некоторые правила поменять проще, другие — сложнее. Используя термин "архитектурно значимые" ты как бы говоришь, что те правила, которые на первый взгляд проще поменять — менее важны. И их как бы не надо соблюдать.
Но это не так. Если наплевать на правило распределения по папкам и сборкам, у тебя, например, сломается паттерн Layer. Суть которого, в общем, и состоит в том, что ты раскладываешь код по модулям не абы как, а очень даже осмысленно. Соблюдение этого правила может довольно сильно влиять не только на положения файла в папке, но и на объектную декомпозицию. Которую, если забить на правило с папками, потом поменять может быть уже совсем не дешево.
T>С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Некоторые правила соблюдать затратно, а некоторые — не очень. Правило наличия black-box тестов с самого начала было "архитектурой". Просто сначала его было не так затратно соблюдать. Так бывает. Чем дольше разрабатывается продукт, тем больше начинают мешать старые правила, и тем в целом затратнее становится их менять.
Обращать внимание (и считать "архитектурно значимыми") только на те правила, которые доставляют проблемы или которые дорого менять сейчас — не самый полезный способ думать, ИМХО. С таким подходом ты рискуешь все пропустить, и все всегда будет внезапно. А это не то, что мы хотим.
Здравствуйте, mrTwister, Вы писали:
G>>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.
T>Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
T>Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
Некоторые правила поменять проще, другие — сложнее. Используя термин "архитектурно значимые" ты как бы говоришь, что те правила, которые на первый взгляд проще поменять — менее важны. И их как бы не надо соблюдать.
Но это не так. Если наплевать на правило распределения по папкам и сборкам, у тебя, например, сломается паттерн Layer. Суть которого, в общем, и состоит в том, что ты раскладываешь код по модулям не абы как, а очень даже осмысленно. Соблюдение этого правила может довольно сильно влиять не только на положения файла в папке, но и на объектную декомпозицию. Которую, если забить на правило с папками, потом поменять может быть уже совсем не дешево.
И это вполне естественно, если принимать во внимание, что с точки зрения дизайна самое интересное происходит не внутри модулей, а между ними. Интерфейсы.
T>С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Некоторые правила соблюдать затратно, а некоторые — не очень. Правило наличия black-box тестов с самого начала было "архитектурой". Просто сначала его было не так затратно соблюдать. Так бывает. Чем дольше разрабатывается продукт, тем больше начинают мешать старые правила, и тем в целом затратнее становится их менять.
Обращать внимание (и считать "архитектурно значимыми") только на те правила, которые доставляют проблемы или которые дорого менять сейчас — не самый полезный способ думать, ИМХО. С таким подходом ты рискуешь все пропустить, и все всегда будет внезапно. А это не то, что мы хотим.
G>>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно.
Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.T>Согласен, что архитектуру можно рассматривать, как набор правил проектирования. Только не каждое такое правило является архитектурно значимым.
T>Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.
Некоторые правила поменять проще, другие — сложнее. Используя термин "архитектурно значимые" ты как бы говоришь, что те правила, которые на первый взгляд проще поменять — менее важны. И их как бы не надо соблюдать.
Но это не так. Если наплевать на правило распределения по папкам и сборкам, у тебя, например, сломается паттерн Layer. Суть которого, в общем, и состоит в том, что ты раскладываешь код по модулям не абы как, а очень даже осмысленно. Соблюдение этого правила может довольно сильно влиять не только на положения файла в папке, но и на объектную декомпозицию. Которую, если забить на правило с папками, потом поменять может быть уже совсем не дешево.
И это вполне естественно, если принимать во внимание, что с точки зрения дизайна самое интересное происходит не внутри модулей, а между ними. Интерфейсы.
T>С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Некоторые правила соблюдать затратно, а некоторые — не очень. Правило наличия black-box тестов с самого начала было "архитектурой". Просто сначала его было не так затратно соблюдать. Так бывает. Чем дольше разрабатывается продукт, тем больше начинают мешать старые правила, и тем в целом затратнее становится их менять.
Обращать внимание (и считать "архитектурно значимыми") только на те правила, которые доставляют проблемы или которые дорого менять сейчас — не самый полезный способ думать, ИМХО. С таким подходом ты рискуешь все пропустить, и все всегда будет внезапно. А это не то, что мы хотим.