[Refactor] Service 파일의 부담 줄이기

Gitakkkk·2024년 1월 28일

프로젝트 초기에는 기능 구현에 급급하다 보니 MVC 패턴 등을 알고만 있었지, 각각 어떤 역할을 담당해야 하는지, 어떻게 구성하는 것이 추후 유지 보수 및 고도화 작업을 할 때 더 용이할지 생각하며 작업을 하기 어려웠다.
(사실 작업을 하기 어려웠단 건 변명이고, 몰랐다고 하는 게 더 맞는 거 같다)

API 기능 개발이 끝나고, 현재는 UI 개선 작업을 진행 중이기 때문에 여유가 조금 생겨 MVC 패턴과 테스트 코드 등을 작성하여 추후 유지 보수 및 고도화 작업을 용이하게 할 예정이다.

현재 가지고 있는 문제점은 Module, Controller, Service, Repository 등으로 파일들이 나누어져 있긴 했지만 실질적으로는 Service 파일에서 데이터베이스 작업과 네트워크 통신 작업 등을 모두 처리한다는 것이었다.

위 문제점은 파악하고 있었지만, '서비스 파일의 부담이 너무 큰 거 같다' 정도로만 생각했기 때문에 어떻게 리팩토링을 해야 하는지는 잘 몰랐고, 구글링을 통해 알게 되었다.
(Velog, Medium, 각 기업들의 Tech blog 등을 틈날 때마다 읽은 보람이 있다)

서비스 파일의 부담을 줄이기 위해 네트워크 관련 코드는 컨트롤러에서 처리하고, 서비스 파일에서는 비즈니스 로직만 처리하게끔 구성하려고 했다.
서비스 파일 내 코드 중 catch error 발생 시 로깅과 슬랙 알림 발송 등을 하는 기능이 있는데 이 부분을 모두 컨트롤러로 옮겼다.


위와 같이 코드를 작성한 후 포스트맨으로 테스트를 하였다.
정상 요청 시 콘솔에는 result가 찍히는데 응답값이 넘어오지 않아 아래에 있는 catch error의 응답과 같은 형태로 변경해주었다.

return res.status(200).json({...})


위와 같이 리팩토링하여 서비스 파일들의 부담이 조금은 줄어든 거 같아 내심 뿌듯했다.

이번 프로젝트에 대해 리팩토링과 고도화 작업 등이 계속해서 이루어질 거라고 생각된다.
그럴 때마다 매번 포스트맨으로 테스트할 수는 없으니 테스트코드를 먼저 작성하고 서비스 파일 내 데이터베이스 관련 작업들은 레포지토리 파일로 옮길 예정이다.

기능은 돌아가게 만들었으니 확장성과 유지보수성, 가독성 등을 챙겨봐야겠다.
위 작업이 마무리되면 데이터베이스 튜닝과 VPC 구성 등을 해볼 예정이다.
(해보고 싶은게 참 많다)

0개의 댓글