배경
몇달간의 프로젝트를 진행 후에,
서로 다른 코드 스타일, 모듈들의 역할에 대해 상이하게 생각한 부분 등의 문제점들이 발견되었고,
2주 간의 리팩토링을 진행하는 시간을 가지게 되었다.
다음 글에서는 리팩토링을 진행 하면서, '공통 코드를 줄이는 것' 에 대한 경험을 공유 하려 한다.
과정
👉 리팩토링 전 프로젝트 구조
- router/ : api 및 service/ return 값에 따른 error handling 수행
- service/ : 비즈니스 로직 작성 및 결과에 따른 return 성공 여부 반환
- 즉 router에서 service 로직을 호출하여 수행하다가, 성공 여부를 router로 반환해, 핸들링 된 에러로 유저에게 응답하는 방식
- 초기에 이렇게 작성했던 이유는 api 별로 error 흐름을 파악하기 쉽다.
👉 변경 전 코드
# router.py
if not ServiceA.create_obj(): # <- 비즈니스 로직 성공, 실패 여부
raise CustomErrorHandling(code="99", msg="로직 실패~")
# service.py
def create_obj():
# 비즈니스 로직 성공시
if success:
return True
return Fasle
👉 문제점
위와 같은 코드에서는 각 API 마다 공통된 에러 체크를 수행할 경우, (api 1 과, api 2 모두 99에 대한 에러 핸들링이 필요시) 각 API의 router.py 마다, raise 문이 중복 선언 되게 된다.
따라서 이를 Service Layer에 구현하게 되면 코드 중복을 줄일 수 있다.
👉 변경 후 코드
# router.py
ServiceA.create_obj()
# service.py
def create_obj():
# 비즈니스 로직 실패시 error 발생
if not success:
raise CustomErrorHandling(code="999", msg="로직 실패~")
결론
- 리팩 전 router.py 에서 에러 핸들링을 처리하였었음 (서비스 이해 직관성 목적)
- api가 많아지면서 router.py 들에 에러 핸들링 코드가 중복되어 작성됨
- 에러 핸들링을 service layer로 옮겨, 코드 중복을 줄임
'프로젝트 경험기 > 리팩토링 경험기' 카테고리의 다른 글
[리팩토링] (3) early-return 적용하기 (0) | 2024.12.20 |
---|---|
[리팩토링] 가독성 높이기 - 함수명 개선 (0) | 2023.08.05 |