Чи запахи архітектури?

В Інтернеті є багато ресурсів, що посилаються на та перелічують запахи коду. Однак я ніколи не бачив інформації про архітектурні запахи . Чи визначено це десь і чи є список? Чи проводилися якісь офіційні дослідження дефектів архітектури та їх впливу на швидкість проекту, дефекти тощо?

Редагувати: Я не шукав списку відповідей, але документація (в Інтернеті чи в книзі) про архітектуру пахне.

• Багатоярусна архітектура Коли у вас є шари на шарах, на шарах на шарах ... ви бачите мою думку тут, у вашій програмі. Я називаю це над багатошаровою архітектурою
• Над абстрагуванням таким чином, що ви загубитесь у коді.
• Футуристична архітектура Це відбувається, коли рішення занадто футуристичне. Насправді ніхто не може передбачити нових вимог. Тому більшість футуристичних реалізацій - це лише витрата часу та ресурсів.
• Захоплена технологія архітектури Архітектору сподобалась нова технологія, і він поставив у виробництво. Не знаючи, чи це було доведено раніше.
• Over Kill Architecture Проста проблема була вирішена експоненціальним фактором архітектурних навичок та технологій.
• Хмарна архітектура Я називаю це хмарною архітектурою, оскільки архітектура насправді не має жодного зв'язку. Це просто кілька приємних діаграм Visio.

Повна відсутність протилежного також вірна.

Ось посилання на десять помилок архітектури програмного забезпечення .

Все налаштовується . Коли архітектор каже вам, що його система є стійкою до змін або налаштовується через велику налаштованість, це запах архітектури.

Проблема полягає в тому, що ви можете реально надати лише механізми конфігурації для того, що, на вашу думку, зараз потрібно буде налаштувати, але як тільки ваша програма буде в дикій природі, її буде недостатньо. Потім механізми конфігурації розширюються та розширюються, і з часом ви отримуєте ефект Внутрішньої платформи.

І тоді ви перебуваєте в програмному пеклі.

База даних, розроблена ОРМ! Або бекенден для бази даних, який не є реляційним, і має бути реляційним. Або база даних, де ви розробляєте використання представлень, які викликають представлення даних, які переглядають виклики, не тільки вони занадто повільні (бази даних повинні бути розроблені для продуктивності з самого початку не пізніше), але коли вам потрібно внести зміни, вони будуть жахливо відстежувати (Через абстракцію, як сказав @AmirResaei, це легко втрачається в коді, коли вам потрібно виправити щось, що знаходиться внизу всіх цих шарів.)

Кодові запахи та архітектурні запахи - одне і те ж. Код починає «пахнути» через неоптимальну архітектуру.

У навчальній книзі Мартіна Фаулера на тему « Рефакторинг» він представляє серію кодових запахів та визначає спосіб рефакторингу їх із вашої системи. « Рефакторинг на візерунки» Джошуа Керієвського ще більше підкреслює цю ідею, надаючи конкретні архітектурні зразки для фіксації різних запахів коду (і як переробляти їх покроково).

Більшість рефакторингу робиться для зменшення неоптимального коду за допомогою вдосконаленої архітектури. Можна стверджувати, що єдиним природженим «архітектурним запахом» (окрім Великого куля грязі) буде архітектура BDUF (Big Design Up Front). Де ви намагаєтеся вмістити все необхідне до того, як буде написано перший рядок коду. Швидкий програмний проект, де дизайн робиться за потребою (навіть я смію сказати, коли код трактується як дизайн ), його архітектура буде органічно зростати.

(Багато) З'єднання - в будь-якій формі - це те, що викликає запах архітектури. Чим більше вона сполучена, тим більше пахне.

Це говорило: жодна муфта взагалі часто не пахне питаннями продуктивності.

Ось один конкретний запах архітектури / дизайну, з яким я стикаюся весь час: аналіз та звітування безпосередньо з транзакційної бази даних.

Це, звичайно, добре в деяких ситуаціях (тобто легких звітах), але в багатьох випадках вимоги щодо звітності та транзакційної обробки суперечать. Однак, оскільки це дуже просто / недорого зробити, звіти запускаються безпосередньо з БД трансакцій. Це викликає всілякі головні болі по обидва боки рівняння.

Зазвичай це спостерігається в додатках Enterprise LOB, btw. Я розумію, що багато SMB просто не мають ресурсів і ноу-хау для створення складів і марок даних (забудьте про кубики або налаштування для зменшення карти), але багато великих організацій, з якими я працював, мають ті самі проблеми.

Розробляючи систему, архітектор справді повинен усвідомлювати, що вимоги до звітності - особливо звіти про аналіз - та трансакційні вимоги найкраще трактувати як окремі питання, а не просто збирати разом на рівні бази даних.

Я не впевнений, чи правильно це відповідає архітектурному рівню, але якщо я бачу купу класів / модулів менеджерів у тому, що має бути дизайном ОО, то це є гарантією того, що єдиний, хто зрозуміє архітектуру / дизайн є самим архітектором / дизайнером без багато пояснень / навчання іншими.

Є багато запахів архітектури, задокументованих громадою. Часто зустрічається безліч.

• Циклічна залежність: Цей запах виникає, коли два чи більше архітектурних компонентів залежать один від одного прямо чи опосередковано.
• Нестабільна залежність: Цей запах виникає, коли компонент залежить від інших компонентів, які менш стійкі, ніж він сам.
• Компонент Бога: Цей запах виникає тоді, коли компонент надмірно великий або за значенням LOC, або за кількістю класів.
• Концентрація функції: Цей запах виникає, коли компонент реалізує більше ніж один архітектурний предмет / особливість.
• Розсіяна функціональність: Цей запах виникає, коли за реалізацію однієї проблеми на високому рівні відповідає декілька компонентів.
• Щільна структура: Цей запах виникає, коли компоненти мають надмірну і щільну залежність без особливої ​​структури.

Нещодавно я підготував таксономію запахів . Наразі він документує 38 запахів архітектури та понад 260 загальних запахів коду.