TypeORM 코드 리팩토링

·2022년 6월 5일
0

팀 프로젝트

목록 보기
26/34

오늘은 코드리팩토링을 하는 날이다.

근데 정말 마음처럼 되질 않아서 고민중이다(....)

반복되는 createQueryBuilder, 한개만 쓰면 안될까요?

관계로 묶여있는 테이블이 Board라서 어지간해서는 모든 쿼리문을 raw쿼리로 작성을 하고 있다.
그러다보니, 자연스럽게 거의 동일한 코드임에도 불구하고 반복되는 것이 목격되었고

그것을 한번 줄여봐야겠다라는 생각이 들었다.

조건문을 제외하면 사실상 한개로 합쳐도 무관한 코드들

class니까 그럼 this로 해결할 수 있지 않나?

이런식으로 반복되는 쿼리빌더를 클래스 최상단에 담아서 this.qb로 끌어와서 사용을 해보려고 했는데

실제로 이런식으로 this.qb를 여러개를 쌓아서 사용하다보니,
qb를 선언한 위치부터 직접적으로 this.qb를 사용하는 사이에
존재하는 모든 this.qb를 다 끌어와서 사용이 되는 것으로 확인이 됐다.

이게 내가 객체지향에 대한 지식이 모자라서 발생한 것이라 생각은 하고 있는데...
단일적으로만 불러와서 사용하면 해결이 될 것 같은데 왜 저런 이유가 발생했는지 고민을 해보았다.

생각을 해보니 배열이나 객체같은 경우에는 저런식으로 사용하면 안된다.

createQueryBuilder가 어떤 형태로 구성이 되어있는지 알 수는 없지만,

위의 쿼리문이 쌓이는 것으로 보아서는 배열 혹은 객체처럼 메모리에 저장이 되는 식으로 보이기에
얕은 복사나 깊은 복사를 이용하면 되지 않을까! 라고 생각을 해서 한번 사용해봤는데

어림없지!

안된다(....)

그래서 그냥 쿼리빌더를 재사용하려는 욕심은 버리고, 로직 자체를 수정한다거나
여러개로 분리되어있는 로직을 한개로 합쳐보기로 했다..ㅠ_ㅠ

api 개선하기

그래서 그냥 여러개로 흩어진 api를 한개로 합치는 작업을 진행하기로 했다.

여기서 잠깐!! API를 만드는 것은 백엔드지만, 사용하는 사람은 프론트엔드라는 것을 잊지 말아야 한다

그래서 변경사항이 생길 예정이라면, 미리 이야기를 해줘야한다.
왜냐하면 팀프로젝트 진행 중 오전 시간에 고쳐달라는 요청을 받았고, 그것을 늦은 밤이 되서야 수정이 된 날이 있었는데

프론트쪽에서 이 api가 갑자기 사용이 안된다고 이야기를 해서 보니, 수정사항이 적용되어있는 api였고
그 부분에 대한 전달이 이루어지지 않아서 발생한 문제였다.

그래서 이번에는 제대로 먼저 이야기를 하고 api 수정 작업을 하고 있다.

3개로 나눠진 api를 한개로 합치기

현재는 유저의 정보를 조회할 경우 3가지를 활용하여 값을 가져오고 있는데
이 부분이 굳이 3개로 나눠놓을 필요가 없는 것 같아서 한개로 합치는 작업이 진행되었다.

3개 중 아무거나 받을 수 있도록 만들어놨다.

아무것도 못받을 경우 예외처리, 값이 없을 경우 예외처리

물론 위의 코드도 솔직히 마음에 들진 않는다.

내 생각에는 if(userEmail || userId || userNickname) 이런식으로 해서
존재하는 것만 리턴을 하고 전부 다 없으면 예외처리를 해줄 수 있을 것 같은데.

배열이 아닌 상태의 값에서 존재하는 것만 빼서 리턴을 해야하는 것을 어떻게 해야할지 몰라서 현재 고민을 좀 하고 있다(...)
아마 코드에 대한 리팩토링은 계속 이어질 것이고, 오늘은 본가를 온 날이라서 이정도로 마무리를 할까 한다.

profile
물류 서비스 Backend Software Developer

0개의 댓글