코드메모장

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. 다음 목표 설정

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