출근 21일차

뮤·2022년 9월 22일

회사이야기

목록 보기

21/118

불태운 오늘 하루..

끝없는 미팅

이걸 갈아엎는건 말이 안된다는 생각에 오전부터 CTO님한테 Help 요청했다

나 : 기존 프로세스를 몬쓰는데요?
CTO : 그럼 새로 짤 수 있으면 짜는게 맞긴 한데....
CTO : 이럼 안되는데 제가 확인해볼게요

~시간이 좀 흐름~

CTO : 일단 하나는 해결이 됐어요
나 : 그나마 한개가 줄었네요 일단 알겠습니다

기획팀장님 살려주세요

나 : 이렇게 진행되면..... 안돼요
기획팀장 : 기존 프로세스에 최대한 맞춰서 개발하고 있어봐요 제가 운영팀이랑 이야기해서 어떻게든 해볼테니
나 : 일단...알겠습니다 소식 들리면 알려주세요

팀원님 살려주세요

나 : 이거이거 이렇게 가는게 맞나요?
팀원 : ㄴㄴ 이거 이렇게 저렇게 가야해요
나 :
팀원 : 이건 데이터베이스를 완전 훑어봐야 알 수 있는거라... 한 2주만 더 빠르게 왔어도 크게 차이났을 것 같은데
금방 해결이 안될 것 같은 일이 있으면 아무때나 물어보세요 제가 알려드릴게요

리더님 이거 이렇게 해도 될까요???

리더 : 완전 분리해놓으면 좋죠 이렇게 쭉 가도 됩니다
나 : 와!
리더 : 근데 여기 메소드 이름이 쫌
나 : ㅠㅠ

주간회고부터 미팅이란 미팅은 계속 요청드려가지고 최대한 바로 잡을 수 있는 부분은 일단 잡아놨다.

왜냐하면 프로세스가 변경되면, 회사의 모든 구성원이 영향을 받기 때문에....
일의 복잡도가 좀 미친듯이 많이 올라가는데(...)

개발의 복잡도 뿐만 아니라 모든 것에 부하가 걸리다보니 최대한 조정하려고 노력을 했던 하루였던 것 같다.

오전 내내 미팅만 했던 것 같기도 하고(....)

구조부터 짜자!

도메인....주도개발...!!!!!!!

도메인의 메인 비즈니스 피쳐를 개발하고 있기 때문에 흔히 말하는 도메인주도개발을 할 수 있다는 생각이 들었다.

지금 사용하고 있는 백엔드 서버는 NestJS, ORM은 TypeORM인 상태인데

최소 기능단위로 모조리 다 쪼개버리고, 이벤트를 붙여나가는 식으로 구현을 하면 의존성도 최대한 줄 것 같고....
조만간 TypeORM 버전업도 해야하는데 그런 문제를 많이 해결할 수 있을 것 같았다.

그래서 다쪼갬

진짜 가능하면 최대한 다(...)

어느정도 기준은 잡아놨다.

ORM을 사용하는 것이 아니라 무.조.건 쿼리빌더로 모조리 전부 다 짠다.
- 버전업을 할 경우 ORM은 형식이 다 달라지기에, 구현체가 변경이 거의 없는 쿼리빌더로 짜는게 맞다고 생각했다.
큰 틀의 기능이 있을 경우 쪼갤 수 있는 단위로 최대한 나눠서 메소드를 분리한다.
- 이유는 단순한데, 처음부터 끝까지 분기를 주는게 아니라 특정 포인트에서만 분기를 줄 수 있게끔 확장성을 고려했다.
역할에 맞게 컨트롤러, 서비스 파일도 분리한다.
- 이 부분은 기존의 형식과 비슷한 부분이 있다. 접근 권한이 다르기 때문에 유지하는 것이 맞다고 생각했다.
dto 정의 파일, repository 정의 파일도 서비스별로 다 분리한다.
- repository 파일의 메소드는 무조건 SQL에 관한 로직만 들어가야한다.
  - 물론 index.ts 파일에 한곳으로 다 모아서 import 할 수 있게 해야한다.