TIL_2022.09.14

1. Facts(사실, 객관)

- 견적서 개선

- 페이징 관련 강의 수강

 

2. Feelings(느낌, 주관)

이번 견적서는 다양한 부서에서 요청이 온 만큼 개선사항도 많았습니다. 사소한 오탈자부터 글씨체 통일과 추가개발까지 있습니다. 각 부서와 협력하여 어느정도 수준까지 구현하고 언제 완성할지를 정했습니다. 모든 것이 완벽하게 만들어진 상태에서 운영을 시작하는 것이 아닌, 구동 가능한 기능이 만들어진 상황에서 오픈하고, 추가적인 간편화 작업들이 이후에 더해지도록 했습니다.

 

또한 QueryDsl로 열심히 쿼리문을 작성했었는데, 페이징과 관련해서 좀 더 성능을 잘 내고 싶었습니다. 따라서 강의를 다시 보고 어떻게 하면 좋을지 고민했습니다. 항상 코드의 간편성과 성능의 트레이드 오프에 주의해야 합니다. 코드가 간편할수록 성능이 떨어질 수 있고, 성능을 위해서는 복잡한 코드가 있을 수 있습니다. 페이징의 적정한 정석은 OneToMany를 @BatchSize로 in절을 사용하도록 하는 것입니다.

 

3. Findings (배운 점)

- fetch join은 OneToOne과 ManyToOne에서만 사용

OneToMany에서는 데이터가 뻥튀기 되므로 사용하지 않는다

 

- OneToMany는 for문을 돌면서 @BatchSize를 활용하여 조회하도록 하면 자체적으로 in절을 활용해 성능 향상

 

- Dto를 바로 조회하기 위해서는 패키지명까지 써줘야하는 불편함이 있다

 

- Map과 in절을 활용하면 Dto 조회 시 성능을 향상할 수 있으면 엔티티를 반환하는 @BatchSize와 같은 결과를 반환한다.

 

- 실무에서는 Dto가 아닌 엔티티를 조회하는 것이 좋은데, 조금만 수정해도 다양한 형태로 변형이 가능하기 때문이다

 

4. Action (구체적 계획)

- 페이징을 이용해서 프로젝트 개선하기