항해 플러스 백엔드 (3주차 WIL)

3주차 WIL

 

3주차 KPT를 정리합니다.

 

 

 

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

 

요구사항

• E-Commerce 시스템 분석 및 설계
• 시퀀스 다이어그램, ERD, 프로젝트 마일스톤 등 기초 산출물 작성

 

이번주차부터는 이어지는 과제로 분석 - 설계 - 구현의 순서대로 진행이 되는 것 같습니다.

 

첫 주차는 앞으로 만들 E-commerce 시스템에 대한 설계 부분으로

어떤 기술을 채택하는지, 패키지 구조는 어떻게 가져가는지 등 전반적인 구조를 잡습니다.

 

시퀀스 다이어그램이나 API 명세 작성을 실무에서는 많이 안해봐서 어려움을 좀 겪었습니다.

 

2. 시도

 

일반 워드, 엑셀, PPT로만 산출물을 작성해봤지 readme.md 등에 작성하고

공유하기 위한 "실용성있는" 산출물은 작성해보지 못했습니다.

 

다양한 툴이 있다는걸 커뮤니티를 통해 알았으며 mermaid를 사용해 산출물을 작성했습니다.

 

또한 패키지 구조는 이전 주차에서 진행한 Clean + Layerd 아키텍처를 선정했습니다.

 

 

3. 해결

 

다행히 예제를 통해 시퀀스 다이어그램이나 ERD의 기본적인 설계 및 작성 방법에 대해

공유가 되어 어렵지 않게 작성했습니다.

 

 

4. 알게된 것

 

"기본"만 생각하니 멘토링에서 상당히 많은 문제점을 지적받았습니다.

 

1. API를 설계할 때 path는 리소스에 대한 질의 대상으로 봐야한다.  - 유저 잔액 조회시 /balance/{userId}면 balance가 질의 대상인데 뜬금없이 userId가 들어가있음.    따라서 hedaer에 userId를 넣던가, /users/{userId}/balance와 같이 user의 잔액으로 설계가 바람직함  - API 설계는 복수형으로 사용하는게 좋음. 예를 들면 /lectures/{lectureId}이면 여러개의 lecture 중에     lectureId에 해당하는 ID를 찾는 의미로 쓸 수 있음

 

2. 예외 케이스 고려  - userId가 없는 경우가 고려되지 않음  - client에게 응답할 에러 코드가 명확하지 않음

 

3. 기타  - 상품 주문의 경우 재고를 먼저 차감하고 결제를 진행함.    그 이유는 재고에 대한 롤백 비용보다 결제의 롤백 비용이 더욱 크기 때문.  - 분기가 많은 복잡한 시나리오의 경우 플로우 차트를 적극적으로 활용해보는 것도 좋음.  - 결제의 경우 네트워크 등과 같은 장애로 인한 멱등성에 대한 고려가 필요함.

 

 

Keep

- 포기하지 않았습니다.

- "여가"가 먼저가 아닌 "학습"을 먼저하는 습관을 들였습니다.

- 멘토링 예약 성공!

Problem

- 실제 구현부가 들어가지 않아 이후 일정은 고려하지 않고 너무 러프한 설계를 진행했습니다.

- 조금만 더 깊게 생각했다면 피드백에 없었을 내용들이 많아 조금 아쉽습니다.

- 잦은 회식으로 인해 학습에 쓸 시간을 많이 빼앗겼습니다.

Try

- 기능의 동작이 가장 기본적이지만 다양한 예외에 대한 고민을 더 해야합니다.

- 업무와 학습에 쓸 시간을 명확히 계산해야 합니다.

- 문서화 능력을 기릅니다.

 

 

3주차 주요 학습 Keyword

Clean Architecture

Mermaid

RESTful