Disclaimer. Возможно вопрос покажется слишком абстрактным и общим, надеюсь обсуждение подскажет направления для обдумывания темы (мне и не только мне ).
В общем, допустим, есть некоторое решение, архитектура для решения определённых задач. Есть ощущение, что во всей этой схеме присутствую переусложения. К примеру страдает testability отдельных частей системы, т.е. есть повышенная связность и поднимать целый сервер для тестирования одной "фичи" на мой взгляд это уже достаточно заметный "bad smell".
Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)?
[skipped]
Может речь идет о принципах простого дизайна "Do the Simplest Thing that Could Possibly Work" и "You Aren't Going to Need It" (YAGNI)? Здесь разжевано: "Проектирования больше нет?", Мартин Фаулер.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>[skipped] R>Может речь идет о принципах простого дизайна "Do the Simplest Thing that Could Possibly Work" и "You Aren't Going to Need It" (YAGNI)? Здесь разжевано: "Проектирования больше нет?", Мартин Фаулер.
В том и дело, что там ничего не разжёвано
YAGNI и KISS это хорошо, но они не дают каких-то конкретных рекомендаций, кроме абстрактного "неделанья ненужной работы".
Да и речь о том, что некая архитектура уже есть и работа идёт в рамках её. Т.е. хочется покритиковать и выявить слабые места.
Ещё эти принципы особо не противоречат явно наличию большой связности.
GZ>Если метрики качества — то посмотри статью здесь. Далее гугл. Для некоторых метрик существуют инструменты.
Яж предупреждал, что вопрос, к сожалению не совсем чёткий
Вопрос, наверное, относится к обоим терминам, а состоит в выявлении узких местах, дающих переусложение (к примеру большая связность), реально будет проявляться в большей стоимости владения, и возможно в реализации других требований (например с переносимостью могу возникнуть запарки). Метрики же дадуту увидеть лишь последствия.
Хотелось бы подумать о причинах. Пока я вижу как пример такой причины лишь большую связность и как проявлении её — усложение тестирования частей системы.
Здравствуйте, Курилка, Вы писали:
К>Хотелось бы подумать о причинах. Пока я вижу как пример такой причины лишь большую связность и как проявлении её — усложение тестирования частей системы.
Большая связность — прежде всего не тестирование, но и стоимость внесения изменений/исправлений.
Вообще-же, легко посмотреть просто как меряются метрики. Ну например, большая связность это наличие большого количества связей между многими классами. Если у тебя меняется интерфейс, а у тебя большая связность, то тебе придется вносить большое количество изменений. Если у тебя кол-во зависимых классов — 30-40, то и ежу понятно что это не есть хорошо. О том, что глобальные данные влияют на функционирование всего проекта, и их изменение очень дорогое, я думаю объяснять тоже никому не нужно.
Или сложность (complexity). Если у тебя штук 30 if/while/for в одной процедуре, и даже если поймешь что где и как, то внесение изменений может вполне развалить саму процедуру. Я, например, если процедура занимает больше экрана, то рефакторю(и требую оного) обязательно.
Это все в принципе описано в самих метриках. Сами метрики информативны. И в документации к ним вполне нормально описано зачем и почему.
Здравствуйте, Курилка, Вы писали:
К>Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)?
GRASP?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Курилка, Вы писали:
К>>Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)? B>GRASP?
Ларман? Спасибо, надо будет посмотреть повнимательней.
Здравствуйте, Курилка, Вы писали:
К>Disclaimer. Возможно вопрос покажется слишком абстрактным и общим, надеюсь обсуждение подскажет направления для обдумывания темы (мне и не только мне ).
К>В общем, допустим, есть некоторое решение, архитектура для решения определённых задач. Есть ощущение, что во всей этой схеме присутствую переусложения. К примеру страдает testability отдельных частей системы, т.е. есть повышенная связность и поднимать целый сервер для тестирования одной "фичи" на мой взгляд это уже достаточно заметный "bad smell". К>Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)?
Возможно полезно будет обратить внимание на следующие принципы (Agile Principles, Patterns, and Practices in C# By Martin C. Robert, Martin Micah):
The Single-Responsibility Principle
A class should have only one reason to change.
The Open/Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
The Liskov Substitution Principle
Subtypes must be substitutable for their base types.
The Dependency-Inversion Principle
1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.
The Interface Segregation Principle
This principle deals with the disadvantages of "fat" interfaces. Classes whose interfaces are not cohesive have "fat" interfaces. In other words, the interfaces of the class can be broken up into groups of methods. Each group serves a different set of clients. Thus, some clients use one group of methods, and other clients use the other groups.
P>Возможно полезно будет обратить внимание на следующие принципы (Agile Principles, Patterns, and Practices in C# By Martin C. Robert, Martin Micah):
[cut]
Спасибо, вроде близко к тому, о чём спрашивал, но, наверное, хотелось бы более структурированное и обоснованное рассмотрение, насколько книга подходит под такое? Howtos это полезно, но хочется "копнуть глубже" и коснуться к примеру антипаттернов и причин полезности подобных howtos. Т.е. что-нибудь наподобие этого
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, pt4h, Вы писали:
P>>Возможно полезно будет обратить внимание на следующие принципы (Agile Principles, Patterns, and Practices in C# By Martin C. Robert, Martin Micah):
К>[cut]
К>Спасибо, вроде близко к тому, о чём спрашивал, но, наверное, хотелось бы более структурированное и обоснованное рассмотрение, насколько книга подходит под такое? Howtos это полезно, но хочется "копнуть глубже" и коснуться к примеру антипаттернов и причин полезности подобных howtos. Т.е. что-нибудь наподобие этого
Я не совсем согласен, что это howtos. В этой книге (точнее в 5-ти главах, посвещенных перечисленным принципам) рассматриваются глобальные вопросы ОО проектирования. Она описывает последствия отступления от этих принципов. То есть это не паттерны, это принципы, что как мне показалось Вам и надо.
The Single-Responsibility Principle is one of the simplest of the principles but one of the most difficult to get right. Conjoining responsibilities is something that we do naturally. Finding and separating those responsibilities is much of what software design is really about. Indeed, the rest of the principles we discuss come back to this issue in one way or another.
Указанный в ответе выше GRASP, как мне кажется, является смесью паттернов и принципов. Например, High Cohesion соответствует принципу Single-Responsibility Principle, Low Coupling — Open/Closed Principle + Dependency-Inversion Principle, а Factory соответсвует паттерну Abstract Factory от GOF.
Здравствуйте, Курилка, Вы писали:
К>Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)?
Я полагаю, достаточно одного критерия адекватности архитектуры задаче. Этот критерий называется "сложность". Простую архитектуру легко тестировать, легко поддерживать и легко расширять. Под сложностью в данном случае удобно понимать меру неоднородности. Не уверен, что сложность можно оценить формально, но интуитивно неоднородность достаточно хорошо чувствуется. Если у нас есть 10 частей систему действующих сходным образом, то это лучше чем 10 частей, действующих по разному. 100 сходных классов соответствующих 100 таблицам в БД лучше одного класса, инкапсулирующего в себе 400 запросов и содержащего 800 методов. Аналогично, для одной и той же задачи, 10 объектов обращающихся к БД напрямую каждый со своими запросами, хуже трех классов ORM, но лучше 10 классов, каждый из которых содержит механизм работы с собственным хранилищем.
Здравствуйте, Miroff, Вы писали:
M>Я полагаю, достаточно одного критерия адекватности архитектуры задаче. Этот критерий называется "сложность". Простую архитектуру легко тестировать, легко поддерживать и легко расширять. Под сложностью в данном случае удобно понимать меру неоднородности. Не уверен, что сложность можно оценить формально, но интуитивно неоднородность достаточно хорошо чувствуется. Если у нас есть 10 частей систему действующих сходным образом, то это лучше чем 10 частей, действующих по разному. 100 сходных классов соответствующих 100 таблицам в БД лучше одного класса, инкапсулирующего в себе 400 запросов и содержащего 800 методов. Аналогично, для одной и той же задачи, 10 объектов обращающихся к БД напрямую каждый со своими запросами, хуже трех классов ORM, но лучше 10 классов, каждый из которых содержит механизм работы с собственным хранилищем.
В том и дело, что хочется хоть какой-нибудь базис для формализации критериев сложности системы, хотябы для категоризации проблем.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, pt4h, Вы писали:
К>>>Здравствуйте, pt4h, Вы писали:
К>[cut]
К>ОК, надо почитать и разобраться лично, спасибо.
Кстати, в этой же книге есть принципы компоновки классов в пространства имен — рассматриваются проблемы зависимостей, реюза, релиза, расширяемости.
Здравствуйте, Курилка, Вы писали:
К>В том и дело, что хочется хоть какой-нибудь базис для формализации критериев сложности системы, хотябы для категоризации проблем.
Боюсь формальных критериев нет. Либо что-нибудь уж совсем общее, да и то, основанное на субъективных оценках. К тому же к разным типам приложений, взять, например, .NET FW и бизнес логику какого-нибудь бизнес приложения, предъявляются принципиально разные требования. Для первого очень важно продуманность интерфейсов и полнота покрытия тестами. Дла последнего главный критерий возможность безболезненного расширения и модификации функциональности.
Ещё можно попробовать верефицировать необходимость того или иного архитектурного решения путём сравнения проблем, которые оно решает, с проблемами, которые оно привносит.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Курилка, Вы писали:
К>>В том и дело, что хочется хоть какой-нибудь базис для формализации критериев сложности системы, хотябы для категоризации проблем.
IT>Боюсь формальных критериев нет. Либо что-нибудь уж совсем общее, да и то, основанное на субъективных оценках. К тому же к разным типам приложений, взять, например, .NET FW и бизнес логику какого-нибудь бизнес приложения, предъявляются принципиально разные требования. Для первого очень важно продуманность интерфейсов и полнота покрытия тестами. Дла последнего главный критерий возможность безболезненного расширения и модификации функциональности.
Мне кажется, что все же можно как минимум наложить метрику вида "следует или нет заданным принципам". Например, последнее ваше утверждение очень хорошо проверяется следованию следующего принципа:
The Open/Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
When a single change to a program results in a cascade of changes to dependent modules, the design smells of rigidity. OCP advises us to refactor the system so that further changes of that kind will not cause more modifications. If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works.
То есть, таким образом мы можем приблизительно увидеть насколько архитектура приложения способна пережить несколько версий без тотального переписывания или вставки костылей... Хотя конечно и очень приблизительно...
IT>Ещё можно попробовать верефицировать необходимость того или иного архитектурного решения путём сравнения проблем, которые оно решает, с проблемами, которые оно привносит.
Согласен, over-designed vs under-designed тоже напрямую относится к выше указонному принципу — нельзя и не надо предусматривать точки расширения на все случаи жизни.
В целом это не единственный принцип, который можно наложить на архитектуру и попытаться ее оценить...
P>The Open/Closed Principle (OCP)
P>Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
P>When a single change to a program results in a cascade of changes to dependent modules, the design smells of rigidity. OCP advises us to refactor the system so that further changes of that kind will not cause more modifications. If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works.
P>То есть, таким образом мы можем приблизительно увидеть насколько архитектура приложения способна пережить несколько версий без тотального переписывания или вставки костылей... Хотя конечно и очень приблизительно...
Принцип правильный. Но он скорее относится к гигиене, а не к архитектуре.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, pt4h, Вы писали:
P>>
P>>The Open/Closed Principle (OCP)
IT>Принцип правильный. Но он скорее относится к гигиене, а не к архитектуре.
Под гигиеной/архитектурой ты подразумеваешь тактический/стратегический дизайн?
Речь шла о некоем "решении", оно же включает как то так и другое. Скажем те же EJB — там есть и то и другое, вопрос в том как формулировать критерии для проверки. За мысль про сравнение проблем спасибо.
А про общее решение — я ж не ищу 42
Идея была что за столькие годы создания программных продуктов должны же появиться наиболее полезные и широкоупотребимые критерии, с учётом специфики задачи, конечно.
Здравствуйте, Курилка, Вы писали:
К>Под гигиеной/архитектурой ты подразумеваешь тактический/стратегический дизайн?
Что-то типа того. Впрочем грань тут довольно размыта.
К>Идея была что за столькие годы создания программных продуктов должны же появиться наиболее полезные и широкоупотребимые критерии, с учётом специфики задачи, конечно.
Слишком всё субъективно и сликом много специфики у каждого, в том числе специфики не только задач, но и условий, в которых они решаются. Например, сжатые сроки могут отрицательно повлиять на архитектуру, но это будет вполне оправдано. Так что у каждого своя модель, свои критерии, некоторые из них выкристализовываются в виде общепринятых patterns и best practices, а некоторые нет, потому что оправданы только в определённых условиях.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
).
Если нам не помогут, то мы тоже никого не пощадим.
