아키텍처를 현재 조직구조에 맞추도록 한다.
DB가 추가된 이유가 DB팀이 일거리를 찾기 위해서 라는 식은 곤란하다.
25개 이상의 최상위 아키텍처 컴포넌트가 존재하는 건 너무 복잡하다.
한 개의 요구사항이 설계의 전체 방향을 이끌어나간다.
이 요구사항이 없어지면 그 아키텍처는 다른 이슈를 감당하기엔 지나치게 다른 길을 걸어왔다.
하나의 요구사항에 집중하면, 다른 이슈들을 건성으로 다루는 경향이 있기 때문이다.
아키텍처가 운영체제의 특정 버전에 의존적이다.
생각보다 이런 경우가 잦다.
표준 컴포넌트가 사용될 수도 있는 곳에 독점적인 컴포넌트를 사용한다.
하드웨어 단위 구분과 동일하게 컴포넌트를 나눈다.
시스템이 진화하여 하드웨어가 변경되면, 넌 x 된다. 소프트웨어 조직을 하드웨어에 끼워맞추지 말라.
신뢰성 확보라는 명분 하에 필요하지 않은 중복이 있다.
DB 이중화, 2개의 시작 루틴 따위는 시스템을 필요 이상으로 복잡하게 한다.
설계가 예외상황 중심적이다.
핵심 공통성이 아닌 기능의 확장성만을 강조한다.
개발조직에서 시스템 아키텍트를 식별할 수 없다.
아키텍트 또는 프로젝트 관리자가 아키텍처의 이해 관계자를 식별하는데 어려움이 있다.
관계도가 명확하지 않다는 것은 고려 없이 만들었을 가능성이 높다.
개발자가 두 컴포넌트의 상호작용을 코딩하는데 있어서 지나치게 많은 선택권을 갖는다.
아키텍처가 과다하게 선택권을 제공하거나 해당 이슈를 간과하도록 설계됐다면, 아직 아키텍처를 정의하는 중이다.
아키텍트에게 아키텍처 문서 작성을 요청하면, 클래스 다이어그램만 만들고 다른 것은 만들지 않는다(못 한다).
아키텍트에게 아키텍처 문서를 요청하면, 누구도 보지 못한 도구에서 자동으로 생성된 다량의 문서더미를 제시한다.
자동으로 생성이라도 되면 다행이다. 너무 복잡해서 생성하다가 프로그램이 터지는 프로젝트를 나는 알고 있다.
전달된 문서가 예전 내용이라면 당연히 최신 내용으로 관리되지 않고 있다.
설계자 또는 개발자에게 아키텍처를 설명하도록 요청하면, 못 하거나 상이한 아키텍처에 대해서 설명하고 있다.
- 소프트웨어 아키텍처 평가 286p
굵은 글씨는 내 경험 상 깊이 느꼈던 부분들이다.
