내가 작업하는 개발물에 대해 시니어 개발자 분이 리뷰를 달아주셨다. 너무나도 감사하다.
다음과 같은 사항이었다. 나도 피드백을 받은 즉시 공부해서 벨로그에 업로드 하여서 내용이 남아있지만 한번에 한번 더 정리하고 싶어서 로그를 남긴다.
-
변수를 굳이 만들지 않고 if 절을 사용해 한번에 return 하기
-
ResponseEntity로 굳이 감쌀 필요가 없는 것에는 감싸지 않기. 그냥 List 를 반환해도 ResponseEntity로 감싼것과 같은 효과가 난다.
-
(가장 복병이었던.. ) getAll을 할때 나중에 데이터가 많아지면 응답 데이터가 엄청 커질 것 같으니 최대 제한 수를 정해놓는게 좋은 것
- 페이지네이션에 대해 공부하게 되었다.
- 나는 무한 스크롤이기 때문에 모든 항목을 다 주면 알아서 클라이언트에서 끊어서 뷰를 생성할 줄 알았다. 하지만 아니었다. 이것도 백의 역할이다!
- 무한스크롤이라 페이지네이션을 더욱 구현해야 한다. 무한스크롤 기법 하의 백엔드에서 사용하는 페이지네이션 기법은 커서 기반 페이지네이션 (cursor-based pagination) 이 있다.
- SELECT * FROM lesson 과 같은 쿼리는 enum용도의 테이블이 아니라면 백엔드 선에서 컷해야 한다. 무조건 LIMIT과 함께 사용하여 페이지네이션 형태로 제공해야 합니다.
-> 우선 페이지네이션이라는 개념 자체가 이해하기 어려웠고, 구현하기도 너무 어려웠지만 많은 도움 주셔서 덕분에 정말 잘 이해하게 되었다. (거의 과외 수준 ㅜㅜ ㅎㅎ)
- HTTP 응답 코드 활용하기
- 나는 보통 OK를 주로 사용하고 NO_CONTENT같은 204번은 사용할 생각도 하지 못했다. 하지만, 짚어주셔서 내 코드를 더욱 클라이언트가 이해할 수 있도록 짝 수 있었다.
- 보통 응답이 비어있는 경우에 204 NO_CONTENT http code를 사용하면 클라이언트에서 조금의 성능 향상이 있을 수 있습니다. 응답 데이터를 아예 무시해버려서 조금 더 낫습니다.
라고 하셨다 ㅎㅎ
- 순환참조에 대해
- 내가 짜고 있는 로직은 한개를 조회할 시, 같은 카테고리의 항목 중 3개를 랜덤으로 다시 불러와야하는 로직이었다. 나는 DTO에 묶어서 보내는 방식으로 짰다. 그런데 이렇게 말씀하셨다.
- LessonResponse 안에 자신의 List를 갖는 이유는 무엇때문인가요? 이거는 잘못하면 순환 참조가 발생할 수 있을 것 같아 위험해 보이네요.
- 덕분에 순환참조에 대한 경각심을 갖고, 코드를 수정할 수 있었다. 생성자를 여러개 만들어 상황에 따라 사용하도록 하였고, List는 Nullable하게 구현하였다.
- 쿼리 관련 무작위 검색
-
내가 짠 쿼리는 다음과 같다.
@Query(value = "SELECT * FROM lesson l WHERE l.category = ?1 AND l.id <> ?2 ORDER BY RAND() LIMIT 3", nativeQuery = true)이렇게 쿼리를 짠다면, 일단 다 불러 온 다음에, 조건에 맞게 선별을 한 후, 랜덤으로 정렬을 한 다음에 그 중에 3개를 가져온다.
그렇게 되면 불필요하게 다 불러오고 정렬을 하게 되는 정말 효율적이지 않은 쿼리가 된다. -
무작위로 3개를 뽑아오는 코드라면 DB에서 무작위 함수를 돌려 뽑게되면 인덱스를 타지 않아 scope이 많아질 수록 성능 이슈가 있으니 충분히 scope를 조절할 수 있는 게 아니라면 무작위 지정은 서버에서 하는 것이 좋아보입니다. 라는 피드백을 즉각 수용하여 무작위 지정을 서버에서 하도록 구현하였다.
- 트랜잭션
- 운영체제에서 배운 동시성 문제에 대한 경각심을 한번 더 일깨워주셨다.
- 어노테이션을 통해 간단히 구현할 수 있다.
- Converter
-
Enum 과 String 사이에 Converter가 필요한 순간이 있다고 하셔서 피드백을 받은 즉시 구현을 하였다.
( 근데 내 로직에서는 컨버터가 필요없어서,, 그래도 좋은 경험이었다)
이건 어제 따끈따끈하게 받은 피드백!! 아직 벨로그에 정리하지 않았다.
-
ddl-auto: validate
으로 설정하는게 크리티컬하지 않다.
나는 전에 create으로 하였다가 배포 직전에 DB를 날려버린.. ㅜㅜㅜ 정말 끔찍한 기억이 있기 때문에 update으로 설정하고 작업을 진행하곤하였다.
근데 그렇게 되면 타입이 바뀌고 User을 건들일 수 있다고 하셨다.
그래서 운영단계에서는 무조건 validate을 쓰는게 좋다고 하셨다.
DB조작은 직접 DB 들어가서 하는 것이고, 서버에서는 읽기 모드처럼만 사용하는게 가능하고 이게 좋다고 하셨다. -
Page를 쓰는 것에 대해
-
nativeQuery 에 대해
-
ORM에 대해
-
커서기반페이지네이션 -> 쿼리 날릴때 필터링 할 수 있다
-
페이지네이션 : offset vs cursor-based-pagenation
-
PageRequest 에 대해
나도 언젠간 성현님 같은 멋진 시니어 개발자로 성장하길!
