좋은 설계를 하는 방법

설계 능력을 기르는 방법

- 설계 문서 작성 해보기

: 이미 개발한 프로젝트나 포트폴리오용으로 개발 예정인 프로젝트의 설계 문서 작성해보기

 

- 플로우 차트 그리기

: 실제 프로그램을 논리적으로 그려보기

 

- Poc (Proof of Concept) 많이 하기

: 실현 가능성이 있는지, 효과와 효용, 기술적 관점에서 검증

 

- 선배 또는 동료 끌어들이기

: 팀을 구성해서 서로 피드백 할 수 있는 환경을 만들기

 

 

 

 

좋은 소프트웨어 설계 문서를 만드는 방법

- 설계 문서에 있어야 하는 내용

: 디자인 문서의 제목

: 작성자 (작업을 담당한 사람과 동일해야함)

: 문서 검토자 (프로세스 섹션에서 자세하게 설명 됨)

: 최신 업데이트 날짜

 

 

 

 

 

설계 문서 계요

- 문맥

: 직면한 문제가 무엇인이에 대한 설명

: 이 작업이 필요한 이유

: 이 작업 내용을 평강하기 위해 필요한 사항

: 이 작업이 만족시키는 기술 전략

: 팀의 목표에 어떻게 부합하는지

 

- 목표

: 사용자 (혹은 엔지니어) 관점에서의 결과물의 가치

: 성공 여부를 측정하는 방법에 대한 설명

 

- 목표가 아닌 것

: 이 작업으로 수정하지 않을 문제를 설명

 

- 마일스톤

: PM과 관리자가 대략적인 완료일을 알 수 있도록 체크포인트를 명시하여 작성

: 작업의 크기가 1개월 이상인 경우 주요 사용자 별 마일스톤으로 나누어 작성하는 것이 좋음

시작일자: 2023. 2. 6
마일스톤1 - 알약 검색 기능 개발 완료: 2023. 2. 14
마일스톤2 - 기존 시스템 중단: 2023. 2. 15
완료일자 - 신규 시스템에 기능 추가: 2023. 2. 16

 

- 기존 솔루션

: 현재 구현된 사항을 설명

: 사용자가 시스템과 인터렉션 하는 방법과 인터렉션 시에 데이터가 변경되는 흐름을 설명

: 충분한 예제 필요

 

- 제안하려는 솔루션

: 어떻게 문제를 해결할 수 있는지 모두 설명이 되어야함

: 사용자 스토리 프레임으로 설명하는 것이 중요

: 많은 하위 섹션들과 다이어그램을 포함하여 이해도를 높여야함

: 큰 그림을 가장 먼저 제시

 

- 대체 솔루션

: 위의 솔루션을 대체할 대안이 있는 경우 간단하게 나열

: 오픈소스 이용 혹은 구매할 수 있는 솔루션

 

- 테스트 가능성 / 모니터링 및 경고

: 운영 중에 문제가 발생했을 때에 대한 경고

 

- 다른 팀에 영향을 주는 부분

: 보안 취약점

: 추가 비용

: 부작용 등

 

- 열린 질문

: 확실하지 않은 미해결 사항 및 독자가 고민해줬으면 하는 부분

: 논의가 필요한 사항

 

- 상세 타임 라인

: 작업하는 엔지니어, 기술 책임자, 기술 관리자에게 알리는 내용

 

 

 

 

설계문서의 작성 방법

- 가능한 간단하게

: 솔루션을 팀원들에게 이해시키고 피드백을 받기 위해 작성됨을 잊지 말아야함

: 간단한 단어와 짧은 문장, 불릿 목록 및 번호 목록

: 구체적인 예제 등으로 표현

 

- 많은 차트와 다이어그램

: 다이어 그램 아래에 편집 가능한 다이어그램 링크 첨부도 같이 해줄 것

 

- 숫자 포함

: DB 행수, 사용자 오류수, 지연 시간 등의 실제 숫자와 시간 복잡도 등을 넣어 표현

 

- 웃기려는 노력

: 독자가 읽을 때 집중력을 높일 수 있도록 스타일링

 

- 리뷰어 입장에서 검토

: 문서 리뷰 요청 전에 리뷰어로써 검토 해보기

 

- 휴가 테스트

: 이 문서를 작성하고 휴가를 떠나더라도 팀원이 의도한대로 구현할 수 있는지 확인

 

 

 

 

 

문서 작성 프로세스

: 좋은 피드백을 받기 위한 작성 프로세스 및 피드백 프로세스

 

- 모든 참여자는 설계 프로세스에 모두 참여해야함

 

- 직접 솔루션의 프로토타입을 만들어 볼 것

: 아이디어의 유효성을 검사하기 위함

 

- 리뷰어 요청

: 사전에 숙련된 엔지니어 및 기술 책임자에게 리뷰어 요청

: 화이트 보드가 있는 회의실로 이동하여 문제와 솔루션을 설명

 

- 공유

: 작성자와 리뷰어가 승인한 후 팀 구성원 전체에 문서 공유

: 검토 일정을 1주로 제한 (검토 지연 방지)

 

- 토론 섹션

: 피드백 주간에 있었던 논쟁을 정리

 

 

 

 

 

 

Reference

OKKY - [커리어스킬 03] 서비스 기업에 가려면 필요한 능력

좋은 소프트웨어 설계 문서를 작성하는 방법.