개발하기 전 준비

유비쿼터스 랭귀지(Ubiquitous Language)

비즈니스 도메인에 각 직군 별로 동일한 용어와 개념을 사용하여 의사소통할 수 있도록 공통 용어를 정의한다.
하나의 단어는 여러가지 의미로 해석될 수 있기 때문에 구체화 시킬수록 좋다.

도메인을 분석하고 도메인의 핵심 개념과 용어를 식별한다.
도메인 분석을 토대로 모두 이해할 수 있는 공통된 용어를 정의한다.
개발자 간 의사소통을 원활히 할 수 있도록 코드내에 반영한다.

프론트엔드 개발자들끼리 협업 이점

공통된 용어를 사용하여 변수명, 타입명 등을 일관성 있게 작성함으로써, 코드의 가독성과 일관성을 유지할 수 있다.

백엔드 개발자와 협업 이점

서로의 요구사항을 정확하게 이해하고 소통이 원활해진다.
미리 정해놓은 용어들로 API 응답 값이 구성되기 때문에 프론트 측 코드의 일관성과 코드 수정사항이 적어 개발 시간이 단축된다.

Example

Product: 상품
    Summary: 상품에 대한 요약 정보
    Detail: 상품에 대한 상세 정보
    Image: 상품 이미지
    Option: 상품에 대한 상세 옵션 종류 (색상, 크기 등)
        OptionItem: 옵션에 대한 상세 옵션 값 (옵션이 색상이라면 이건 Blue, Red 같은 걸 의미함)
Category: 상품에 대한 분류
Cart: 장바구니
    LineItem: 장바구니에 담긴 것 (상품, 옵션, 수량 등을 동시에 다룸)
        여기서도 Option과 OptionItem을 사용한다.
        용어는 동일하지만 Product와 다른 구성을 갖기 때문에, 여기서는 Product와 Order라는 접두어를 활용한다.
        시스템을 분리할 수 있다면, 근본적으로 나누는 걸 추천(상품 정보 확인 / 장바구니 / 주문).
Order: 주문
    여기서도 동일한 LineItem 활용.
User: 사용자

비즈니스 요구사항 분석하기

비즈니스 목표 이해하기

제품을 만들 때 비즈니스 목표를 온전히 이해해야 디테일을 신경쓸 수 있다.
즉, 어떤 가치가 만들어지고 있는지 모르는 상태로 단순히 기능만 구현한다면 사용자를 위한 제품을 만들기 어렵다.

제품을 만들 때 어떤 것이 가장 중요한지는 목표에서 결정된다.
비즈니스를 알고 있어야 어떤 제품을 만들지 어떤 부분에 더욱 신경을 써야할지 결정할 수 있다.

요구사항 도출해내기 (기능 정의하기)

비즈니스 요구사항은 우리가 어떤 목표를 추구하는지에 따라서 결정됨

비즈니스 요구사항들을 바탕으로 앞으로 만들어 낼 기능들을 나열할 수 있다.

쇼핑몰
  구매자
    상품 목록 확인
    상품 상세 정보 확인
    상품 문의하기
    장바구니에 상품 담기
    주문하기 → 배송지 입력, 결제
    주문 목록 확인
    주문 상세 확인
    로그인
    회원 가입
 관리자
   회원 관리
   상품 관리
   주문 관리
   문의 관리
   공지사항 관리
   배너 관리
   통계 관리

우선순위 정리하기

비즈니스 요구사항이 도출되면 우선순위(중요도)를 결정짓게 된다.

요구사항에 따른 우선순위를 알고 있어야 어떤 기능을 고도화 시키고 집중할지를 알 수 있다.
우선순위를 정한 후 어떤 기능을 먼저 구현해야 할지 결정할 때는 대체재가 어떤 것들이 있는지 인지하는 것이 중요
대체 불가능한 것들은 직접 개발해야하기 때문에 우선순위를 높히고, 우선순위가 높더라도 대체 가능한것들은 후순위로 미룬다.

