Czy są zapachy architektury?

W sieci jest mnóstwo zasobów odnoszących się do zapachów kodu i wyświetlających je na liście. Jednak nigdy nie widziałem informacji o zapachach architektonicznych . Czy jest to gdzieś zdefiniowane i czy jest dostępna lista? Czy przeprowadzono formalne badania defektów architektury i ich wpływu na szybkość projektu, defekty i tym podobne?

Edycja: Tak naprawdę nie szukałem listy w odpowiedziach, ale dokumentacja (w Internecie lub w książce) o architekturze pachnie.

• Architektura wielowarstwowa Kiedy masz Warstwy na Warstwach na Warstwach na Warstwach ... mój punkt tutaj widzisz w swojej aplikacji. Nazywam to architekturą warstwową
• Nadmiar abstrakcji w taki sposób, że gubisz się w kodzie.
• Futurystyczna architektura Dzieje się tak, gdy rozwiązanie jest zbyt futurystyczne. W rzeczywistości nikt nie jest w stanie przewidzieć nowych wymagań. Dlatego większość futurystycznych wdrożeń to tylko strata czasu i zasobów.
• Technologia Entuzjastyczna architektura Architektowi spodobała się nowa technologia i wprowadził ją do produkcji. Nie wiedząc, czy zostało to wcześniej udowodnione.
• Architektura Over Kill Prosty problem został rozwiązany przez wykładniczy czynnik umiejętności i technologii architektury.
• Architektura chmur Nazywam to architekturą chmurową, ponieważ architektura nie ma żadnego związku z rzeczywistością. To tylko kilka ładnych diagramów Visio.

Zupełny brak jest również prawdą.

Oto link do dziesięciu najczęstszych błędów architektury oprogramowania .

Wszystko jest konfigurowalne . Kiedy architekt mówi ci, że jego system jest odporny na zmiany lub wysoce konfigurowalny z powodu szerokiej konfiguracji, to zapach architektury.

Problem polega na tym, że naprawdę możesz dostarczyć tylko mechanizmy konfiguracji dla tego, co według ciebie będzie wymagało skonfigurowania, ale gdy aplikacja będzie już na wolności, nie będzie wystarczająca. Następnie mechanizmy konfiguracji rozszerzają się i rozszerzają, a ostatecznie uzyskuje się efekt platformy wewnętrznej.

A potem jesteś w piekle oprogramowania.

Baza danych zaprojektowana przez ORM! Lub backend bazy danych, który jest nierelacyjny i powinien być relacyjny. Lub baza danych, w której zaprojektowano korzystanie z widoków wywołujących widoki, które wywołują widoki, nie tylko są one zbyt wolne (bazy danych muszą być projektowane pod kątem wydajności od początku nie później), ale gdy trzeba wprowadzić zmiany, śledzenie ich jest okropne (Nadmiar abstrakcji, jak powiedział @AmirResaei, ułatwia zagubienie się w kodzie, gdy trzeba naprawić coś, co znajduje się na dole wszystkich tych warstw).

Zapachy kodowe i zapachy architektoniczne są jednym i tym samym. Kod zaczyna „wąchać” z powodu nieoptymalnej architektury.

W przełomowej książce Martina Fowlera na ten temat, Refaktoryzacja , przedstawia serię zapachowych kodów i identyfikuje sposób na ich refaktoryzację z twojego systemu. Refaktoryzacja wzorców przez Joshua Kerievsky'ego jeszcze bardziej podkreśla ten pomysł, podając konkretne wzory architektoniczne, aby naprawić różne zapachy kodu (i jak refaktoryzować je krok po kroku).

Większość refaktoryzacji ma na celu złagodzenie suboptymalnego kodu poprzez ulepszoną architekturę. Można argumentować, że jedynym naturalnie urodzonym „Architectural Smell” (innym niż Big Ball of Mud) byłaby architektura BDUF (Big Design Up Front). Gdzie próbujesz pomieścić wszystko, czego potrzebujesz przed napisaniem pierwszego wiersza kodu. Zwinny projekt oprogramowania, w którym projektowanie jest wykonywane w razie potrzeby (nawet ja twierdzę, że kod jest traktowany jako projektowanie ), będzie miał organicznie rozwijaną architekturę.

(Dużo) Sprzęganie - w jakiejkolwiek formie - powoduje zapach architektury. Im bardziej jest sprzężony, tym bardziej pachnie.

To powiedziawszy: brak sprzężenia często wącha problemy z wydajnością.

Oto jeden konkretny zapach architektury / projektowania, z którym ciągle się spotykam: analiza i raportowanie bezpośrednio z transakcyjnej bazy danych.

Z pewnością jest to OK w niektórych sytuacjach (np. Lekkie raporty), ale w wielu przypadkach wymagania dotyczące raportowania i przetwarzania transakcji są w konflikcie. Ponieważ jednak jest to prosta / niedroga rzecz, raporty są uruchamiane bezpośrednio z transakcyjnej bazy danych. Powoduje to różnego rodzaju bóle głowy po obu stronach równania.

Zazwyczaj jest to widoczne w aplikacjach Enterprise LOB, btw. Rozumiem, że wiele małych i średnich firm po prostu nie ma zasobów ani wiedzy, aby tworzyć magazyny i karty danych (zapomnij o kostkach lub ustawieniach zmniejszania mapy), ale wiele większych organizacji, z którymi pracowałem, ma te same problemy.

Projektując system, architekt powinien mieć świadomość, że raportowanie - zwłaszcza raporty analityczne - i wymagania transakcyjne najlepiej traktować jako osobne problemy, a nie tylko skupiać je na poziomie bazy danych.

Nie jestem pewien, czy to słusznie pasuje na poziomie architektury, ale jeśli widzę kilka klas menedżerów / modułów w projekcie, który powinien być projektem OO, to jest to gwarancja, że ​​jedyna osoba, która zrozumie architekturę / projekt jest architektem / projektantem bez wielu wyjaśnień / uczenia się przez innych.

Społeczność dokumentuje wiele zapachów architektury. Najczęściej występujący zestaw jest następujący.

• Cykliczna zależność: ten zapach powstaje, gdy dwa lub więcej elementów architektury zależy od siebie bezpośrednio lub pośrednio.
• Niestabilna zależność: ten zapach powstaje, gdy składnik zależy od innych składników, które są mniej stabilne niż on sam.
• God Component: Ten zapach pojawia się, gdy składnik jest nadmiernie duży, zarówno pod względem LOC, jak i liczby klas.
• Stężenie cech: ten zapach pojawia się, gdy element zdaje sobie sprawę z więcej niż jednego problemu / cechy architektonicznej.
• Rozproszona funkcjonalność: ten zapach powstaje, gdy wiele elementów jest odpowiedzialnych za realizację tego samego problemu na wysokim poziomie.
• Gęsta struktura: ten zapach powstaje, gdy składniki mają nadmierne i gęste zależności bez żadnej konkretnej struktury.

Niedawno przygotowałem taksonomię zapachów . Obecnie dokumentuje 38 zapachów architektury i ponad 260 zapachów kodu.