- 각자 상황 공유
- 주말 까지 restdocs 진행하는 게 좋을 것 같음
- 프로필 받아올 때 ridingpost 정보까지 받아오는 것이 문제의 여지가 있음
- 추후 리팩터링/최적화 때 수정
- 프론트에서는 한 번에 받는 것이 편하다고 함.
- querydsl 활용 코드들 리뷰 필요. (Kant, Pray)
- 리스트 조회의 개별 데이터의 크기가 너무 크다
- 요구사항에 최적화할 필요가 있음.
- 평가 부분 - Didi
- 리프레시 토큰 구현 - Partey
- 필터에서 구현하면 테스트 코드가 붕괴된다.
- 필터에서는 만료 테스트, 토큰이 제대로 된 토큰인지 검증.
- /user/me 에서 토큰 확인
- Riding 조회 이슈 대응.
멘토님 최종 방문
프로젝트 피드백
성공 케이스에 치우친 테스트 코드
예외 케이스들도 테스트 해야 한다.
데드 코드
ex) dummy.java
데드 코드를 만들지 않은 사람은 무서워서 지울 수가 없음
의미 없는 주석
코드만 봐도 알 수 있는 주석들을 지울 것.
깔끔한 코드
코드만 봐도 로직을 이해할 수 있도록 짜야 한다.
개인적으로 기술적인 것보다 더 중요하다고 생각(기술적인 것들은 회사에서 배우면 되니까)
불필요한 모듈
스프링에서는 자바 내장 Http 모듈보다는 RestTemplate를 사용할 것.
문서화
각자 프로젝트에서 구현한 것들을 정리해서 공유할 것
ex) 데브옵스, 스프링 이벤트
API 버저닝
API 클라이언트를 직접 제어할 수 있는 팀의 경우 버저닝이 불필요하다고 생각한다.
API 변경에 맞춰서 클라이언트 앱 개발자에게 수정을 요청하면 된다.
과제 범위
범위를 잘 줄여서 잘 한 것 같음
e2e 테스트
로컬에서 한다. 실제 배포 환경과 큰 차이가 없다.
저장소에서 받아온 프론트엔드 코드를 실행시켜서 테스트한다.
인증 필요 API 테스트
인증이 필요한 API라도 인증이 준비되지 않으면 일단 인증 없이 코드를 실행하고 테스트 한다.
Q&A
리프래시 토큰 전략
refresh 토큰 저장 전략
헤더,쿠키,localstorage,캐시 등
각 방식의 장단점을 파악해서 현재 프로젝트에 맞는 것을 선택할 것.
멘토님 : DB에 저장
로그인 token은 아님
api 사용 권한 토큰
조인 쿼리 상충 관계
데이터베이스 1:N 테이블 조인
한 테이블에서 1:N 관계가 여러 개일 경우 조인 때문에 시스템 부하가 일어나지 않는가?
꼭 필요한 것은 어쩔 수 없다.
초대형 쿼리 vs 쿼리 분할
쿼리를 여러 개 실행한다고 네트워크 성능에 크게 문제가 되지 않는다.
거대한 도메인 문제
연관 관계가 복잡해질 수록 코드가 복잡해지는 것은 JPA를 사용하는 이상 막을 수 없음.