달거북씨의 코딩생활

💡 아래 명세를 잘 읽어보고, 서버를 구현합니다.

Description

• 특강 신청 서비스를 구현해 봅니다.
• 항해 플러스 토요일 특강을 신청할 수 있는 서비스를 개발합니다.
• 특강 신청 및 신청자 목록 관리를 RDBMS를 이용해 관리할 방법을 고민합니다.

Requirements

• 아래 2가지 API 를 구현합니다.
  • 특강 신청 API
  • 특강 신청 여부 조회 API
• 각 기능 및 제약 사항에 대해 단위 테스트를 반드시 하나 이상 작성하도록 합니다.
• 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 작성하도록 합니다.
• 동시성 이슈를 고려하여 구현합니다.

API Specs

1️⃣ (핵심) 특강 신청 API POST /lectures/apply

• 특정 userId 로 선착순으로 제공되는 특강을 신청하는 API 를 작성합니다.
• 동일한 신청자는 한 번의 수강 신청만 성공할 수 있습니다.
• 각 강의는 선착순 30명만 신청 가능합니다.
• 이미 신청자가 30명이 초과되면 이후 신청자는 요청을 실패합니다.
• 어떤 유저가 특강을 신청했는지 히스토리를 저장해야한다.

2️⃣ (기본) 특강 목록 API GET /lectures

• 단 한번의 특강을 위한 것이 아닌 날짜별로 특강이 존재할 수 있는 범용적인 서비스로 변화시켜 봅니다.
• 이를 수용하기 위해, 특강 엔티티의 경우 기본 과제 SPEC 을 만족하는 설계에서 변경되어야 할 수 있습니다.
  • 수강신청 API 요청 및 응답 또한 이를 잘 수용할 수 있는 구조로 변경되어야 할 것입니다.
• 특강의 정원은 30명으로 고정이며, 사용자는 각 특강에 신청하기전 목록을 조회해볼 수 있어야 합니다.
  • 추가로 정원이 특강마다 다르다면 어떻게 처리할것인가..? 고민해 보셔라~

3️⃣ (기본) 특강 신청 완료 여부 조회 API GET /lectures/application/{userId}

• 특정 userId 로 특강 신청 완료 여부를 조회하는 API 를 작성합니다.
• 특강 신청에 성공한 사용자는 성공했음을, 특강 등록자 명단에 없는 사용자는 실패했음을 반환합니다. (true, false)

 💡 KEY POINT

• 정확하게 30명의 사용자에게만 특강을 제공할 방법을 고민해 봅니다.
• 같은 사용자에게 여러 번의 특강 슬롯이 제공되지 않도록 제한할 방법을 고민해 봅니다.

천방지축 어리둥절 빙글빙글 돌아가는 1주였다.

지난주보다는 시간분배도 잘했다고 생각했는데,

ERD 설계(랄 것도 사실 없지만...)부터 구현 및 테스트까지,

시간이 모자랐다.

하현우 코치님이 입이 닳도록 프로젝트 구조에 대해 설명하시는 거 들어서 구조 잘 짤 수 있다고 생각했는데,

컨트롤러 테스트 해서 컨트롤러 만드는 것까진 신나게 했는데,

Entity와 DTO를 나누고, 레파지토리를 추상화하는 과정에서 멘붕이 왔다.

DTO를 Entity로 바꾸어서 전달하고, 디비에서 받은 데이터를 다시 Entity에서 DTO로 바꿔서 던져주고 해야 한다고 머리는 이해하는데...

어느 위치에서 어떤 시점에 해야하는 거지...?

멘붕에 빠져서 시간을 엄청 잡아 먹었다.

레파지토리 추상화도 그냥 repository랑 impl로 나누면 되겠지 하고 있었는데,

JPA 레파지토리 추상화를 검색해 보니 갑자기 레파지토리커스텀이 등장하는 게 아닌가.

그래그래, 쿼리 커스텀해서 쓰니까 레파지토리커스텀을 써야하는구나.

근데 이건 또 어느 위치에서 어디에 참조해야하는 거지?

진짜 이 부분에서 모든 시간을 다 써버렸다.

그래서 선착순 30명 조건을 충족하기 위해 비관적 락을 적용하고 동시성 테스트 하는 코드는 날림으로 작성했다.

