필요한 기능만을 빠르게 구현한 후 리팩토링 과정을 통해 쿼리 실행 개수를 10개에서 5개로 줄일 수 있었다.
Paper API 중 페이퍼 상세보기 기능 구현을 위해
- user 조회 (DB에 있는 data인지 확인)
- 페이퍼 paperId, paperTitle 조회
- 페이퍼에 있는 message 조회
- 조회된 user == paper의 OwnerUser일 경우 message readyn 수정
- message의 reaction 조회
- 페이퍼에 있는 sticker 조회
위의 메서드들을 각각 구현하였다.
각 메서드에서는 user 확인, (필요시) paper 검증, (필요시) message 검증을 거치고 있었다.
예를 들자면 message 조회의 경우 message는 paper의 자식 entity이므로 message 조회 전 paper가 있는지 없는지를 확인하기 위해 paper를 조회하는 쿼리가 한 줄 들어가 있었다.
이러한 코드로 인해 각 메서드마다 중복되는 쿼리가 포함되고 있었고 이렇게 중복된 쿼리로 인해 방금 막 생성되어 아무것도 없는 페이퍼를 조회해도 쿼리가 10개씩 나가고 있었다.
이론상 빈 페이퍼라면 user, paper, message, reaction, sticker 조회에 각 1번씩이면 충분했다.
메서드 하나씩만을 본다면 기존에 구현해둔 방식이 맞다고 볼 수 있다.
하지만, 이 메서드들은 Paper Service에서만 사용하고, 다른 곳에서는 사용하지 않는 로직이고, 오로지 Paper API의 페이퍼 상세보기 기능에만 필요했다.
그래서 불필요하게 중복되는 쿼리를 줄이기 위해 리팩토링하기로 했다.
이미 검증이 끝난 Entity들을 필요한 메서드에 전달하게 수정하였고, 이 Entity들은 PaperService단에서만 사용하게 하였다.
PaperController에 전달하지 않으므로 Entity가 화면단에 노출되는 위험도 없었다.
- user에 대한 확인을 하면서 user Entity를 다른 메서드에서 사용
- paperId, paperTitle을 조회하면서 paper에 대한 검증이 끝나고, 이 paper Entity를 다른 메서드에서 사용
- message 조회에 위의 user Entity와 paper Entity를 사용하여 조회
- reaction 조회에 위의 Entity들을 사용
- sticker 조회에 위의 Entity들을 사용
이렇게 해서 페이퍼 상세 보기 API를 위해 사용되던 기존의 쿼리 10개를 5개로 줄일 수 있었다.
빠르게 기능 구현을 위해 구현했었다. 처음부터 완벽하게 짜려고 이리저리 궁리하다 개발이 늦어지고 서비스가 늦어질 것 같아 내린 판단이다.
클린 코드 관점에서 생각해보면 메서드는 하나의 역할만 하는 것이 좋다. 기존의 로직은 메서드가 최소 두 가지의 일을 하고 있었으니 그리 좋지는 않다.
하지만 리팩토링을 통해 메서드가 하나의 일만 할 수 있게 하였고 결과도 나쁘지 않았다.
