코드메모장

1. 문제

• Layered Architecture + Clean Architecture를 잘 지키면서 개발을 하고 있는지..?

• Facade 패턴을 활용

2. 시도

• 아키텍처 관련 매니저님께 문의

• 다른 팀원과 각자 개발한 아키텍처 구조 설명 및 논의

• 구글링

3. 해결 / 알게된 것

• 아키텍처도 어느정도 기준은 있지만 명확한 정답이 없으며 각 클래스의 역할에 대한 관점을 어떻게 보냐에따라 다르게 생각할 수 있다고 판단되었습니다.

• 내가 활용한 Facade패턴

  1) domain에 있는 Respoitory를 참고하는 Service를 만들고, 해당 Service에서 비지니스 로직을 전부 구현

  2) 다른 서비스를 참고해야 하는 경우 Facade를 만든 후 해당 Facade에서는 각 서비스의 로직을 호출만 하여 원하는결과를 출력할 수 있도록 구현

  3) Controller는 Service를 모르며, Facade만을 호출할 수 있도록 구현

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

1. TDD

2. 아키텍처 구조

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

• 이번에도 과제 제출 전날인 목요일날 밤샘작업을 진행했다.... 뭐든 미리미리 하는것이 중요한데, 분발하여 미리끝낼 수 있도록 해보자!

• 내가 생각했던 범위보다 과제의 양이 많았다. 그래도 일정에 맞춰 작업물을 제출할 수 있어서 다행이지만.. 개선이 필요하다!

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

• 상대적으로 안정적인 월 ~ 수 시간을 많이 활용하여 작업을 진행하자!

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

• 시퀀스 다이어그램 작성하는것에 익숙하지 않은 문제점이 있었습니다.
• Mock API 작성을 실제로 해본 경험이 없어 어떻게 작성을 해야하는지 학습이 필요했습니다.

2. 시도

• 시퀀스 다이어그램 학습
  • 구글링 및 Chat GPT를 통해 다른 서비스에 대해 어떤식으로 시퀀스 다이어그램을 작성하는지 학습 및 작성
  • 개인적으로 시퀀스 다이어그램 작성 및 조원분들과 공유 하여 서로에게 피드백 진행
• Mock API 학습
  • 구글링을 통해 Mock API 작성방법에 대한 학습 및 작성

3. 해결

• 시퀀스 다이어그램
  • API 별로 나누어 각각의 시퀀스 다이어그램을 작성하니 정리도 편하고 보기에도 깔끔하게 잘 작성되었습니다.
• Mock API
  • API 명세와 MockAPI를 한번에 처리하기 위해 Swagger를 사용하였습니다. (오히려 독이 되어.. Fail로 돌아옴 ㅜㅜ)

4. 알게된 것

• 시퀀스 다이어그램을 작성할때 DB, Service와 같이 상세하게 처리하게 되면 오히려, 개발하는데 있어 제한을 두게될 수 있으므로 추상적으로 작성하는것이 좋다.
• MockAPI를 만들때는 실패 케이스는 처리하지 않아도 된다(?). 라고 김종협 코치님께 피드백을 받았습니다.

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

• 팀원들과 소통을 통해 각자의 과제 진행상태에 대한 피드백을 진행하는것을 계속 유지하면 좋을듯 합니다.

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

• 이번주차가 설계 주차이기에, 긴장감이 조금 풀어졌던것 같습니다. (노력해야지....)
• 더 하려고 하지 말고, 기본을 잘 지키며 과제를 진행하자! (다음주차에 swagger 적용이 있는지 모르고... 미리 작성을 해버림...)

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

• 10주차 중 이제 3주차가 지났으며, 마지막까지 긴장을 하며 열심히 달리겠습니다!!

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

• 동시성 이슈를 해결하기 위해 DB Lock을 공부가 필요했습니다.
• 동시성 이슈 테스트과정에서, Thread와 DB connection pool의 관계로 인하여 문제가 발생하였습니다.

2. 시도

• DB Lock에 대한 학습을 진행하였습니다.
  • 구글링, Chat GPT를 통해 낙관적 락, 비관적 락 에 대해 차이점을 공부 하여 어떤 Lock을 적용해야할지 고민하였습니다.
• Spring Boot 설정값을 변경하였습니다.

3. 해결

• 데이터 충돌이 많이 발생할 것으로 예상되어 데이터를 읽는 시점부터 Lock이 되는 비관적 락을 선택하였으며, 코드로 적용하는것은 생각보다 간단했습니다.
  • 비관적락 - @Lock(LockModeType.PERSSIMISTIC_WRITE)