사실 동시성 테스트는 실패해서 다시 손봐야한다ㅠ

그래도 어찌어찌 2주 간의 챕터 1의 끝났다.

코드 실력은 상승했다고 보기 어렵겠지만 관념적인 시야는 조금 성장한 것 같다.

레이어드 아키텍처 기반의 클린 아키텍처는 어떻게 해야 하는가에 대해 조금은 익숙해졌고,

코드를 짤 때 이 기술을 왜 여기서 써야 하는지에 대해 생각하려 연습하고 있다.

챕터 2를 하는 3주 간의 목표는 클린 아키텍처에 익숙해지는 것 + 객체지향적인 코드를 짜는 것이다.

(절차지향적인 코드라고 피드백 받아서 슬프다)

그리고 아고라나 DM을 적어도 한 번은 사용해보는 것이 목표다.

내 지식이 많이 부족하다고 느껴 오히려 아고라나 DM으로 코치님께 물어보기가 어렵다.

Keep : 모르는 부분은 팀원들과 공유해서 해결하는 부분
Problem : 내가 모르는 것에 대해 말로 정리하기가 어렵다
Try : 아고라랑 DM도 활용해보자!

그걸 왜 써야하는지 자기 자신만의 이유 만들기

❓ [과제] point 패키지의 TODO 와 테스트코드를 작성해주세요.

요구 사항

• PATCH /point/{id}/charge : 포인트를 충전한다.
• PATCH /point/{id}/use : 포인트를 사용한다.
• GET /point/{id} : 포인트를 조회한다.
• GET /point/{id}/histories : 포인트 내역을 조회한다.
• 잔고가 부족할 경우, 포인트 사용은 실패하여야 합니다.
• 동시에 여러 건의 포인트 충전, 이용 요청이 들어올 경우 순차적으로 처리되어야 합니다. (동시성)

과제 제출

• 과제 제출은 pr 형태로 한다. (코치 분들이 코드리뷰 예정)
• PR을 만드실때 어떤 부분들이 되고 봐줬으면 좋겠는지 작성해주세요.
• PR내용에 비지니스 로직이외에 프로젝트 init이라든가.. 포함 X (핵심 로직부분만 pr로 만들어주세요)

문제가 아주 많았다.

과제가 아니라 나한테 문제가 많았다.

우선 TDD를 하나도 몰랐다.

테스트 코드도 작성해본 적이 거의 없었다.

마감 이틀 전에 들어와서 다른 분들과 사전스터디를 할 시간도 없었다.

(만약 이 글을 보는 분들이 있다면, 충분한 공부 후 시작을 위해 마감 직전에는 들어가지 않는 걸 추천한다)

어쩔 수 없지. 

발제 시간에 잠깐 들은 거로는 부족해서 우선 인프런의 무료 TDD 강의를 들었다. 코드 짜는 흐름이라도 파악해보려구.

하지만 단축키 써서 무슨 축지법 쓰듯 하는 강의에 멘붕이 왔다.

결국 이너 클래스로 작성한 코드 분리하는 것까지만 보고 껐다.(와중에 adaptor 쓰는 걸 보니 헥사고날 아키텍처였던 듯...🤮)

여튼 테스트 코드로 테스트 해보고 필요한 로직을 작성하면 되는 거잖아!

하지만.

컨트롤러 > 서비스 > 레파지토리 > sql 이 방향으로 짜던 머리를, 

테스트 > 서비스 > ??? 이 방향으로 굴리려니 뇌의 과부하가 왔다.

어찌 어찌 기본 성공 케이스를 짜는 데는 성공? 했지만... 테스트 케이스를 뭘 얼마나 작성해야 하는 걸까. 다시 멘붕...

실패 케이스가 중요하다지만, 어떤 실패를 내면 되나요...

TDD도 잘 못하겠는데, 동시성 컨트롤은 또 어떻게 하지...

1주 전의 나는 레드 뱃지 받고 싶다고 했는데 네, 실언이었어요^^

공부할 시간이 없어 새벽에 잠들다 보니 회사 생활도 엉망이 됐다.

반차 두 번에 시차 한 번... 그래도 피곤하고......

어쨌든 한 주가 끝났다.

KEEP.

이번주에 하루 최소 두시간 공부가 목표였는데, 두 시간이 뭐야 퇴근하고 와서 새벽까지 해도 모자라요. 본의 아니게 목표 달성.

좋은 게 좋은 거지. 계속 이렇게 매일 공부하자.

PROBLEM.

근데 잠은 자야함.

TRY.

이번 주는 TDD를 잘 모르겠어서 팀원이나 코치님께 뭘 물어봐야 할지도 알 수 없었다.

그러니 개념은 주말에 공부할 것.

코드 짜면서 모르겠는 게 생기면 팀원이나 코치님께 물어볼 것.

또한 팀원들이랑 협의해서 멘토링 시간을 주 중간에 잡는 게 좋을 것 같다.

이번에는 과제 다 끝나고 멘토링을 해서 과제에 도움을 받을 수는 없었다

1. onPress={() => handleClickedSave()}

이 문법에서는 화살표 함수를 사용하여 handleClickedSave를 호출

• 장점:
  • handleClickedSave에 인수를 전달할 수 있음
  • 컴포넌트가 렌더링될 때마다 새로운 함수가 생성되므로, 항상 최신의 상태를 유지할 수 있음
• 단점:
  • 컴포넌트가 렌더링될 때마다 새로운 함수가 생성되기 때문에, 렌더링이 빈번하게 발생하는 경우 성능 문제가 발생할 수 있음
  • 깊이 중첩된 컴포넌트나 자식 컴포넌트가 많은 경우, 성능에 영향을 미칠 수 있음

2. onPress={handleClickedSave}

이 문법에서는 함수 참조를 직접 onPress 속성에 전달

• 장점:
  • 렌더링할 때마다 새로운 함수가 생성되지 않으므로, 일반적으로 더 나은 성능을 제공
  • 메모리 사용이 적고, 특히 렌더링이 빈번하게 발생하는 경우 유리
• 단점:
  • 인수를 전달할 수 없음. 인수를 전달해야 한다면 화살표 함수를 사용해야 함

요약

• onPress={() => handleClickedSave()}: 새로운 함수가 매 렌더링마다 생성됨. 인수를 전달할 수 있음
• onPress={handleClickedSave}: 함수 참조가 그대로 전달됨. 성능이 더 GOOD

대부분의 경우, 인수를 전달할 필요가 없다면 두 번째 방법(onPress={handleClickedSave})을 사용하는 것이 좋음

> 성능 최적화에 유리하기 때문에

인수를 전달해야 한다면 첫 번째 방법(onPress={() => handleClickedSave()})을 사용

24.06.15(토) 시작~

1. 지금까지의 회고

24년 하반기 이직을 목표로 항해 플러스 백엔드 10주 코스를 신청했다.

5기 모집 막바지에 지원해서 스터디 할 시간이 없었던 것이 아쉽기도 하나, 앞으로의 과정에 설레는 중

2. 항해 플러스 참여 계기

이직을 생각하고 있었으나 공고에서 요구하는 역량과 현재 내 역량을 비교했을 때 모자란 부분이 많았다.

거의 다! 모자르게 느껴졌다.

그러던 중 내가 필요로 하는 커리큘럼으로 딱 맞게 짜진 항해 플러스를 발견하게 되었고,

이직까지 도움을 준다하여 바로 참여를 결정했다.

3. 향후 5년 뒤 커리어 방향성

현재 1년차인 내게 당장 3년차가 되었을 때의 내 모습도 잘 그려지진 않지만, 음.

그 때도 변함없이 내게 부족한 부분을 배우고 보완하며 개발자로 살고 있을 것 같다.

다만 그 때는 자체 서비스를 하는 회사에서 개발을 하면서 후배에게도 도움이 되는 선배가 되고 싶다.

4. 10주간의 목표

시간적인 부분으로 얘기하자면 매일매일 꾸준히 공부해서 한 주, 그리고 10주를 만들어나가는 것이 목표

능력적인 부분으로 얘기하자면 발제 주제를 적어도 혼자 해낼 수 있을 정도로 익히는 것이 목표

5. 최종 목표 배지

목표는 크게! 블랙 배지! 

현실적으로는 레드?