WEEK 1 멘토링

README

• 프로젝트 취지
• 모임의 룰
• 기타 궁금한 점을 파악할 수 있게…
• wiki 참고하라고 링크 다는게

스택

• Vite 왜 사용했는지? : Go로 만들어져서 병렬처리 빌드로 해서 사용해보니 빠르다 + CI 때 빌드 빠르게 하려고
  • Vite 현업에서 사용하셨을 때 : 내부 직원용 CMS 만듬. 서버측 SSR이 딱히 필요는 X
  • Vite 를 쓰지만 Vite를 이용한 SSR은 사용하지 않음
• BE : Nest

기획

• 코드리뷰 SNS 플랫폼임
• 코드 에디터 등 차별화되는 부분이 있어야 할듯.
• 우리도 코드를 댓글로 주고받을 수 있는데, github UX 등 차별화된 기능이 있어야 할듯
  • 만약 없으면 컨텐츠만 코드만 올리는 거라고 생각이 들어서 차별점이 안보일듯
  • 사실상 facebook에 올리고 댓글로 리뷰하는거랑 다를게 없는듯?
• 기획서에 들어가야 할 것
  • 기획서보다 한단계 위에 있는 문서 (프로젝트를 안내하는 대문 역할)
  • 대문 → 레포, 기획서, 등등 (링크로만 이루어져도 상관X) 여기로 오면 모든 리소스로 오는것도 좋음
  • 이걸 리드미에 붙여도 좋을듯!

FE style?

• SCSS 를 적용하여 사용. (not CSS in JS)
• 왜 사용했나요? 요즘 트랜드 → 스타일드 컴포넌트, 이모션, 테일윈드 등등
  • BEM 방법론 + 태그가 바껴서 불편 + 도입하지 않아도 똑같이 이용할 수 있지 않을까?
• BEM 사용하면 컨벤션 잘 지켜야 하는거 조심

인증은 어떻게?

• Github OAuth → SSO를 하겠다는 건데, 서비스 내에서 인가에 대한 권한의 차별은? (로그인만 되면 끝인가?)
  • 생각했던 건 jwt 사용해서 서버 자체에서 accesstoken, refreshtoken 사용 → 서버에서 확인하는 절차 할 예정
• jwt를 사용하여 하면 로그인 하면 권한에 대한 차별이 없는지? → 즉 권한 차이가 있는지?
  • 아직은 기획하지 않고 있어요.

Githook

• 커밋 타이틀 컨벤션을 고정할 수 있음
• 커밋을 남길 때, 올릴때 등등

issue tracking

• 현업에서는 github 별로 안씀. 지라 같은거 사용.
• 멘토님은 github으로 사용하는거 좋아하신다고. (그러나 현업에서는 다른 분들이 이슈를 보기 위해 깃헙 초대하는게 불편)
  • 그래서 다른 서드파티 사용하면 연결해줘야하는 등 필요
  • githook을 이용한 컨벤션에서 커밋 메세지 체크 + 브랜치 이름(지라 이슈 넘버로 따인 브랜치 명으로 강제 등)
• 혹시 이런거는 훅으로 강제하는게 좋다? 추천할만한게 있으실까요?
  • PR을 올리는데 커밋이 몇개 이상 쌓이면 PR이 안올라가게 → 즉, 작은 단위의 PR 유지하도록 (커밋 개수 5개 이하로 하기)
  • 이런 부분은 github bot을 이용해서 리뷰/머지 비활성화 하게 할 수 있음.

상태관리 어떤거 사용했는지?

• Zustand, RQ 사용했습니다.

  → 왜?

  • 멘토님께서 공부해보신다고 함! (감사합니다)

테스트

• Cypress : 하다보니까 유닛 테스트의 영역까지도 Cypress가 포함하게 됨 (통합 테스트의 측면에서)
  • 유닛 테스트에서 검증된 컴포넌트의 기능인데, 이걸 Cypress에서 화면 테스트를 하면 중복되는 느낌이 있음
  • 물론 통합 테스트는 중복이 없을순 없음.
  • 이런 부분에서 Cypress의 유닛 테스트 feature까지 만들면 중복 (끝도 없음)
  • 어느정도 선에서 잘 조정하기 (스타일을 다 체크하는 거는 되게 힘들고, 기능 하나하나 마우스에 대한 뷰의 변화 등등…)
  • 그리고 테스트의 폴더 구조도 어떻게 가져갈지 (화면 단위, 컴포넌트 단위) → 고민해보기 -> 통합은 시나리오 단위 유닛은 훅들만

