[데브코스] 8주차 회고

회고: ⭐⭐⭐⭐⭐

꾸준히 성실하진 않았지만 확실하게 불태우고 할 건 다해낸 한 주 

 

👍Liked

투두리스트 개발을 완료했다. 설계 + 폴더 구조 고민, 프리즈마 알아보기 등에 시간을 너무 많이 쏟아서(사실 미룬거임) 실 개발 시간은 4일 정도 되는 것 같다.

 

이 와중에 할아버지 제사 사유로 금요일, 일요일 각각 5시간씩 이동 시간이 있어서 시간 아끼고자 이틀 밤샘을 선택했고 나 홀로 해커톤을 한 셈이 됐다. 너무 힘든데 내가 미뤘고 그냥 메가업보업보빔 맞은거라 할 말이 없다...미룬건 잘못했지만 훌륭하게 해치웠으니 잘한 일이라고 생각하기로 했음

 

https://github.com/Monixc/devcoure_todolist

GitHub - Monixc/devcoure_todolist

어떤 생각으로 코드를 짰는지, 개발 중 어떤 고민을 했는지 간략하게 정리해본다.

 

폴더 구조에 대한 고민

계층 기반 구조를 사용할지, 기능 중심 구조를 사용할 지 폴더 구조에 대해 굉장히 많은 고민을 했다. 

백엔드 스택은 데브코스 커리큘럼에 맞게 express를 사용하려고 하는데, express의 "간단함" 특성을 살리기 위해서는 계층 기반으로 최대한 간단하게 구조를 짜는게 맞지 않나 싶다가도, 좀 더 명확하게 파악 가능하도록 기능 기반으로 분리하는게 더 좋지 않을까 생각이 들어 갈팡질팡 하는중

 

관련된 글들도 굉장히 많이 읽어보고, 팀원들과 상의를 해본 후 멘토님께 질문도 해보았다. 

 

내 의견: 

기능별로 코드를 분리하여 관리하면 프로젝트를 파악하기 더 용이하고, 나중에 기능을 추가하거나 유지보수하는데에도 유리하지 않을까. 구조가 복잡해지긴 하겠지만, 개발 단계에서도 기능별로 작업하는게 더 편리할 것 같다.

 

팀원 의견:

라우터를 사용해 API를 구현한다면 컨트롤러, 서비스, 미들웨어 등 관심사를 분리하는게 유지보수에 유리할 것 같다. 관심사의 기준이 중요하다고 생각함

계층 기반은 구조적으로는 직관적이지만 기능에 대한 부분이 src(root) 단위에서 흩어져서 오히려 유지보수성이 떨어질 수 있다고도 느낌. feature-base는 좀 더 폴더구조가 복잡해지지만 기능에 대한 관심사가 분리되는 느낌이기도 함

 

멘토님:

작은 단위에서는 layered도 충분히 좋다. 그리고 feature-based라는 말보다는 domain, model based라는게 더 적합한 것 같다.

모델은 db 한 개의 테이블을 뜻하고, feature-based(model based 아무튼)을 쓸 땐 하나 테이블에 대한 분리보다는 모델의 군집 개념인 Aggregate(어그리게이트) 단위로, 연관 개념을 통합하여 폴더를 구성하는게 더 효율적이다.

사실 어떤 구조를 쓰든 본질은 폴더 정리이다. 사람마다 다르고, 또 회사마다 다른게 폴더 구조이니 정답은 없다. 각자의 규칙이 있을 뿐이고, 그냥 왜 이렇게 분리하는지 명확한 근거만 있으면 될 듯. 그래도 굳이 정답을 찾자면 대기업 블로그 참고

 

고민이 컸는데, 멘토님 의견을 들으니 이렇게까지 크게 고민할 필요는 없다는 생각이 들었고, 그냥 내가 좀 더 마음에 드는 방식인 feature-based 방식으로 폴더 구조를 정리해보았다. 프론트를 만들때도 페이지 하위 종속 컴포넌트, 유틸 등을 넣는 구조를 자주 쓰기도 해서 더 익숙한 방식이기도 하고.

 

개발

백엔드를 개발할 때 가장 많이 신경 쓴 건 에러처리 부분이었던 것 같다. 이렇게 신경쓴 것 치고는 결과가 썩 만족스럽지 못하지만, 에러메시지 세분화 및 상수 처리하여 최대한 깔끔하게 작성하려고 노력했음

 

 

👎Lacked

태도적인 부분 말고 프로젝트에 대한 아쉬운 점을 좀 정리해보려고 함

• 에러 반환 시 상태코드를 포함하지 않는다. 에러메시지만 반환하는데, 상태코드 + 에러메시지 동시 반환하도록 처리해야 하지 않았나 아쉬움이 남음
• ESM과 CommonJS는 아직도 이해가 안된다. ESM을 사용하는데 오류가 너무 많이 나서, CommonJS에서 import/export 허용하도록 설정 적용하여 개발하였다. 오류는 탈출했지만, 각 모듈 시스템에 대한 충분한 이해 없이 해결에만 너무 급급했던 것 같아서 아쉬움
• any를 은근 많이 사용했다. 타입스크립트 사용 면에서 많이 부족함이 있었음
• 설계의 미흡. api 설계를 잘 했다고 생각했는데, 막상 프론트 작업을 하다 보니 부족한 API가 너무 많았다. 프론트 작업을 하면서 실시간으로 API를 추가 개발했는데, 최대한 많은 유저 플로우를 고려해서 api 설계를 해야겠다고 느낌
• 시간이 좀 남았으면 테스트 코드를 작성해보았을텐데 하는 아쉬움

 

🥸Learned

• 백날 Service며 controller며 읽어봐도 그래서 뭔 차이지 아리송한 느낌이 있었는데, 이번 백엔드 개발에서 service, controller를 분리해서 써보면서 확실히 구조와 코드 흐름을 파악할 수 있게 된 것 같다.
• Prisma를 사용해보았다. SQL로만 처리하는 것보다 훨씬 간편하게 코드를 작성할 수 있었음. 

 

🏹Longed for

급한 불 다 껐으니 블로그 정리하기