최근 해당 voice 프로젝트를 개인적으로 리팩토링하려고 생각중이다. 물론 같이 프로젝트를 진행했던 팀원들에게 피해가 가지 않게 다른 레포에서 진행할 예정이다.
근데 사실 '리팩토링을 이렇게 할거다!' 라는 글을 쓰려는건 아니고 지금보니 코드가 너무 개판이어서 반성문쓰는거다.
폴더구조
위 사진은 예전에 진행했던 프로젝트의 폴더 구조이다.
router폴더부터 controller, service로 분리했고 DB에 관련된 정보는 model폴더에 넣었었다.
잘못한 점
나름대로 비즈니스 로직을 controller가 아닌 service에 넣었던 프로젝트였다.
하지만 지금 살펴보면 뜯어고칠게 많은데 그 중 가장 마음에 걸리는 것은 계층대로 코드를 나눠놓고 계층간의 의존성을 분리시키지 않은 것이다. (의존성에 대한 글) (그리고 현재 모든 코드가 함수로 되어있는데 class로 바꿀 예정이다.)
controller와 service간의 강한 결합
controller를 살펴보면 비즈니스 로직이 위치한 service를 전역으로 받아와 함수 스코프내에서 바로 사용했었다. class형태로 의존성 주입 프레임워크(typeDi) 활용해서 진행해봐야 겠다.
service와 model(db)간의 강한 결합
위와 같은 문제였다.
테스트코드의 부재
프로젝트를 진행할 때 기능의 추가나 수정이 있을 때 배포 이후에 제대로 동작하지 않아 다시 수정 후 배포 수정 후 배포를 반복하는 문제가 있었다. 물론 이미 로직이 작성되어있어서 TDD는 아니겠지만, 간단한 테스트들이라도 작성해볼 예정이다.