1. 상품 목록 확인
2. 상품 상세 정보 확인
3. 장바구니에 상품 담기
4. 주문하기 → 배송지 입력, 결제
5. 주문 목록 확인
6. 주문 상세 확인
7. 로그인
8. 회원 가입

비즈니스 레이어와 밀접하게 일을 하고 우선순위를 결정할 수 있는 능력은 개발자의 중요 역량 중 하나이다.

유저 플로우 그리기

사용자가 제품을 이용하기 위해 거쳐야 하는 단계를 순서대로 연결한 것
각 단계에서 필요한 액션과 정보를 표시하여 사용자 관점에서의 이해도를 높히고 사용자 경험을 개선할 수 있다.

유저 플로우를 그리면 제품의 기능을 구체화하여 개발할 수 있다.
유저 플로우는 사용자의 제품 진입점(Entry Point)에 따라 달라질 수 있다.
사용자는 다양한 경로를 통해 들어올 수 있기 때문에 진입점이 항상 메인 페이지가 아니라는 것을 인지해야 한다.
모든 플로우를 고려하는 것은 불가능하므로 놓치고 있는 플로우가 존재할 수 있다.
제품의 완성도를 높이기 위해 필요한 기능들을 찾아내고 적절하게 제시할 수 있는 것이 기술을 잘 이해하고 있는 개발자의 의무이다.

사용자(구매자) → 상품 목록 → 상품 상세 → (로그인 & 회원가입) → 주문 → 결제 → 주문 확인

각 플로우의 실패 케이스들도 모두 고려해서 정리해야 한다.

데이터 플로우 그리기

어느 시점에 어떤 데이터를 사용할지 데이터 흐름을 정의하는 것

전체적인 데이터 구조의 흐름을 파악하여 API 스펙을 미리 설계하고 Mock API를 작성
필요로 하는 데이터 구조와 흐름을 먼저 정의하여 백엔드 개발자에게 요청하면 편할것 같다.

기술 요구사항 정리하기

기술적인 이해도를 바탕으로 제품을 어떻게 구현할지 기술들을 나열하는 것. 즉, 디테일을 잡아가는 과정

서비스 아키텍처는 어떤식으로 구성할 것인지
배포 주기는 어떤식으로 정할 것인지
프로덕션 환경을 어떻게 구성할 것인지
SEO에 민감한지
결제 모듈은 어떤 것을 사용해야 하는지
소셜 로그인을 지원해야 하는지
유저 트래킹이 가능해야 하는지
상세 페이지가 얼마나 자주 변경될 것인지

기술 요구사항을 정리할 때, 명확하지 않은 부분들은 다른 직군과 소통하면서 모두 물어봐야 한다.

기술 도입을 위해 팀원에게 설득시키는 일은 개인의 문제가 아닌 우리가 가진 문제를 바탕으로 이 기술을 왜(Why) 사용해야 하는지에 대해 설득할 수 있어야 한다.

항상 Why를 바탕으로 기술을 사용해야 한다.

개발 환경 세팅

추가로 설치한 도구들

그 외 고려사항

Unit Test → 모든 단위 테스트는 TDD를 따른다.
- 비즈니스 로직은 테스트 커버리지 100%를 목표로 삼는다.
- 컴포넌트 단위로 각 컴포넌트가 맡은 역할을 잘 수행하는지 동작을 검증한다.
E2E Test → 작성한 유저 시나리오를 바탕으로 테스트를 작성하고 모두 통과하는 것을 목표로 삼는다.
Type 정의 → 특별한 경우가 아니라면, 미리 정한 용어집과 API 스펙에 맞추어 설정한다.
MSW 세팅 → REST API 스펙에 맞춰 Mock API 핸들러를 준비한다.

유저 시나리오는 사용자가 제품 서비스를 어떻게 이용할지 정의하는 것

제품 서비스를 이용할 타겟 유저를 먼저 정의하고 서비스를 어떤 상황에서 어떤 목적으로 사용되는지를 묘사한다.
제품 스펙을 개발자 관점에서 미리 정의하여, 테스트 케이스를 작성하는 데 도움이 될 것 같다.

PreviousWeek 9 Next상품 목록 페이지

Last updated 5 months ago