RooTrip 재 리팩토링

영슈·2023년 9월 18일

루트트립 프로젝트

목록 보기

4/6

모든 학점을 다 채우고 알바 휴식으로 인한 시간적 여유
우선 , RooTrip 은 이미 Typestack 에서 Nest.js 로 리팩토링을 했다.
그럼에도 , 똑같은 코드로 재 리팩토링 하는 이유는 적당한 크기의 볼륨과 다양한 기능이 있어서
새로운 기술 과 코드 스타일을 단순 사용이 아니라 체화 할 수 있을 거 같기 때문이다.
그러면 , 아래에 기존 코드에서 발견되는 문제들을 말하겠다.

기존 Clone 에서는 Git Branch 를 main 에서만 push 를 했다.
물론 , 1인 작성이고 이미 다 생각한 요구사항에서 코드만 바꾼 것 이지만 ,
이번 원티드 인턴십을 하며 , 소통 과 협업을 할 때는 브랜치 전략과 PR 이 필수란 것을 깨달았다.
=> 따라서 , 이번 코드는 각 큰 로직마다 feature 로 branch 를 분리하고 , develop branch 에서 개발후
main 에 develop 을 할 예정이다. ( main 의 코드는 항시 구동할 예정 )

그 당시 , nest 를 공부한지 얼마 안되서 바로 수정하여 각 provider 들이 의미하는게 뭔지 모른채 무턱대고 Folder 만 많이 만들었다.

( 매우 심각한 폴더 구조... )
해당 당시에는 Spring 의 구조인 MVC 적 Layered Pattern 이 좋다고 생각했는데 , nest 에 대해서 좀 더 공부하고 알게 되니까 nest 는 Layered 에 다소 부적절 하다고도 생각이 됐었다. 그 이유로 nest 는 매우 많은 middleware 와 provider 들을 세분화 해서 구성을 했다. 이러한 요소들을 전부 폴더로 구분하기에는 다소 난잡했다.
이렇게 하니 , controller 와 service 들이 많아짐과 동시에 , 각 로직에 매핑된 요소들을 찾는데도 시간이 오래 걸리고 개인적인 생각으로 매우 지저분 해 보였다.
=> 이에 따라 , nestjs 에서 추천하는 Domain 적 Folder Pattern 으로 만들어 보려고 한다.

Module 과 Controller 들을 설계할 때 , 크게크게 엔드포인트 단위로만 기능을 설계해서 내부 실제 실행되는 로직 단위를 깊게 생각하지 않았었다.
이렇게 , Email 을 담당하는 Controller 는 User 와 Profile 의 Repostiory 도 가지고 , Auth Service , Config Service 를 가지는 매우 비효율적인 Module 구조가 나왔다.
이런 모듈에 따라 , Controller - Service 들도 SRP 에 어긋나는 코드가 나왔다.
=> 모듈을 더욱 짧게 세분화 하더라도 SRP 를 준수하는 Module 설계

해당 코드를 작성할 때 연구실 내 있는 서버에서 작업을 하였다. 따라서 , 프론트와 통신을 하거나 구현 할 때
매우 편리하고 문제점 없이 작성을 했다.
하지만 , 다른 컴퓨터에서 작성을 하거나 , AWS 에 올려서 배포 하려고 할 때 어디서 부터 오류가 나는지 모르겠어서 포기를 했다.
=> 이에 따라 , 처음부터 docker 구동이 되는지 확인하고 aws 에 EKS 로 올려서 동작을 하는지 계속 확인을 할 예정이다.
=> 추가로 , main 에 있는 Code 를 Github Action 을 작성해 CI / CD 를 자동화 하여 항시 구동 시켜보고 싶다.

현재 비즈니스 로직 내 , 발생하는 에러는 interface 단위로 생성 후 검사하고 있었다.
이전 글에서 설명했듯이 interface 로 할 시 , class 내 추가적인 로직이나 로깅 및 레디스 처리등 부가작업 하기가 매우 힘들었다.
현재 로깅은 그냥 전체 Request 에서 End Point 와 언제 기능이 발생됐는지만 측정하는 매우 간단한 로깅이였다. 에러가 발생하는 경우나 , 중요한 작업을 할 때 별도 로깅 처리 기능이 없었다.
=> 에러 및 별도 메소드에서만 분기 처리 하는 기능 추가 및 모든 Error 를 방지하는 ExceptionFilter 구현 예정

해당 코드들은 전부 직접 일일이 프론트와 연동하고 , 작동 하는지 확인하면서 작성을 했다.
이러한 점이 사실 현엽이나 일반적인 개발 상황에서 전혀 없는 환경인걸 깨달았다.
=> 이번에는 Unit 단위의 Testing 은 준수해서 , Mocking 을 사용해서 우선 Testing 을 구현해보고 작성을 준수해볼 예정이다. ( 차차, 조정 : 코드를 먼저 작성후 , Testing 을 통과후 Push 방법도 여부 존재 )
=> 기존에는 매번 단순한 데이터로 결과만 확인했는데 대규모 테스팅 데이터 삽입 스크립트를 작성하여 ,
서버 부하 및 DB 부하 까지 테스트를 해볼 예정이다.

기존 typescript 로 작성할 때 , typestack 과 typeorm 을 사용하였다.
그래서 , nest 로 refactoring 할때도 매우 문제점 없이 바로바로 작성 할 수 있었다.
=> 따라서 , 이번에는 prisma 를 접목하여 코드를 작성해볼 예정이다.
Email 전송도 현재는 async - await 구문으로 전송을 기다리고 확인 후 전송
=> Kafka 를 공부해서 비동기로 처리 예정

이러한 점에서 새롭게 리팩토링을 진행해볼 예정이다.