Architecture Anti-patterns: Automatically Detectable Violations of Design Principles (Рубрика #Architecture)
Эта статья посвящена интересной для меня теме architecture governance. В ней авторы рассказывают о своих подходах для автоматического нахождения архитектурных анти-паттернов в больших системах. Суть в том, что файлы, которые подвержены изменениям и ошибкам редко в таких системах живут поодиночке - обычно они архитектурно связаны и эти связи отображают архитектурные проблемы, которые приводят к распространению подверженности ошибкам. В этой статье авторы определяют набор антипаттернов, взяв за основу фундаментальные принципы дизайна и Baldwin and Clark’s design rule theory. Дальше они валидируют на опыте набор архитектурных анти-паттернов, которые можно автоматически находить анализируя структурные взаимоотношения в проекте, а также историю изменений. Для этого авторы проанализировали 19 крупномасштабрных системы и показали
1. Files involved in these architecture anti-patterns are more error-prone and change-prone;
2. The more anti-patterns a file is involved in, the more error-prone and change-prone it is; and
3. While all of our defined architecture anti-patterns contribute to file’s error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.
В итоге, у авторов получилось 6 антипаттернов:
1. Unstable Interface - интерфейсы, от которых многие зависят, должны оставаться стабильными
2. Modularity Violation Groups - независимые модули должны и эволюционировать независимо
3. Unhealthy Inheritance Hierarchy - этот антипаттерн про нарушение Liskov Substitution principle
4. Crossing - a file that has both high fan-in and high fan-out, and changes often together with its dependents and the files it depends on, is often at the center of maintenance activities.
5. Clique - набор файлов, которые формируют сильно-связный граф, что приводит к tight coupling между файлами (расширение истории с циклическими зависимостями)
6. Package Cycle - циклы в графах зависимостей, который нарушают базовые принципы дизайна для формирования иерархических структур. Такие нарушения приводят к тому, что изменения в файле одного package часто вызывают неожиданные изменения файлов в других пакетах из-за циклических зависимостей между ними.
Интересно, что я заинтересовался этим white-paper из-за статьи "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google", про которую я рассказывал пару дней назад. Суть в том, что там авторы анализировали кодовую базу Monarch, описанным в этой статье способом, и нашли много анти-паттернов в кодовой базе компонентав Leaves, на которых было слишком много ответственности и которые было сложно поддерживать. Дальше в прошлой статье они заредизайнили этот компонент для повышения availability и maintainability.
#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems
Эта статья посвящена интересной для меня теме architecture governance. В ней авторы рассказывают о своих подходах для автоматического нахождения архитектурных анти-паттернов в больших системах. Суть в том, что файлы, которые подвержены изменениям и ошибкам редко в таких системах живут поодиночке - обычно они архитектурно связаны и эти связи отображают архитектурные проблемы, которые приводят к распространению подверженности ошибкам. В этой статье авторы определяют набор антипаттернов, взяв за основу фундаментальные принципы дизайна и Baldwin and Clark’s design rule theory. Дальше они валидируют на опыте набор архитектурных анти-паттернов, которые можно автоматически находить анализируя структурные взаимоотношения в проекте, а также историю изменений. Для этого авторы проанализировали 19 крупномасштабрных системы и показали
1. Files involved in these architecture anti-patterns are more error-prone and change-prone;
2. The more anti-patterns a file is involved in, the more error-prone and change-prone it is; and
3. While all of our defined architecture anti-patterns contribute to file’s error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.
В итоге, у авторов получилось 6 антипаттернов:
1. Unstable Interface - интерфейсы, от которых многие зависят, должны оставаться стабильными
2. Modularity Violation Groups - независимые модули должны и эволюционировать независимо
3. Unhealthy Inheritance Hierarchy - этот антипаттерн про нарушение Liskov Substitution principle
4. Crossing - a file that has both high fan-in and high fan-out, and changes often together with its dependents and the files it depends on, is often at the center of maintenance activities.
5. Clique - набор файлов, которые формируют сильно-связный граф, что приводит к tight coupling между файлами (расширение истории с циклическими зависимостями)
6. Package Cycle - циклы в графах зависимостей, который нарушают базовые принципы дизайна для формирования иерархических структур. Такие нарушения приводят к тому, что изменения в файле одного package часто вызывают неожиданные изменения файлов в других пакетах из-за циклических зависимостей между ними.
Интересно, что я заинтересовался этим white-paper из-за статьи "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google", про которую я рассказывал пару дней назад. Суть в том, что там авторы анализировали кодовую базу Monarch, описанным в этой статье способом, и нашли много анти-паттернов в кодовой базе компонентав Leaves, на которых было слишком много ответственности и которые было сложно поддерживать. Дальше в прошлой статье они заредизайнили этот компонент для повышения availability и maintainability.
#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems