항해 플러스 백엔드 코스 6기 1주차 회고 WIL

항해 플러스 추천인 코드

지원페이지에서 추천 코드에 3ZTeU1를 입력해주시면 20만원 할인 적용됩니다.
항해 플러스 과정에 관심이 있는 분들은 아래 링크를 통해 신청해보세요!
궁금하시거나 커피챗을 하고 싶으신 분들은 링크드인이나 kboxstar@gmail.com으로 연락주세요.

항해 플러스 과정 페이지

항해 플러스 백엔드 코스 6기 1주차 회고 WIL

항해 플러스 백엔드 코스 6기 1주차 회고 WIL을 작성한다.
이번 주차는 TDD(Test Driven Development)를 이용하여 포인트 관리 API를 구현하는 과제를 진행했다. GitHub Repository

[GitHub - hhpb-code/hhplus-tdd-java: 1주차 발제: TDD 로 개발하기

1주차 발제: TDD 로 개발하기. Contribute to hhpb-code/hhplus-tdd-java development by creating an account on GitHub.

github.com](https://github.com/hhpb-code/hhplus-tdd-java)

처음 진행되는 과제였고 나의 목표는 ALL Pass에 우수 과제 선정이였다.

이번에 우수과제 + 명에의 전당에 선정되어서 다음 주차도 열심히해서 연속으로 해봐야겠다.

[우수 과제 선정]

[명예의 전당]

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

이번 주차를 지나며 겪었던 문제가 무엇이었나요?

• 유닛 테스트 작성의 범위
• 각 layer별 테스트의 범위
• 중복되는 코드 및 역할 과 책임
• 멀티 스레드 환경에서의 동시성 방법

2. 시도

문제를 해결하기 위해 어떤 시도를 하셨나요?

효과적인 유닛 테스트의 범위에 대해 고민하고 TDD를 하려는 목적에 대해 고민하였다.
TDD를 하는 이유는 코드의 안정성을 높이고 빠르게 개발하기 위함이라고 생각했다.
하지만 불필요한 테스트 코드의 경우 빠르게 개발하는 것을 방해할 수 있다고 생각했다.
그래서 효과적인 테스트 코드를 작성하기 위해 노력하였다.

멀티 스레드 환경에서의 동시성 방법에 대해 고민하고 공부하였다.
해당 부분은 동시성 제어 방식에 대한 분석에 정리하였다.

3. 해결

문제를 어떻게 해결하셨나요?

• 유닛 테스트 작성의 범위를 정의하고 테스트 코드를 작성하였다.
• 각 layer별 테스트의 범위를 정의하고 테스트 코드를 작성하였다.
  • Controller
    • 통합 테스트
  • Service
    • 유닛 테스트
    • 통합 테스트
  • Repository
    • 유닛 테스트
  • 객체 (Command, DTO, Entity, Validator, ...)
    • 유닛 테스트

4. 알게된 것

문제를 해결하기 위해 시도하며 새롭게 알게된 것은 무엇인가요?

나는 Test case간의 의존성이 없어야 된다고 생각한다.
하지만 DB가 아닌 List로 구현된 가상 DB를 사용하고 있었고 delete 메소드가 별도로 구현되어 있지 않았다. (과제 요구사항에 해당 코드는 수정이 불가능 했다.)
그래서 Bean을 초기화 하는 방법이 있을까? 찾아보던 중 @DirtiesContext 어노테이션을 알게 되었다.
@DirtiesContext를 사용하면 context를 재생성할 수 있어 test case간의 의존성을 없앨 수 있다.
하지만 이 방법은 말 그대로 context를 재생성하다 보니 속도가 느리다.
Test case간 userId를 다르게하여 의존성을 없애거나
초기값으로 계속 update하여 초기값 세팅을 하는 방법이 가장 좋았을 것 같다.

Keep : 현재 만족하고 계속 유지할 부분

이번 주를 마무리 하며 나에게 만족했던 부분은 무엇인가요?

TDD 방법론에 대해 많은 고민을 하며 다른 사람들과 의견을 나누고 멘토님에게 질문을 하며 공부한 것이 만족스러웠다.
TDD 방법론은 처음 나는 코드의 안정성은 올라가지만 개발 속도가 느려질 것이라고 생각했다.
하지만 직접 해보면서 느끼니 오히려 개발 속도가 올라 갈 수 있다고 생각했다.
지금처럼 비지니스가 간단한 로직이라도 요구사항이 변경된다면 코드의 검증이 필요해지는데 이를 테스트 코드로 간단하게 딸깍해서 검증할 수 있다.
그리고 코드의 설계 관점에서 테스트가 용이한 코드를 짜면서 덤으로 코드의 품질이 올라가는 것을 느꼈다.

Problem : 개선이 필요하다고 생각하는 문제점

이번 주를 마무리 하며 개선이 필요하다고 생각했던 문제점은 무엇인가요?

P1. 혼자서 너무 깊게 고민하지 말자.
P2. 좀더 좋은 코드를 짜기 위해 노력하자.

Try : 문제점을 해결하기 위해 시도해야 할 것

이 문제점을 해결하기 위해 다음 한 주간 시도 할 것은 무엇인가요?

P1. 혼자서 너무 깊게 고민하지 말자.

• 모르는게 생기면 깊게 오래동안은 생각하지말고 주위 사람들과 이야기 나눠보거나 멘토님께 질문하자.
  이거는 실무에서도 중요한 부분이다.
  내가 아직 모르는 개발 지식이 많다. 이걸 알기 위해선 수많은 고뇌를 해야하는데 그게 쉽게 풀릴 수 도 있지만 안풀리는 경우도 많다.
  이런 경우는 나의 시간(리소스)를 많이 잡아 먹게된다.
  시간은 중요하다. 시간을 잘 관리하는 것도 중요한 스킬인 것 같다. (시간이 낭비가 되면 야근을 해야한다)

P2. 좀더 좋은 코드를 짜기 위해 노력하자.

• TDD 방법론을 통해 테스트가 용이한 코드를 짜면서 코드의 품질을 올리고 있었다.
  하지만 매일 새벽 4~5시에 자면서 지친 나는 좀더 개선이 가능한 부분이 있음에도 불구하고 그냥 넘어가는 경우가 있었다.
  이 부분에 대해 좀더 고려해봤다면 나에게 좋은 개발 공부가 되지 않았을까 싶다. (항해가 끝난 후 따로 해봐야겠다)