К>В общем, допустим, есть некоторое решение, архитектура для решения определённых задач. Есть ощущение, что во всей этой схеме присутствую переусложения. К примеру страдает testability отдельных частей системы, т.е. есть повышенная связность и поднимать целый сервер для тестирования одной "фичи" на мой взгляд это уже достаточно заметный "bad smell". К>Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)?
Дробить и обосабливать пока евозможно. Если не возможно — ещё задуматься, дробить и обосабливать.
Здравствуйте, VGn, Вы писали:
VGn>Дробить и обосабливать пока евозможно. Если не возможно — ещё задуматься, дробить и обосабливать.
Дробить решение на отдельные компоненты? Но это на мой вгляд даст лишь выводы по поводу большой связности...
Важная проблема архитектуры, но не единственная, я думаю.
К>Дробить решение на отдельные компоненты? Но это на мой вгляд даст лишь выводы по поводу большой связности... К>Важная проблема архитектуры, но не единственная, я думаю.
Решение на слои, слои на компоненты, компоненты на узлы.
Выделение интерфейсов даст обособление и возможности гибкого тестирования и расширяемости.
Выделение слоя(ёв)-контроллера даст бОльшую расширяемость.
Мелкие блоки более устойчивы к масштабированию функциональности и количества данных.
Здравствуйте, VGn, Вы писали:
VGn>Мелкие блоки более устойчивы к масштабированию функциональности и количества данных.
Только надо следить за тем чтоб не переборщить
Лишняя косвенность может и аукнуться, скажем, на производительности.
Как всегда надо исходить из поставленной задачи.
Вопрос только как ты будешь решать проблему производительности, если она возникнет? Апгрейдом железа?
Тоже, конечно, вариант, только не всегда он применим.
Принцип разделения на слои полезен, не спорю, просто надо не забывать мозг использовать, т.к. как любое другое средство он может быть и вреден.
К>Вопрос только как ты будешь решать проблему производительности, если она возникнет? Апгрейдом железа?
Отдельные узлы — это, как правило и отдельные таблицы, а значит производительности скорее плюс.
Выделение элементарных операций доступа к данным в хранимые процедуры производительность также увеличивает.
Программная производительность при прохождении дополнительных слоёв снижается обычно на пару десятков тактов процессора. Это — смешно.
Минус — кода больше.
Плюс — этот код проще и его может писать больше народа.
Минус — больше документации.
Плюс — эта документация конкретнее.
Минус — сложнее рефакторинг.
Плюс — его меньше.
К>Тоже, конечно, вариант, только не всегда он применим. К>Принцип разделения на слои полезен, не спорю, просто надо не забывать мозг использовать, т.к. как любое другое средство он может быть и вреден.
Это было в весёлой цитате по ссылке.
Естественно, дробление — не панацея. Но при таком диагнозе — первое средство.
К>В том и дело, что хочется хоть какой-нибудь базис для формализации критериев сложности системы, хотябы для категоризации проблем.
А зачем тут формализация. Это больше аналитическая задача.
Длинные методы — плохо.
Длинные запросы — плохо.
Повторение кода — отвратительно.
Похожий код — стоит задуматься.
Раздутый класс, ответственный за всё — палкой по рукам тому кодеру.
Куча функциональных классов-сервисов — наверное им требуются фабрики.
Связность связностью, а что у нас там с зацеплением?
Для чего в таблице 40 полей, из них 10 полей-флагов и т. д.
Хотя и такую работу могут выполнять специальные средства. Последняя студия довольно критично настроена на синтаксический анализ кода и даёт неплохие советы по низкоуровневой архитектуре.
Здравствуйте, VGn, Вы писали:
К>>В том и дело, что хочется хоть какой-нибудь базис для формализации критериев сложности системы, хотябы для категоризации проблем.
VGn>А зачем тут формализация. Это больше аналитическая задача. VGn>Длинные методы — плохо.
[cut]
VGn>Хотя и такую работу могут выполнять специальные средства. Последняя студия довольно критично настроена на
синтаксический анализ кода и даёт неплохие советы по низкоуровневой архитектуре.
Ну автоматические средства это лишь против примитивных случаев и скорее говорит об ограниченности языка, который допускает такое, что могут диагностировать другие тулы. Но это длинная долгая и старая тема Речь не об этом. Хотелось что-то типа guidelines с аргументацией почему проблема является проблемой и в каких условиях.
Тупая категоризация уже способна дать неплохую помощь. Т.е. хотелось понять как создать контрольный список (чеклист) для проверки архитектуры на вменяемость, точнее его базовый вариант, который бы расширялся в ходе итеративного процесса работы.
К>Ну автоматические средства это лишь против примитивных случаев и скорее говорит об ограниченности языка, который допускает такое, что могут диагностировать другие тулы. Но это длинная долгая и старая тема Речь не об этом. Хотелось что-то типа guidelines с аргументацией почему проблема является проблемой и в каких условиях. К>Тупая категоризация уже способна дать неплохую помощь.
Именно этим она и занимается.
О правильности кода речи не идёт.
Я имел в виду Code Analysis и FxCop.
см например http://www.vitalygorn.com/blog/post/2007/11/Code-Metrics-in-Visual-Studio-2008.aspx
Здравствуйте, VGn, Вы писали:
К>>Ну автоматические средства это лишь против примитивных случаев и скорее говорит об ограниченности языка, который допускает такое, что могут диагностировать другие тулы. Но это длинная долгая и старая тема Речь не об этом. Хотелось что-то типа guidelines с аргументацией почему проблема является проблемой и в каких условиях. К>>Тупая категоризация уже способна дать неплохую помощь. VGn>Именно этим она и занимается. VGn>О правильности кода речи не идёт. VGn>Я имел в виду Code Analysis и FxCop. VGn>см например VGn>http://www.vitalygorn.com/blog/post/2007/11/Code-Metrics-in-Visual-Studio-2008.aspx
Круто, только речь-то шла всё равно немного о другом
Тулзы ничего не стоят, если у использующего эти тулзы нет понимания, чтож они делают.
Но там есть полезная ссылка на индексную технику поддерживаемости (Maintainability Index Technique) SEI, думаю это очень близко к тому, о чём я спрашивал, спасибо.
Здравствуйте, VGn, Вы писали:
К>>Круто, только речь-то шла всё равно немного о другом К>>Тулзы ничего не стоят, если у использующего эти тулзы нет понимания, чтож они делают.
VGn>Ты о том, даёт ли она советы? Даёт, зараза, опухнешь от объёма советов. Приходится отключать во время отладки.
Дак в том и смысл итеративности чеклиста
Критерии периодически просматриваются на применимость и полезность. Плюс добавляются новые.
А тул он лишь тул, новые параметры он же сам придумать не сможет, и чтоб бороться с объёмами цифр и добавлять новые параметры надо хотябы понимать смысл имеющихся + ещё чуть-чуть
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Курилка, Вы писали:
К>>Какие ещё существуют критерии для выявления проблем архитектуры с точки зрения дизайна, расширяемости и т.п., а не с точки зрения требований (в том числе нефункциональных по времени выполнения, памяти и т.д.)?
M>Я полагаю, достаточно одного критерия адекватности архитектуры задаче. Этот критерий называется "сложность". Простую архитектуру легко тестировать, легко поддерживать и легко расширять. Под сложностью в данном случае удобно понимать меру неоднородности. Не уверен, что сложность можно оценить формально, но интуитивно неоднородность достаточно хорошо чувствуется. Если у нас есть 10 частей систему действующих сходным образом, то это лучше чем 10 частей, действующих по разному. 100 сходных классов соответствующих 100 таблицам в БД лучше одного класса, инкапсулирующего в себе 400 запросов....
10 однородных классов может быть и лучше (понятнее) 10ти классов делающих одно и то же, но каждый по-своему; но я не считаю, что однородность — это то, к чему стоит стремиться. И в том и в другом случае имеет место дублирование, только в однородной структуре это дублирование очевиднее. И избавляться нужно именно от дублирования, а не просто писать классы так, чтобы они были друг на друга похожи.
