건축 냄새가 있습니까?

웹에는 코드 냄새를 언급하고 나열하는 수많은 리소스가 있습니다. 그러나 건축 냄새에 대한 정보는 본 적이 없습니다 . 이것은 어딘가에 정의되어 있으며 사용 가능한 목록이 있습니까? 아키텍처 결함과 프로젝트 속도, 결함 등에 미치는 영향에 대한 공식적인 연구가 수행 되었습니까?

편집 : 나는 실제로 답변에서 목록을 찾지 않고 건축 냄새에 대한 문서 (웹 또는 책)를 찾고있었습니다.

• 멀티 티어 아키텍처 Layers on Layers on Layers ...를 사용하면 애플리케이션에서 내 요점이 표시됩니다. 나는 그것을 호출 계층 구조 이상
• 코드에서 길을 잃는 방식으로 추상화 하십시오.
• 미래 아키텍처 솔루션이 너무 미래 일 때 발생합니다. 실제로 아무도 새로운 요구 사항을 예측할 수 없습니다. 따라서 대부분의 미래 구현은 시간과 자원 낭비입니다.
• 기술 열광적 인 건축 건축가는 새로운 기술을 좋아하여 생산에 투입했습니다. 그것이 이전에 입증되었는지 알지 못함.
• 오버 킬 아키텍처 간단한 문제는 아키텍처 기술과 기술의 지수 요소에 의해 해결되었습니다.
• 클라우드 아키텍처 아키텍처는 실제로 연결되어 있지 않으므로 클라우드 아키텍처라고합니다. 멋진 Visio 다이어그램 일뿐입니다.

반대의 부족도 마찬가지입니다.

다음은 Top 10 소프트웨어 아키텍처 실수의 링크입니다 .

모든 것이 구성 가능 합니다. 건축가가 자신의 시스템이 광범위한 구성 가능성으로 인해 변경 방지 또는 사용자 정의가 가능하다고 말하면 이는 아키텍처 냄새입니다.

문제는 실제로 지금 당장 생각해야 할 구성에 대해서만 구성 메커니즘을 제공 할 수 있지만 응용 프로그램이 야생에 있으면 충분하지 않다는 것입니다. 그런 다음 구성 메커니즘이 확장 및 확장되어 결국 내부 플랫폼 효과를 얻게됩니다.

그리고 당신은 소프트웨어 지옥에 있습니다.

ORM이 디자인 한 데이터베이스! 또는 관계형이어야하는 비 관계형 데이터베이스 백엔드. 또는 뷰를 호출하는 뷰를 호출하는 뷰를 사용하도록 설계 한 데이터베이스는 너무 느릴뿐만 아니라 (데이터베이스는 처음부터 성능을 위해 설계되어야 함) 변경해야 할 때 추적하기가 끔찍합니다. (@AmirResaei가 말한 것처럼 추상화는 모든 레이어의 맨 아래에있는 것을 수정해야 할 때 코드에서 쉽게 길을 잃을 수 있습니다.)

코드 냄새와 건축 냄새는 동일합니다. 차선의 아키텍처로 인해 코드가 "냄새가 나기"시작합니다.

Martin Fowler의 리팩토링 (Refactoring ) 주제에 관한 주요 저서에서 일련의 코드 냄새를 제시하고이를 시스템에서 리팩토링하는 방법을 식별합니다. Joshua Kerievsky의 패턴 리팩토링은 다양한 코드 냄새를 해결하기 위해 특정 아키텍처 패턴을 제공하고 (단계적으로 리팩토링하는 방법)이 아이디어를 강조합니다.

대부분의 리팩토링은 향상된 아키텍처를 통해 차선책을 완화하기 위해 수행됩니다. 하나는 자연적으로 태어난 "건축 냄새"(빅 머드 볼 제외)는 BDUF (Big Design Up Front) 아키텍처 일 것이라고 주장 할 수 있습니다. 첫 번째 코드 줄을 작성하기 전에 필요한 모든 것을 수용하려고합니다. 디자인이 필요에 따라 수행되는 민첩한 소프트웨어 프로젝트 ( 코드가 디자인 으로 취급 되는 경우에도 )는 아키텍처가 유기적으로 성장할 것입니다.

(많은) 커플 링 은 어떤 형태로든 건축 냄새를 맡게합니다. 더 많이 결합할수록 더 많은 냄새가납니다.

즉, 커플 링이 전혀 없으면 성능 문제가 발생하지 않습니다.

여기에는 항상 발생하는 구체적인 아키텍처 / 디자인 냄새가 있습니다. 트랜잭션 데이터베이스에서 직접 분석 및보고하는 것입니다.

일부 상황 (예 : 간단한 보고서)에서는 문제가 없지만 대부분의 경우보고 및 트랜잭션 처리 요구 사항이 충돌합니다. 그러나 간단하고 비용이 많이 들지 않기 때문에 보고서는 트랜잭션 DB에서 직접 실행됩니다. 이것은 방정식의 양쪽에 모든 종류의 두통을 유발합니다.

이는 일반적으로 Enterprise LOB 앱인 btw에서 볼 수 있습니다. 많은 중소기업에웨어 하우스 및 데이터 마트를 생성 할 수있는 리소스 나 노하우가 없지만 (큐브 또는 맵 축소 설정은 잊어 버리지 만) 함께 작업 한 많은 대규모 조직에는 동일한 문제가 있습니다.

시스템을 설계 할 때 아키텍트는보고, 특히 분석 보고서와 트랜잭션 요구 사항이 데이터베이스 수준에서 함께 집중되는 것이 아니라 별도의 문제로 처리되는 것이 가장 좋습니다.

이것이 아키텍처 수준에 올바르게 맞는지 확실하지 않지만 OO 디자인으로 간주되는 관리자 클래스 / 모듈을 보면 아키텍처 / 디자인을 이해하는 사람은 다른 사람의 많은 설명 / 학습없이 건축가 / 디자이너 자신입니다.

커뮤니티가 문서화 한 많은 건축 냄새가 있습니다. 일반적으로 발생하는 집합은 다음과 같습니다.

• 순환 종속성 : 이 냄새는 두 개 이상의 아키텍처 구성 요소가 서로 직접 또는 간접적으로 의존 할 때 발생합니다.
• 불안정한 종속성 : 이 냄새는 구성 요소가 자신보다 불안정한 다른 구성 요소에 의존 할 때 발생합니다.
• 신 구성 요소 : 이 냄새는 구성 요소가 LOC 또는 클래스 수 측면에서 지나치게 큰 경우에 발생합니다.
• 기능 집중 : 이 냄새는 구성 요소가 둘 이상의 건축 적 문제 / 기능을 인식 할 때 발생합니다.
• 흩어진 기능 : 이 냄새는 여러 구성 요소가 동일한 높은 수준의 관심사를 실현할 때 발생합니다.
• 고밀도 구조 : 이 냄새는 구성 요소가 특정 구조없이 지나치게 밀도가 높을 때 발생합니다.

나는 최근 에 냄새 의 분류를 준비했다 . 현재 38 건의 건축 냄새와 총 260 건 이상의 코드 냄새가 있습니다.