• Spring Boot 설정시 hikair 설정을 변경하여 connection pool의 크기를 늘렸으며, 해당 크기에 맞게 Thread의 개수 제한도 설정하였습니다.
• 동시성 테스트 코드에서 Semaphore 를 사용하여 전체 Thread가 50개를 실행할 예정이어도 10개씩 나누어서 동작할 수 있도록 처리하였습니다.
  • ex) 50개 실행 → 10개만 우선 동작 → 1개 완료 → 남은 40개의 스레드 중 1개 동작 → …. → 50개 완료

4. 알게된 것

• DB Lock을 어떤 기준으로 선택해야하는지 알게되었습니다.
• 웹서버의 Thread수와 DB connection pool에 대한 설정을 서비스에 맞게 설정해주어야 사이드이펙트를 피할 수 있다는것을 깨달았습니다.

5. 지난 목표 회고

• TDD를 작성하며 개발하는것이 목표였으며, 잘 이루어지고 있어 뿌듯합니다.

6. 다음 목표 설정

• 이전 목표들은 유지하면서 다음 목표는 내가 학습한 내용들에 대한 문서화를 열심히 진행하고 싶습니다.

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

• 테스트 코드 작성은 익숙한 상태이나, TDD 방법론에 맞게 개발을 진행한 경험이 없어 초반에 어려움을 겪었습니다.
• 코틀린 코드에 아직 익숙하지 않아 코틀린스러운 코드를 작성하는데 어려움을 겪었습니다.

2. 시도

• 항해99 플러스에서 제공한 open Q&A를 참여하였습니다.
• Git Commit을 최대한 분리하여 작성하면서 TDD 방법론에 맞도록 구현 시도 했습니다.
• 스파르타 코딩클럽에서 제공해준 코틀린강의를 우선적으로 학습하였습니다.

3. 해결

• 코틀린 코드를 작성하기 위해 ChatGPT를 사용하며 우선적으로 문제를 해결하였습니다.

4. 알게된 것

• EndToEnd 테스트, 통합 테스트, 유닛 테스트의 차이점
  • EtoE 테스트
    • 사용자가 요청을 보내고 응답을 받는 전체적인 테스트 (api 테스트)
  • 통합 테스트
    • 하나의 컴포넌트가 다른 하나 이상의 컴포넌트를 참조 및 호출하여 정상적으로 동작하는지에 대한 테스트
  • 유닛 테스트
    • 하나의 컴포넌트가 다른 컴포넌트를 참조하지 않고 가짜 객체(Mock or Stub)를 활용하여 정상적으로 동작하는지에 대한 테스트
• Test Double 개념에 대한 이해
  • 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행할 수 있도록 만들어주는 객체
    • Dummy: 아무 기능도 하지 않는 객체로, 보통 메서드 호출이 필요하지만 실제로 그 결과가 테스트에 중요하지 않은 경우에 사용됩니다.
    • Fake: 실제 동작을 흉내내는 객체로, 보통 간단한 구현을 통해 실제 객체를 대체합니다. 예를 들어, 인메모리 데이터베이스를 사용할 수 있습니다.
    • Stub: 사전 정의된 응답을 반환하는 객체로, 특정 메서드 호출에 대해 고정된 결과를 제공하여 테스트의 예측성을 높입니다.
    • Spy: 호출된 메서드와 전달된 인자를 기록하는 객체로, 호출 여부나 호출된 횟수 등을 검증하는 데 사용됩니다.
    • Mock: 사전 정의된 기대값과 행동을 갖는 객체로, 특정 메서드 호출이 특정 조건을 만족하는지 검증하고, 그에 따라 예외를 던지거나 다른 동작을 수행할 수 있습니다.

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

• 프로젝트를 진행하면서 앞으로 TDD 방법론을 지키면서 작업을 진행 할 예정입니다.
  • 테스트 코드를 작성함으로써 각 함수들의 기능이 정상적으로 잘 돌아가고있다는 확신이 들며 편안하게 리펙토링을 할 수 있어 좋았습니다.

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

• 개발을 들어가기 이전 테스트 테스트 케이스들을 먼저 작성 후 작업을 진행해야 하지만, 그렇게 진행하지 못한부분이 조금 아쉽고 개선해야하는 점으로 생각합니다.

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

• 개발을 진행하기 이전에 어떻게 작업을 진행할지 노션 혹은 다른 문서에 작성을 우선적으로 진행하도록 시도해 볼 예정입니다.

과제 제출 링크

• https://github.com/Loafly/hhp_week_01