개발자에서 아키텍트로 - 3. 설계 전략 고안하기2

3.3 위험요소 가이드로 삼기

3.3.3 위험이 줄면 수동적인 설계로 전환한다.

아키텍트는 아키텍처가 시스템에서 위험 요소가 아닐 때까지 기술적 위험을 줄여야 한다고 말했습니다. 아키텍처에서 발생할 위험을 충분히 줄이면 그 다음부터는 다른곳에 시간을 쏟는 편이 좋습니다.

아키텍처가 더는 시스템에서 가장 큰 위험 요소가 아니라면, 그래프에 보이는 것처럼 능동적인 설계에서 수동적인 설계로 전환하세요. 능동적인 설계는 위험을 줄이기 위한 설계 프로세스 입니다. 수동적인 설계는 시스템에 구현된 아키텍처를 관찰하고 필요에 따라 수정 조치를 취합니다.

아키텍처가 다시 위험을 품게 되면 그땐 다시 능동적인 설계로 전환하고 새로운 현실을 반영해 아키텍처를 조정해야 합니다.

 

3.4 설계 계획 세우기

설계 계획은 팀이 아키텍처를 설계할 때 시간을 어떻게 활용할지에 대한 일반적인 전략을 말합니다.

설계의 판단 근거
마감시간을 정하고 선행 설계를 할지? 아니면 오래 걸리더라도 위험을 줄이는 설계를 할지? 코딩하기 전에 최소한의 선행 디자인 작업을 할지? 아키텍처를 더 구성해 볼지? 작은 부분부터 구현할지? 정답은 없습니다. 판단 근거는 팀, 이해관계자, 프로젝트 맥락에 따라 달라집니다.

디자인 산출물
설계를 시작하기전 아키텍처의 문서화 계획을 모두에게 알립니다. 화이트 보드 사진만으로 괜찮을지? 더 전통적인 문서화가 필요할지? 회사 or 팀에서 전통적인 템플릿을 사용하는지? 설계 결과물은 어디에 저장할지에 대해서도 확인이 필요 합니다.

일정
프로젝트 일정 내에서 주요 설계 마일스톤을 정합니다. 대규모 프로젝트에는 요구사항을 수집하고 아키텍처를 탐색하기 위한 별도의 교정 과정이 있습니다. 소규모 프로젝트나 지속적으로 유지보수하는 소프트웨어 시스템은 정기적으로 집중 설계 기간을 가질 수 있습니다. 최소한으로 아키텍처에 영향을 끼치는 주요 요구사항을 검토, 초한 설계를 검토 평가(테스트)를 수행하는 마일스톤이 포함되어야 합니다. 또한 이해관계자들과의 워크샵을 여러 번 해야 합니다. 구현이 들어갈즘 초기 구현이 어떤 범위로 개발할지 논의하는 내용으로 워크숍을 할 수 있습니다.

위험요소
위험이 이끄는 설계방식을 사용하고 있으므로 주요 위험 요소를 설계 계획에 다룹니다. 소프트웨어 시스템의 수명 전체에서 특히 선행 아키텍처 설계 중에 위험 목록을 다시 검토 합니다.

 

개괄적인 아키텍처 디자인

어림짐작한 해결법을 먼저 구상 합니다. 문제를 정의하기 위한 해결법이어야 합니다. 개괄적인 아키텍처란 초기에 구상한 대략적인 설계를 논의할 수 있을 정도의 가벼운 스케치 이기도 합니다.

 

소프트웨어 설계는 시스템에 따라 몇시간 or 몇 달이 될 수도 있습니다.