개요
기존의 코드가 너무 복잡했다.
왜냐하면 NestJS를 사용하기위해 30분짜리 사용법만 익히고 나머지는 사용하면서 익혀보자는 마음에 들어갔다. 그렇게 들어갔을 때 문제를 만날때마다 찾아보면서 작업할 필요가 있었는데 그 당시엔 일단 동작하게 만들자는 마음가짐으로 똑같은 구성의 중복되는 코드를 이곳저곳 붙여 사용하게 되었다.
그렇게 사용하다보니 한 곳을 수정했는데 다른 곳에서 같은 로직이 발견되고 하다보니 어지러워졌다.
따라서 어영부영 넘어간 부분을 조금 수정하고자 리팩토링을 하기로 했다.
DTO
"Data Transfer Object"의 약자이며, 일반적으로 데이터베이스나 서비스 등에서 데이터를 전송하기 위해 사용되는 객체이다.
request body를 타입스크립트로 사용하면서 어떻게 정의하면 될지몰라 그냥 ignore로 무시해버렸다. 하지만 나중에 함수의 인자로 넘겨줄 때 타입을 지정해주지 못해 에러가 계속 나오고 그걸 또 해결한다고 이상하게 작성되는 코드를 보면 어영부영 넘어가는 건 안하느니만 못하다고 생각해 최대한 알고 지정해주고자 자료를 찾아봤다.
DTO를 작성해줌으로써 데이터를 검증할 수 있다는 걸 알았고 Nest에서 제공하는 여러 파이프들이 있다는 것도 알게 되었다. 나중에 통신하면서 자료가 필요할 때 더 찾아볼 예정이다
서비스 분리
각 데이터베이스 테이블을 서비스마다 직접 호출해서 사용하다보니 답이 없었다. 코드가 너무 길어지고 계속 얘기했던 수정할 곳을 생각해내야하다보니 작업이 길어지고 만지기 어렵다는 생각을 계속했다. 따라서 리포지토리를 서비스로 분리해서 훨씬 관리하기 쉽게 수정했다.
조금 더 찾아보니 의존성 주입이라는 개념을 알게됐고 객체간 결합도를 낮추고 코드 재사용성을 높인다고 한다. 따라서 추상화를 적절히 하는게 중요하다고 생각했고 CRUD에 따라 분류하는게 나을 것 같다고 생각했다.
회고
이번에 리팩토링하면서 스스로 이상한 짓을 했다는 것을 많이 느꼈다.
어영부영 넘어가려했던 이유도 당시 개발하던 때를 생각해보면 처음 사용해보는 프레임워크에 어려웠던 구조와 시간적 부담 때문에 최대한 되는 구조들로 길어지더라도 복붙해나갔다. 물론 안좋은 습관이지만 내가 익히는 방법 중 하나라고 생각했고 결국 잘못된게 커져서 약 한두달간 많은걸 해결했어야 됐다고 생각한다.
이제부터는 구조를 익히고 작은 구조로 잘라서 생각해보려고 한다. 이게 안되면 더 작게 찾아보고 하면서 좁혀나가다보면 해결될거라는 걸 최근에서야 느끼고 있다. 또 그러기 위한 많은 자료들과 좋은 검색봇도 있다. 그래서 이제부터라도 잘하면 된다고 생각하고 마무리했다.
'TIL > 트러블슈팅' 카테고리의 다른 글
KPT 회고로 프로젝트 실패 회고하기 (0) | 2023.04.01 |
---|---|
클라이언트와 서버 포트로 인해 발생했던 보안 그룹 문제 (0) | 2023.03.27 |
subdomain 설정이 안됐던 이슈 (0) | 2023.03.18 |
프론트 백엔드간 배포시 쿠키 저장이 안됐던 이슈 (0) | 2023.03.16 |
쿠키 저장 이슈를 통해 정리한 쿠키 옵션과 HTTPS로 리디렉션 (0) | 2023.03.14 |