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