멘토링 날짜 : 2024년 1월 10일 수요일 오전 10:10

• 코드 컨벤션

  • 디렉토리명은 단수 명사
  • 클래스명은 파스칼 케이스
  • 테이블명은 tb_ 붙여서 통일성 유지
  • 엔티티는 -Entity 붙이지 말고 도메인명 그대로
  • 엔티티에 필요한 메서드 만들되, 명확하게 기능명을 메서드명으로 명명
  • Repository에서 가져올 때 Optional 사용
  • JpaRepository 상속 대신 RepositoryDefinition 어노테이션으로 필요한 메서드만 쓰기
  • 생성자는 서비스 코드 정적 팩토리 메서드, 테스트는 빌더 패턴 이용
  • 객체 간 변환 작업은 mapStruct 사용
  • ResultCase로 성공 및 실패 케이스를 enum으로 묶음
  • 테스트는 단위 테스트만, 성공 케이스만을 다룸
  • API당 요청, 응답 DTO 1개씩 만들기
  • DTO 네이밍 규칙은 도메인 + 기능 + 요청/응답 + Dto, ex) UserLoginRequestDto
  • DTO는 Record 사용
  • 패키지 구조는 domain, global, infra 로 나누어서, 하위는 각 도메인 별로 또 디렉토리 나누기.

• 깃플로우 전략

  • Github flow 전략을 사용하여, main 브랜치를 유지하면서 새로운 작업을 시작할 때 브랜치 분기 후 작업하고 완료 시 머지.
  • 작업 시작 전 이슈로 작업 내용을 작성 후, 작업 완료 시 관련 이슈를 PR에 등록하기
  • 브랜치 분기 후 커밋에는 [#4] feat : add login api 와 같이 이슈번호 명시

• 배포 계획

  • Github action으로 Ci & CD 구현하여 배포까지 진행.
  • 우선은 현재 EC2에 인스턴스를 1개 만들어둔 상태.

• 이번 주 한 일

  • 기획 및 기획 개편 (피드백) 전반적으로 잘 작성 되어 있음, 아래 기획과 관련된 문서 내용이 전체 목표 대비 얼마나 작성 되었는지 궁금합니다. → 1.10(수) 오전 피드백 시에는 기획 대비 예상 가능한 완성도를 얘기 해주셨던거 같습니다.
    • 시스템 상황 분석 및 기획서 작성
    • ERD 작성
    • 와이어 프레임 작성
    • API 명세 작성
    • 개발 컨벤션 작성
  • 개발 환경 설정 (피드백) 특별히 코멘트 할 내용 없습니다.
    • 깃허브 Organization 및 Repository 생성
    • 이슈 및 PR 템플릿 생성
    • Branch protection 설정
      • main 브랜치 push 금지
      • PR approve 1개 이상 시 merge 가능
      • merge 시 브랜치 자동 삭제
    • 팀원 모두 AWS IAM 사용자 부여
    • EC2 인스턴스 생성 및 pem 공유 완료
    • 프로젝트 기반 코드 작성
      • 라이브러리, 디렉토리 구조, BaseEntity, 등등
  • 팀원 개인
    • 프로젝트 초기 설정을 하느라 다같이 모여서 의논하여 위를 진행했습니다.
    • 김재윤
    • 임지훈
    • 황규정
    • 장규빈

⭐ 기술적인 방향을 잡기 위한 질문 정리

[부하테스트 관련]

• 부하테스트 프레임워크 ::: JMeter를 사용할까 vs nGrinder를 사용할까? (피드백) 국내 테크 기업 타겟 → nGrinder / General → JMeter

[레디스 관련]

• 부하 테스트에서 1000개의 상품이 있다면 요청이 1000개 각각으로 균일하게 요청이 되는 것이 아닐텐데, 최대한 실제 환경과 같이 부하를 주려면 관련 알고리즘? (피드백) 질문에 대한 답변부터 하자면 1~1000 integer 반복문을 돌리면서 2의 배수면 A상품, 3의 배수면 B상품… 이런식으로 요청을 주면 비중을 다르게 보낼 수 있으나, 부하테스트의 목적은 서버에 임계치 이상의 요청이 들어왔을 때 서버가 견고하게 버티면서 제대로 서비스를 처리해줄 수 있는지를 확인하는 것이 목표이기 때문에 균일하게 요청이 가냐 안가냐에 관심이 있는 부분은 아님.
  • 그리고 실제 상황과 비슷한 요청을 받을 때, 이를 캐싱하고 안 하고 의 기준들이 있는지 (피드백) 개발자가 그 때 그 때 판단함, 기준이라기 보단 휴리스틱이 있다고 얘기하고 싶음, 여러분들이 생각하기에 기준을 판단할 때 어떤 것들을 고려해서 캐싱 여부를 결정해야 할까요?
• 레디스 클러스터를 구성할 때, 직접 EC2에 구축을 해보는 것이 ElasticCache 와 같은 잘 구축된 서비스를 사용하는 것과 비교할 때 유의미한 경험일지. (피드백) ElasticCache 쓰세요. AWS에서 항상 하는 말 - 바퀴를 재발명 하지 마라. 잘 만들어 놓은거 잘 쓰는것도 기술입니다.]
• 어떤 데이터를 캐싱해야할지 감이 잘 안 잡혀요. << 1차 멘토링 이후 질의>>

[메세지 브로커 관련]

• 메세지 브로커가 다음 역할을 위해 사용하려고 하는데 적합한지 궁금합니다. (피드백) 일반적으로 적합하다고 생각됨
  • 큐를 사용하여 구매입찰/판매입찰 요청에 대한 동시성 제어
  • master와 slave 동기화