질문 목록
- 중복 확인 → GetMappling 으로 RequestParam : 선택의 차이이긴 하지만 pathvariable은 키를 넘길때 사용하는 것이 멘토님 취향입니다.
- 팀 권한에 따른 api 호출
- Grade class → public static fonal Set<Grade> = set.of(권한, 권한)
- if(grade.POST_ABDD.contains(teamUser.getGrade())
- 데이터를 보여줄때 렌더링 할 데이터를 완벽히 백엔드에서 정렬 또는 가공해서 보내줘야 맞는 걸까요 아니면 프론트에서도 어느 정도 추려서 사용하는 것도 괜찮은 걸까요??
- 클라이언트가 하나일 경우 백 /프론트 어느 부분에서 해도 되지만 클라이언트가 여러 가지인 경우(웹, 모바일) 서버에서 하는 것이 맞지만 서버 자원의 레이턴시 를 고려해야 한다.
- 팀 해체 시 → 연관된 데이터가 어디까지 지워져야 할지 →
- team이 소프트 삭제되면 teamuser를 물리 딜리트 / 삭제 된 팀을 조회할때는 (매치기록 볼때) 딜리트 쿼리 조건을 빼주자 (isdelted=true도 조회)
- 실무에서는 100% 확률을 예측하고 조건문을 걸지 않습니다.
- 주장이 회원 탈퇴하면 팀은??
- 프로젝트 중 1시간씩 프로젝트를 정리하는 시간을 갖는 것도 좋을 것 같아요
- 개발중 이슈 (순환참조...
- 프로젝트에서 가장 어려운 점
- 컨벤션을 강하게 잡아서 좋았던 점
- jpa를 써서 좋았던 점
- erd 짤때 멘토님과 미팅할때 질문 내역
- 이력서 / 포트폴리오 와꾸 (21~23일에 해오세요!!)
미팅 정리
- http vs https : 프론트와 백엔드 둘다 같은 프로토콜로 맞추는 것이 좋다.
- 2가지 적용 시점이 있을 수 있다.
- 이슈가 나왔을 때 적용
- api 구현 / 연동 완료 후 배포 직전에 적용후 배포
- 순환 참조 :
- Spring Boot : 2.6 버전부터 순환참조 문제가 있을시 서버에 못올라가도록 막힙니다.
- 순환참조를 일으키는 적게 사용되는 service의 주입을 빼주어서 필요한 메서드를 facadeService 에 중간에 구성한다.
- 순환 참조를 피하기 위해 service를 주입받는 대신 repository를 주입 받은 경우 : 현재 방식
- 현재 참조되는 상황에서 잘못된 방식은 아니나 중간에 인터페이스를 구성해서 해결하는 방식을 구현해 보는 것이 좋을 것 같다.
ToDo
리펙토링 : reviewMatch → if문 switch 문으로
if vs switch (바이트 코드)
- if 문 : 하나 씩 단계별로 실행 1번 조건이 아니야 → 2번으로 가 → 그다음 3번으로가
- switch : 조건에 맞는 로직으로 바로 이동