DB

• RDB는 어디에 두고 사용하나요?
  • 일단은 저희 서버 안에서 돌릴 것 같습니다. (서버 = 네이버 클라우드)
  • NCP → 도커 안에서 서버를 돌리고, 도커 밖에서 mysql 직접 띄움
  • 그래도 RDB를 따로 빼면 너무 비싸서 서버 하나에 통합해서 사용했습니다.
• 멘토님 경험 : 스타트업 초창기 때 서버 하나에 몽고디비, 백엔드, 웹서버 이렇게 했다고 하심..! (한달 서버비용 < 50만원)
  • 이럴때 발생하는 문제는? : 이벤트같은거 한번 하면 따운생김.. 이럴때 급하게 이중화 하고 컨테이너 갈아타고 등등 하셨다고..! → 나중에 성장해서 분리, 이중화, DB Saas 등등 진행하셨다고 함 (돈으로 해결)

브랜치 전략

• release가 없으면? → 개발중인 기능 넘겨버리고 바로 릴리즈해야 하는 경우가 필요할수도 있음.
• 그래도 전략적으로 이렇게 짠 구조는 현업에서도 많이 사용함.
• 오히려 main브랜치 하나 두고, git flow 해보는것도 해보면 좋겠다 라는 생각
• 지금 선택한 방법도 좋아보임.

QnA

1. BE는 기술적인 도전이 없어서 성능 개선 등에 집중해보려 하는데 이런 부분은 어떨지?

• 성능 개선 → 개선 할 대상이 있어야 하는데, 성능의 퍼포먼스가 낮다 싶으면 개선을 해야 하는데, 일단 뭘 만들어야 성능을 측정하고 개선할 수 있음.
• 그래서 Feature를 빠르게 구현하는 거에 초점을 맞추고, 성능을 두번째로 생각을 하는게 좋을듯.
  • -> 하여 기능 개발에 초점을 맞춘 후 성능 측정 후 개선하기로 결정
• 모든 회사의 Code Review의 목적이 (멘토님 생각에는) 성능을 올리는 내용의 코드리뷰는 2순위임. 사실 첫번째 리뷰의 목적은 가독성. 잘 읽히고 다른 사람이 이 코드를 보고 수정하거나 개선할 때 빠르게 파악하여 개선할 수 있도록 코딩 하는 것
  • 사실 이 부분도 아는 만큼 보여서 가독성도 개인마다 다름. (삼항 연산자 → 잘 보일수도, 안 보일수도 등 → 우리는 삼항연산자 쓸지 안쓸지 정하기)
  • 어 이러면 코드의 성능이 좋지 않은데 < 가독성이 좋음 → 가독성이 좋게 코드를 맞춘 다음에 성능을 바꿔라.
• 처음부터 여유가 된다면 성능도 고려하지만, 일단은 잘 읽히는 코드를 만드는 것을 추천.
• BE에서 도전적인 Feature가 없다면…
  • ex) 테스트 커버리지를 무조건 80% 이상을 맞추겠다. → 이 부분이 현업에서는 되게 힘들기 때문에 챙겨보는 것도 좋을듯.
  • ex) 무조건 TDD를 하겠다.

2. 기획을 어느정도까지 자세히 해야할까?

• 원래라면 서비스를 기획하는 것 자체가 디테일까지 다 해야 하는 것.
• 기획 단계에서 생각할 수 있는 것들에 대해서 다 해야 함 (이런것까지 줘야 해? 까지도 다 해야 함.)
  • 이 단계에서 개발자가 참여 하긴 함.
• 하지만 만약 볼륨을 줄이고 싶다면 feature의 개수를 줄이고, 줄인 것들에 대한 디테일을 깊게 가져가는게 좋겠다.
• 이렇게 디테일하게 잡아도 개발하다보면 바뀜
• 그래도 디테일하게 잡다보면 개발 전에 더 빠르게 잡아낼 수 있음. → 시간을 아낄 수 있다.
• 가능하면 디테일하게 들어갈 수 있도록 하는것을 추천.