[엘리스 SW 트랙] 2차 프로젝트 : 오피스아워 코멘트 14주차 - 1

• commit 등 관리할 때, 백엔드/프론트 엔드 별로 나눠서 레포를 관리하면 너무 번거로워져서 한 레포로 작업하려고 합니다. husky로 보려고 해도 애매한데요. 이렇게 적용하는게 맞을까요? 아니면 더 좋은 방법이 있을까요?
  • 현재 구성한 구조는 client/ server에서 동일한 패키지를 사용한다고 했을 때, 각 폴더마다 중복되는 패키지가 설치가 될 겁니다.
  • 저장소를 하나로 두고 구성한다는 것은 mono repo로 구성한다는 것이겠죠? mono repo를 구성한다는 것은 한 repogitory 안에서 client/server 를 구성하는 것이 아닙니다. yarn 또는 npm workspace 를 써서 구성하는 기술이 있습니다. 어떤 workspace를 쓰던 상관은 없지만 "왜 사용했는가"가 매우 중요합니다.
    
    • mono repo workspace
      • lerna
      • turborepo
  • workspace를 사용한다면 루트 경로에 중복된 패키지들을 관리할 수 있습니다. 그리고 npm parallel을 사용하지 않아도 되겠죠
  • mono repo 를 사용한다면 공통된 라이브러리 혹은 모듈들만 따로 관리하는데, 이럴 경우는 디렉터리를 구성하는 전략도 엄청 중요합니다. 대부분 백/프론트로 나누기 보다는 apps와 libraries 로 나눕니다. libraries에는 백/프론트에서 공용으로 쓰는 라이브러리들이 들어갑니다. 예를 들자면 날짜에 관련된 라이브러리들 같은 게 있겠죠? 이런 것들이 libraries들을 넣어놓는 겁니다.
  • mono repo의 단점도 있습니다. 만약 공통된 라이브러리 같은 걸 변경해야 한다면, 라이브러리 변경되기 때문에 프론트, 백엔트 코드 모두가 변경 될 수도 있습니다. 이런 단점을 어떻게 극복할까요? 이런것들은 코드 구성 전략을 잘 짜야 합니다 ㅎㅎ 추상화를 아주 잘 해놓는 거죠.
  • mono repo가 조금 러닝커브가 있는 편입니다. 시간 여유가 있다면 사용하는 걸 추천 드리지만, 시간적으로 여유가 되지 않는다다면 팀원분들끼리 충분한 논의 후에 선택하는 것도 나쁘지 않습니다
• 저희는 단순히 하나의 레포를 사용해서 커밋할때 레포를 왔다갔다 하지 않고 한번에 작업하는 것 때문에 이렇게 구성했는데요. mono repo는 나중에 고도화 할때 적용하는 것은 어떨지 궁금합니다
  • 그렇게 해도 상관은 없습니다. 다만 그렇게 된다면 모든 코드가 수정되어야 하는 불상사가 발생할 수도 있습니다. 왜냐하면 이미 모든 코드가 특정 라이브러리에 강력하게 의존되어서 작성 될 거기 때문이죠. 개인적으로 mono repo에 대한 무서움이 있다면, 나중에 변환하는 것도 나쁘지 않다고 봅니다.
  • 또, 롤백 할 때를 고민해야합니다. 커밋에 백,프론트 커밋이 포함되겠죠? 예를 들어 백엔트 쪽 이슈가 있어서 롤백을 해야하는데, 롤백할 커밋에 프론트 코드도 포함이 되어있을 수도 있죠. 이럴때 어떻게 해야할 지, 고민해야합니다.
• 저희 팀원 모두 다 프론트 엔드 쪽을 원하기도 하고, 1차 프로젝트 때 백엔드를 해보신 분들이 많기도 해서 팀원 전체 full-stack 포지션으로 진행하려고 합니다.
  • full stack을 하게 된다면 git flow를 잘 제어해야합니다. 개개인에게 merge 권한을 위임하면 숙련자가 아닐 경우 무수한 충돌이 일어날 수 있습니다.
  • 그러면 어떻게 하는게 좋을까요? 깃 브랜치 전략도 한번 고민해보셔야합니다. git flow 를 할지, github flow를 할지.. 이런 것들도 고민을 해보시죠. 추천하는 방법 중 하나는 팀원 중 한분 또는 두 분이 리뷰어 포지션을 맡아서 합치는 방법입니다. 브랜치 마다 protection도 걸고, 리뷰어만 머지를 할 수 있도록 하는거죠.
  • git flow 는 속도가 조금 느리다는 단점이 있습니다. commit 양도 엄청 커질거고.. 풀스택을 하신다면 github flow가 좀 더 좋아 보입니다. ㅎㅎ
• 혹시 머지 전략 같은 것은 mono repo를 썼을 때 좀 더 엄격하게 써야한다거나 이런게 있을까요? 아니면 multi repo를 사용해도 똑같이 엄격하게 가져가야하는지 궁금합니다.
  • multi repo던지, mono repo던지 모두 엄격하게 관리합니다
• 이미지 위에 위치정보를 알려주는 기능을 넣고 싶은데, 어려울까요?
  • 기능보다는 먼저 위치 정보를 어떻게 관리할 것인지를 고려해야합니다. 
  • 위치 정보는 행정동/법정동 두가지로 나뉘어서 관리 되는데요. 어떤 걸 선택하냐에 따라 관리하는 체계가 아예 달라질 겁니다. 백엔드에서는 위치를 관리하는 체계를 잡고, 유저가 입력한 데이터를 백엔드에서 어떻게 저장할건지 고민해야합니다. 주소값을 저장할건지.. 위/경도값을 저장할 건지 등등 정책들을 다 정해야합니다.
  • 위/경도 값이 동일한 경우가 있을텐데요. 예를 들면 현대백화점 안의 스파게티 집과, 꽃집은 동일할텐데.. 이런것들을 다 고려해야하는데요. 이게 난이도가 생각보다 높을 것이라서, 요 기능 개발은 제일 후순위로 하는 걸 추천드립니다 

 

#엘리스트랙 #엘리스트랙후기 #리액트네이티브강좌 #온라인코딩부트캠프 #온라인코딩학원 #프론트엔드학원 #개발자국비지원 #개발자부트캠프 #국비지원부트캠프 #프론트엔드국비지원 #React #Styledcomponent #React Router Dom #Redux #Typescript #Javascript