📝 사전 작업 회의 (작성일 : 2024 11 04)

분류: 정규 회의
생성 일시: 2024년 11월 4일 오전 10:22
선택: 회의록

📝 정리자료

⚙️ 환경설정 관련 정리

📝 회의 안건

🧑‍💻 1번 안건 (식사 전)

코어시간 및 MH 논의
PR 조건에 대해서 재논의
코드리뷰에 대해서도 재논의
문서화 → 기술적인 내용이 들어가는데 어떻게 적을지?
용어사전집
회의록 자동화에 대한 논의 (클로바노트)

🧑‍💻 2번 안건 (식사 이후)

컨벤션
브랜치
모노레포 관해서 커밋 메세지 내용도 좀 더 세분화 (FE, BE, story, swagger 등에 대해서 논의)
백로그

🧑‍💻 3번 안건 (시간 남거나 에너지가 남을 경우)

E2E → End to End Test → 어떻게 보여줄건가? (Cypress 나중 나중 발표 직전. 할지말지)
Storybook → 시각화 테스트 → 어떻게 해볼지? (Storybook 때문에 비용이 안듦. 할지말지)

📝 오전 회의 내용

✏️ 코어시간 및 MH 논의

🗣️ 코어시간에 대한 용어 정의

@Zen :: 근무시간과 코어시간은 다르다.
@혜인 정 :: 우리가 생각하는 코어시간은 근무시간에 가깝지 않았나? MH에 대한 기준만 정해도 될 것 같다. 네부캠 특성 상 큰 분류의 큰 의미는 없을 것 같다.
@주원 김 :: 쉬는 시간만 중간중간 갖고, 네부캠 코어시간에는 다 앉아있을 것이기에 그렇다.
@Zen :: 10~7시가 코어시간 개념대로라면 맞는거 같고, 그 외는 12시까지는 근무시간으로 두는데, 이떄는 진짜 자유.
- 코어시간에는 Zep 항상 들어와있기
- 그 외에는 자유

🗣️ MH에 대한 논의

@주원 김 :: MH는 10시간으로 생각하긴 했다. 하루에 2.5 Task를 생각했다. 한 테스크 당 4MH로 잡았다. 코드리뷰나 각자 학습할게 있기 때문에 12시간씩 잡으면 빡빡하지 않을까 생각을 했다. 10시간으로 잡고 다음주에 조정하고 하는게 좋을 것 같다.
@Zen :: MH에 코드리뷰나 문서화 이런거 포함시킬건지도 논의해봐야할 것 같다.
@혜인 정 :: 생각했던 것은 코드리뷰나 문서화는 다 시간 외라고 생각을 했다. 그때 그렇게 이야기가 된 줄 알았다. 만약에 이게 맞다면, 우리 코어타임 9시간 중 1시간을 빼서 8시간으로 잡아도 될 것 같다. 나는 사실 10시간 12시간 이렇게 되면 이 시간동안 쭉 앉아있어야 하는 것이다. 집중이 빡 안될 것 같다는 문제가 있다. 예를 들어, 10시간 기준으로 0.5 MH로 잡아서 5시간 안에 끝내겠다. 이렇게 되어있는데, 범위가 너무 넓어져버려서 집중이 빡 안될것 같다는 느낌이 있다. 일단 그렇지만 다른 분들의 의견을 따르겠습니다.
@동율 이 :: 코드리뷰나 문서화는 시간 외라고 생각을 했다. 이 부분을 제외하면 12시간은 너무 많은 것 같고, 10시간 이내로 잡는게 좋지 않을까 생각하고 있습니다. 물론, 나중에 주차 길어지고, 못한 부분이 많아지면 열심히 해야하는 부분이 많아지면 더 고려해야할 수도 있을 것 같다. 일단 기준점 정도는 10시간 이내로 잡는게 좋지 않을까 생각하고 있습니다.
@주원 김 :: 그러면 하루 MH를 8시간으로 잡고, 백로그를 작성할 때 2시간 단위인 작업들을 만들어둬서, 하고 싶은 사람이 있으면 더 가져가면 좋을 것 같다. 코어타임을 더 하라고 강요할 수는 없을 것 같고, 일단은 8시간으로 잡고 0.5 Task 정도로 쪼개놔서 “저 오늘 하나 더 할게요.”하면서 가져가면 좋지 않을까 한다.
@혜인 정 :: 좋긴 한데.. 제가 8시간을 주장해서 맞춰주진 않아도 됩니다.
@Zen, @동율 이, @주원 김 :: 지칠 수 있으니 8시간으로 잡고, 코드 기가막히게 써지면 더 해도 되고 기본은 8시간.
@혜인 정 :: 8시간으로 되지 않을 걸 알기에.. 걱정이 앞섭니다… 사실 8시간 못 지켜질 거 알지만…… 이거라도 정해놔야 심적으로 편할 것 같아요…………
@Zen :: 어떤 작업이 주어졌을때, 그걸 다 완수할거기 때문에.. 그냥 8시간은 건강을 위한 기준으로 잡아도 좋을 것 같습니다. 사실, 혜인님 말은 그렇게해도.. 항상 슬랙보면 불켜져있음…
@혜인 정 :: 생각이라도 하면서… 심적 부담을 줄이고 싶어요..

📚 정리

MH는 8시간으로 측정.
Task 단위는 0.25MH 2시간.
일 분배 단위는 0.5MH로 잡자.

✏️ 코드리뷰에 대한 논의

🗣️ 코드 리뷰를 어떻게 할 것인가?

코드리뷰를 어떤 목적을 달성하기 위한 장치로 쓰고 싶으신가요?

@주원 김 :: Vitest를 이용해서 테스트를 진행하고 있다. 테스트가 알맞게 진행되고 있는가를 확인할 필요가 있다. 테스트가 알맞다면 원래 쓴 코드에 대해서는 안정성이 보장이 된다. 이에 따라서 테스트를 보는 능력을 기르고 싶다.
- Vitest 를 통한 Unit Test를 진행하니까, 테스트 코드가 잘 작성이 되어 있는지, 코드 자체의 분리가 테스트 가능한 코드 단위로 잘 모듈화 되어 있는지 확인하고 싶습니다.
- @Zen :: 테스트코드에 대한 최소조건을 정하자. (실패케이스 몇개, 성공케이스 몇개) → 나중에 이야기
@주원 김 :: 데일리스크럼, 코드를 이해하는 목적이다. 질문을 미리 남겨둘 수 있는 장치로 쓰고 싶다. 다음날 데일리스크럼에서 질문을 하게 되면 서로 질문할 시간도 없고, 머리가 안돌아가는 타이밍이니 궁금한거 있으면 미리 좀 적어주면 질문을 받을 사람도 미리 준비할 수 있는 시간이 될 것 같다.
@혜인 정 :: 우리끼리 코드리뷰 하는 건 엄청난 실력향상이 된다거나, 코드를 더 잘짜게 된다거나 이런건 적을 것 같다. 시니어 분들이 봐주는게 아니라서, 경험 수준이 비슷하기 때문이다. 제가 느끼는 코드리뷰의 목적은 팀원들이 뭘 하고 있는지 서로의 현황을 알고, 질문을 남겨두거나, 피드백을 남겨두기 위한 장치로 생각했다.
@Zen :: “누가 어떤 코드를 짰는지 모르게 하고 싶다.” - 지식적으로나 코드적으로나 서로가 어떤 작업을 했는지 외부에서 봤을때 아예 모르게. 이런 목표를 달성하기 위한 장치로 코드리뷰를 사용하고 싶습니다.
@혜인 정 :: 모두가 지금 코드리뷰의 목표가 “서로에 대한 코드를 보는 것”이 장치만으로 코드를 보는 거라는 생각이 든다. 거창한 코드에 대한 리뷰! 라는 것보다는 PR에 댓글을 남기는 정도가 맞나요? 코드리뷰라는 장치로써, 모두가 어떤 것을 하는 것이 목적이라면..
@Zen :: 서로에 대한 작업 이해, 이해에서 나오는 서로에 대한 피드백의 장치로 쓰고 싶습니다.
@혜인 정 :: 좋아요.

📚 정리

목적 : 서로에 대한 작업 이해, 이해에서 나오는 피드백
방법 :
1. 서로의 코드를 보고 다른 사람들이 작성한 코드를 이해한다.
2. 만약 피드백할 사항이 있다면 피드백을 남긴다.
3. 코드리뷰는 PR Approve 전에 한다.
4. 피드백 사항이 있으면 이를 다 수정해서, 수정이 끝나면 Approve 진행.

✏️ PR 조건 논의

🗣️ PR Approve의 조건 논의

@혜인 정 :: PR Approve가 모두의 Approve를 받고 하는 건데, 조금씩 밀리면 많이 쌓이는 경우가 있을 것이라고 생각한다. 4명이 작업하다보니 많이 쌓일 것 같아서, 이건 조금 비현실적인거 같다. 제 생각에는 한명씩 1:1 랜덤으로 돌리는 게 어떨까? 오늘 예를 들어 우리가 코드를 짜서 보냈으면, PR이 4개면 4개의 PR 중에 자동화를 시키는 거다. 작성한 PR 4개 중에 하나를 올리면 자동으로 동율님이 Approve 대상으로 올라가고, 2번 PR을 올렸을때는 재도님이 Approve 하는 거고. 이렇게 계속 섞이게 되면 모두의 코드를 다 볼 수 있게 된다고 생각한다.

랜덤으로 Approve할 사람을 뽑아서 그 사람이 해당 PR에 대해서 리뷰하게 하자.

@Zen :: Approve의 조건을 2명으로 해보면 어떨까요?

@주원 김, @동율 이, @혜인 정 :: 좋습니다.

🗣️ PR 날라오면 몇 시간 내로 리뷰할 것인가?

@혜인 정 :: 현실적으로 시간을 정하지 않았으면 좋겠습니다. 저희 모두가 해야하는데 미루지는 않지 않을까 하는 생각이 들어서, 시간을 정해서 오늘까지면, 더 중요하게 작업해야 하는 게 있는데 우선순위가 꼬여버릴 것 같다는 생각이 있습니다.

@주원 김 :: 당일까지로 하나요?

@혜인 정 :: 그것도 정해두지말자긴 했는데, 우리 스스로의 제제가 필요할지 진짜 진짜 모르겠습니다.(I don’t know) 다른 분들 의견 듣고 싶어요. 이거 ㅈ니짠 모르겠음

@주원 김 :: 코어시간에 잡은 것은 당일 내에 하고, 추가 작업을 한 것은 늦어도 다음날까지 하면 좋지 않을까 했습니다.

@Zen :: 못해도 다음날 오전 10시 전(데일리스크럼 전)까지는 PR 요청이 비어있으면 합니다.. 주말은 제외 쉬셔야죠. 다음 작업 사이클 전까지 머지가 안되면 한번에 머지 시에 충돌이 엄청날꺼같아서 그렇습니다.

@동율 이 :: 주원님 말씀에 동의하는게, 코어 시간에 작업한건 당일 자정(오후 11시 59분)까지 리뷰 완수, 그리고 추가 작업 분에 대해서는 언제 올라올 지 모르니 다음날 오전 10시 전까지 완수.

@Zen, @혜인 정, @주원 김 :: 좋습니다.

📚 정리

PR 리뷰를 하면서 코드리뷰도 같이 한다. 즉, PR리뷰 === 코드리뷰
테스크 분배해서 당일에 작업된 작업물에 대해서는 당일 자정(오후 11:59)까지 완수한다.
팀원 개인적으로 추가 작업한 사항에 대해서는 다음날 10시까지 완수한다.
이유 :: 밀려서 한번에 머지를 할 경우 충돌이 날 가능성이 있기 때문에, 다음 작업 싸이클 전까지는 PR이 다 처리되도록 한다.

✏️ 문서화에 대한 논의

🗣️ 기술문서에 대한 안건

안건 - @Zen :: wiki라고 하면 나무위키생각하면 된다. 저희의 기술 내용에 대한 설명이자, 동시에 학습 등 관련되서 처리한 프로젝트에 대한 과정 및 결과물에 대한 정보.
1. github wiki를 어떻게 관리할 것인가?
2. 기술 문서를 어떻게 적을 것인가?

🗣️ `Github wiki`를 어떻게 관리할 것인가?

@주원 김 :: github wiki는 노션에 있는 걸 옮기는 건가요?
@Zen :: 논의해봐야한다. 지금 쌓인거 옮기는 것도 일이다.
@혜인 정 :: 제가 해봤을 떄는 꺠지는 것은 인용만 꺠지고, 나머지는 안깨졌던 것 같아요. 데이터베이스 등도 다 되었던 거로 기억하는데 아닌가요?
@Zen :: wiki를 어떤 목적으로 쓸 것인가를 먼저 논의해봐야할 것 같아요.

🗣️ `wiki`를 어떤 목적으로 쓸 것인가

아카이빙 목적으로 노션에 있는 자료를 다 migration 할 것인지, 아니면 정제해서 정리된 것들만 딱!딱! 올릴 건지

@혜인 정 :: 재도님이 생각한 목적은 무엇이었나요?
@Zen :: 아카이빙 목적이었습니다.
@주원 김 :: 정제는 각자 블로그나, 여기에 하고, 아카이빙 목적으로 하자.
@Zen :: 회의록 아카이빙시

노션을 그대로 깃허브에 옮기고, 디렉토리 구조도 그대로 가져갈 생각이었습니다.
- 루트
  - 팀 소개
    - 팀원
  - 회의
    - 데일리 스크럼
    - 회의록
      - 회의록 정리
      - 회의록
      - 사전 준비록
  - 기술문서
    - FE
      - React
      - Test
    - BE
      - WebServer
      - WAS
      - DB
    - 환경설정
@혜인 정 :: Migration 비용이 많이 발생하지 않을까 하는 우려사항이 있습니다. 궁금한게 사실 노션 링크를 적어도 되잖아요? 깃허브 위키에 똑같이 적으려는 이유가 있나요?
@Zen :: 여러가지 이유가 있다.
1. 노션 들어오는 거 자체를 싫어하는 분들이 많다.
  - 링크 열고, 로딩하고, 새 창띄우는게 생각보다 짜증이 많이남.
  - 포폴로 쓰겠다고 하면, 면접관은 우리에게 20초정도 쓰면 많이 쓴거. → 이걸 다 로딩시간으로 쓰긴 아깝다.
2. 개발바닥 에서 라이브가 있었다.
  - 이력서+포폴 첨삭, 노션으로 제출한사람들 일단 다 짤랐습니다.
  - 위키에 다 박아라. 그래야 우리도 포폴 볼때 프로젝트 한번에 보지 않겠느냐?
3. 사실 wiki든, notion이든 안본다고 보는 게 맞긴 하다. 관심있는 몇개만 보지.
  - 그때에 한번 들어와서 다른것도 겸사겸사 한번만 클릭해볼까? 하는 마음이 있을 때 비용을 줄여주면 아낀 에너지로 다른 것도 보게 됨.
  - 심리적인 것을 이용함.
@혜인 정 :: 어쩃든 포폴로써 가치가 있기 위해서, 보여주기 위해서라면… 그리고 이거 하나하나 옮기는게 비용이 많이 들거라 생각한다. 물론 어느정도일지는 모르겠지만, 다 마치고 넣는건 어떤가?
@Zen :: 처음 틀만 잘 잡히면, 문서 어차피 적잖아요? 그러면 적을때 MD으로 빼서 같이 넣는건 매순간했을때 비용이 크게 안든다. 총량으로 봤을때는 같지만, 그걸 되게 작은 단위로 쪼개서 매일 한다고 생각? 한다고 하면 이에 대한 초기작업은 제가 하겠습니다. 그 이후는 팀원이 그때그때 올려도 될 것 같아요.
- @Zen :: 개인적인 욕심이긴 한데, 저희가 TypeDOC(JSDOC, TSDOC) + Storybook + Swagger 등도 쓰니까, 이거 하나로 다 묶어서 저희 기술문서를 만들고 싶기도 합니다.
  - JSDoc, TSDoc 컨벤션은 이따 논의
  - 다 끝나고 저희만의 기술문서 사이트 만들면 어떨까 했습니다. → vercel 무료로 계속 사용가능하니까… (관련해서는 나중에 곰터뷰 참고하셔도 좋을것 같아요.)

📚 정리

위키는 아카이빙 목적으로 사용한다.
노션에 있는 내용을 그대로 위키에 서술한다. 디렉토리 구조는 노션을 따른다.
포폴에서 보여주기 위한 목적이다.
코드 자체에 대한 내용은 노션이나 깃허브에 업로드하는 것이 아닌 TSDoc, JSDoc, Storybook, Swagger를 이용한다.
최종적으로, 위키와 이걸 합쳐서 우리만의 기술 문서 사이트를 열고 배포한다.

✏️ 용어사전집

컨벤션이긴 하다. 우리는 이 용어를 이런 의미로 쓴다를 정리해둔것. ex. 피그마에 경로방 등이 있는데 이런걸 어떻게 지칭할지 정하자는 거. 그리고, 그걸 단순히 저희끼리만 아는 게 아니라 문서화 하는거.

🗣️ 도입에 대한 내용

@Zen, @혜인 정, @주원 김, @동율 이 :: 좋습니다.
@주원 김 :: 이렇게 되면, 경로 드로우 이런 식으로 저희가 이름을 붙이는 건가요?
- @Zen :: 네! 그렇게 하면 좋을 것 같고, 이게 모호할 수 있어서 문서로 명세하면 좋을 것 같아서 제안해봤습니다.
@혜인 정 :: 노션 최상단에다가 용어 사전집을 추가해서, 표처럼 만들고, 모두가 동의한 것을 하나씩 추가하고, 마지막에 완전 배포할 때 위키에 넣어도 될 것 같습니다. 완성이 되었을 떄 넣으면 좋을 것 같아요.

📚 정리

용어사전집 만든다.
우리가 용어를 지칭하고, 이에 대한 설명을 적는다.
노션의 루트에 항목을 만들고 지속적으로 업데이트 한다.
최종본이 나왔을 경우에 그때 가서 위키에 추가한다. (그 전까지는 보류)

✏️ 회의록 자동화에 대한 논의

🗣️내 클로바노트의 사용에 대한 논의

@혜인 정 :: 내일부터 제가 클로바 노트로 해볼게요. 제가 썼을떄는 한창 나왔을떄라 다 무료였는데, 요약까지는 크레딧이 있어야하는지는 모르겠어요.
@Zen :: 대화본이 전부다 적혀있었으면 합니다. → GPT 요약이 훨씬 나아서… 네이버에겐 미안하지만…
- @Zen :: Claude, GPT 둘다 결제하려구요.
- @Zen :: 내일까지는 이렇게 적기도 하고, 클로바 노트도 사용. 대신에 만약에 클로바노트가 잘 적어지면 모래부터는 그냥 클로바노트만. 이렇게.

📚 정리

클로바 노트 사용한다.
2024년 11월 05일 화요일에 클로바노트 사용 및 지금처럼 회의록 작성을 하면서, 클로바노트가 우리가 사용하고자 하는 목적대로 동작하는지 테스트한다.
클로바노트는 요약이 아닌, 회의록 적문을 적는 기능을 목적으로 한다.

점심시간 : 11시 45분 ~ 13시 00분까지
장소 : Zep

📝 오후 회의 안건

✏️ 모노레포에 관한 논의

모노레포에 대한 개념 일치

디렉토리 구성을 어떻게 할지
자동화 도구 뭐쓸지

🗣️ 모노레포에 대한 개념 일치

@Zen :: 모노레포가 깊게 들어가면 진짜 복잡한데, 간단하게 써보려면 어느정도면 될까요?

@혜인 정 전에 이야기했던 것처럼, 백엔드 프론트 함께 한 디렉토리에 넣은 것

@주원 김 :: 지금까지 해온 것처럼 슬랙에 정리한 것처럼 정리하려고, 모노레포를 하라고 한 게 아닐까 싶었다. 기술적 도전보다는 레포 안에 프론트앤드 백앤드 폴더가 있으면 되지 않을까 싶다.

@혜인 정 :: fe, be가 독립적으로

-root

-FE

-package.json

-tsconfig

-BE

-package.json

-.git

eslint
prettier

-husky

-package.json ⇒ eslint 설치 + prettier 설치 + 관련해서 환경설정 데이터들…

진짜 공통으로 들어가는 것 외에는 아무것도 들어가지 않게 하자.
실행 권한을 다시한번 주자

-readme.md

@주원 김 :: 원래 레포지토리를 따로 해야하는 데 하나만 짜야하는 구조로 생각했다.

@Zen :: 둘 다 독립적인 프로세스, git커밋을 제외하고는 아예 다르게 동작, cd했을때 각각 디렉토리 들어가서 조작, 컨벤션도 각각 따로? 인가요…?

@혜인 정 :: 공통되는 건 eslint 같은 설정 FE, BE

📚 정리

프로젝트 루트
│
├── README.md                   # 프로젝트 전반적인 설명, 설정 방법 등
├── package.json                # 루트 공통 패키지 및 스크립트 관리
├── .eslintrc.js                # 공통 ESLint 설정
├── .prettierrc                 # 공통 Prettier 설정
├── ignore 파일들(.gitignore 등)  # 무시 파일 설정
│
├── FE                          # 프론트엔드 패키지
│   ├── package.json            # 프론트엔드 전용 패키지 관리
│   ├── tsconfig.json           # 프론트엔드 전용 TypeScript 설정 (루트 설정을 확장)
│   ├── src                     # FE 코드가 들어가는 폴더
│   │   └── index.tsx           # FE 시작 파일
│   └── ...                     # 기타 FE 관련 파일 및 폴더
│
├── BE                          # 백엔드 패키지
│   ├── package.json            # 백엔드 전용 패키지 관리
│   ├── src                     # BE 코드가 들어가는 폴더
│   │   └── index.js            # BE 시작 파일
│   └── ...                     # 기타 BE 관련 파일 및 폴더
│
└── .husky                      # Husky를 통한 Git Hook 관리
    ├── pre-commit              # 커밋 전에 실행할 스크립트 (ESLint, Prettier 등)
    └── ...                     # 기타 Husky 관련 설정 파일

자동화도구는 별도로 사용하지 않고 pnpm으로 관리
package.json 명령어는 아래를 참고

pnpm으로 모노레포 환경 구축하기

✏️ 브렌치 전략에 대한 논의

브랜치 어떻게 명명할지

버전관리 어떻게 할지
배포전략
커밋 관련된 메세지 내용들은 어떻게 할지(브렌치 전략에서 논의해도 무방)

🗣️ 브렌치 전략 생각해오신게 있나요?

@혜인 정 deploy, develop (dev), feature/ , fix/ (깃 플로우)

@동율 이 :: 깃허브 플로우, 깃플로우 두가지 전략을 알아보았다. 우리가 모듈화도 생각하고 있고, 안정성도 생각하는 부분이 있다. 이런 부분 잘 하려면 시간 조금 들더라도 Git Flow 써서 develop 등을 써서 하는게 좋지 않을까 하는 생각을 했다.

@주원 김 :: 깃플로우가 나을 것 같습니다.

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

📚 정리

깃플로우 방식으로 진행 → 학습이 좀 필요할거 같으니 이건 본격적으로 코드작성 들어가기전에 이야기 (환경설정때)

🗣️ 브렌치 명명 전략은 어떻게 할 것인가?

자료출처 : 인파님 블로그
@Zen :: feature-fe-[이슈나 테스크명]-[세부내용] 이런식으로 적어보면 어떨까요?
@혜인 정 :: feature/fe/[이슈나 테스크명 넘버명]-[내용]-[세부 내용], 분리가 된다고 생각해서 이렇게 표기했습니다.
@Zen :: /가 좋은거 같아요.

📚 정리

[git flow 명명]/[fe/be]/[이슈나 테스트의 넘버링]-[내용]-[세부내용]
예: feature/fe/01-로그인-UI구현

🗣️ 버전관리

0.0.1 등과 관련된 내용입니다.

@Zen :: 매주 배포를 해야하는데… 이걸 마이너로 취급한다고 치면 0.1로 갈건지 이런거…?
@혜인 정 :: 아직은 개발 단계라서 6주차 완성이 끝나고 버전이 그게 0.0.0이 되고 6주 이후에 버전 업그레이드를 해야하지 않을까 하는 생각이 듭니다.
@주원 김 :: 개발을 하면서 완성이 되고 수정하면서 기능을 늘려야 버전이 올라가는게 맞지 않나 싶어서 6주 이후에 버전이 올라가는게 맞지 않나 싶었습니다.
@동율 이 :: 개발이 끝나고 하는 게 나을 것 같습니다.

📚 정리

버전관리는 개발이 끝나고 부터 생각. 즉, 개발이 끝난 시점이 0.0.0으로 취급. (나중에 정확한 버전은 생각)
리팩토링 직전에 다시 논의

HeadVer - 기민한 프로덕트 팀을 위한 새로운 버저닝 시스템

참고자료

🗣️ 배포 전략

@Zen :: Git Flow 전략 쓰기로 한 이상 배포는 Master가 업그레이드 되었을 때 하면 좋을 것 같습니다.
@혜인 정 :: 금요일마다 하는거에 굳이 힘을 쏟을 필요는 없어서 develop 브렌치를 보여줘도 될 것 같습니다.
@Zen :: 저희 그러면 master에 올려서 배포하는 것은 6주 이후인가요?
- @혜인 정 :: 처음에 계속 master에 올리는 건 크게 의미가 없을 것 같아요. 그때 해도 괜찮아 보여요. 4주차 금요일 혹은 5주차부터 배포 시작해서 오류나 이슈 대응
- @주원 김 :: 리팩토링 기간을 기점으로 해서 리펙토링 직전에 master에 올리고, 그 다음에 리팩토링 하면서 그때부터 계속 maseter 에 업데이트된 걸 올려도 좋을 것 같아요.
@Zen :: 버전도 나오네요. 리팩토링 직전을 기점으로 이때부터 버전관리 들어가면 되곘네요!

📚 정리

Development 브렌치를 기능 개발 완료 끝나기 전까지 활용 (5주차 전까지 끝내기)
개발 끝나면 master에 올림
그때부터 버전관리 하면서 리팩토링 시작

🗣️ 커밋 메세지는 어떻게 할 것인가?

태그 이름	설명
Feat	새로운 기능을 추가할 경우
Fix	버그를 고친 경우
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링
Chore	빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우

@Zen :: 한글 영문 정도만 통일합시다. 의도는 뭐엿냐면, Feat(FE-taskNumber): ~~~~
@Zen :: Docs(Storybook):
@혜인 정 전 한글 한표요

@혜인 정 이런늑미

[FE][Feat] #1 : 로그인 UI 구현

- OAuth 연동
- 회원가입과 로그인 로직 구현
- 로그인, 회원가입 폼 컴포넌트 구현

[FE][Feat][Fix] #1 : 로그인 UI 수정

- OAuth 연동
- 회원가입과 로그인 로직 구현
- 로그인, 회원가입 폼 컴포넌트 구현

description은 선택, 만약 쓸거라면 - 정도는 붙이기, 제목 다음에 한줄 띄고 작성

📚 정리

커밋 메세지는 한글로 작성하기
커밋 메세지 형식은 아래와 같은 규정을 따른다.
- [FE/BE][태그 이름] #{테스크 넘버} : 로그인 UI 구현
  - 태그 이름은 여러개 사용 가능
- description은 선택, 만약 쓸거라면 - 정도는 붙이기, 제목 다음에 한줄 띄고 작성
- 그 외 양식은 자유 너무 지저분하지만 않게…
- 사용 예시는 아래와 같다.
```
[FE][Feat] #1 : 로그인 UI 구현

- OAuth 연동
- 회원가입과 로그인 로직 구현
- 로그인, 회원가입 폼 컴포넌트 구현
```
husky써서 push할때도 검사하도록 설정

✏️ 컨벤션에 대한 논의

▸ ESLint 설정 ▸ Prettier 설정 ▸ TSConfig 설정 ▸ React 관련 컨벤션 이야기 ▸ Tailwind 관련 컨벤션 이야기

🗣️ ESLint 어떤 스타일로?

@Zen, @혜인 정, @주원 김, @동율 이 :: 이미 있는거 npm에서 다운받아서 최대한 활용하자.

@Zen :: 이미있는거에 몇가지만 +a

📚 정리

GitHub - airbnb/javascript: JavaScript Style Guide

npm: eslint-config-airbnb

Airbnb Style Guide로 가고, 그외 세부 설정은 React 가이드 쓰기 보다는 걍 우리가 정하기

npm: eslint-config-airbnb-typescript

🗣️ React 관련된 코딩 스타일 컨벤션

📚 정리

export default function Div() { // @주원, @동률 이
	...
}

export function Div() { // 
	...
}

export const Div = () => { // @Zen, @혜인 정
	...
}

@Zen :: 3번인 이유
1. 호이스팅 문제 (화살표 함수는 호이스팅에서 자유롭다.)
2. export default를 쓰게되면 코드를 사용하는 입장에서 명명을 맘대로 바꿀 수 있음. → export도 안되는 건 아니지만 별도의 요구사항이 있는데, export default는 변수에 애초에 담아버릴 수 있음. TS쓰는 의도와 어긋남.
3번으로 결정

export const Div = ({prop1, prop2, ...}) => {
	...
}

export const Div = (props: IProps) => {
	const {prop1, prop2} = props;
	...
}

export const Div = (props: IProps) => {
	props.prop;
	props.prop2;
	...
}

@Zen :: 2번, 3번 중 어느 것으로…?
1. @혜인 정 :: 타입스크립트 썼을 떄 interface 가 직관적으로 보인다.
2. @Zen :: props가 어디에서 쓰이는지 정확히 파악이 가능하다.
@혜인 정 :: 둘다 할당 안하는 경우도 있다.
2, 3번 섞어서 쓰기로 결정. props 만 인자로 제대로 받아오자.

interface

다 인터페이스로 사용
앞에 I 붙이기. (PascallCase)
props 쓸때 명명규칙은 I{컴포넌트명}Props
- 예: ICustomComponentProps

🗣️ Prettier 어떻게 할 것인가?

📚 정리

npm: eslint-plugin-prettier

위에거 쓰자.

🗣️ Tailwind 컨벤션

📚 정리

npm: eslint-plugin-tailwindcss

위에거 씁시다.

🗣️ 변수명 컨벤션

📚 정리

상수
- 스크리밍 스네이크 케이스(Screaming Snake Case)
변수
- camel case
함수명
- 동사+명사

https://github.com/ParkSB/javascript-style-guide

참고하기

📝 백로그 설정

정방형 사진 오늘까지 보내주세요 (readme 수정해둘게요)

🔗 관련 링크:

📜 라이센스: MIT 라이센스

👥 기여자: 기여자 목록 보기

💻 개발 문서

⚖ 개발/학습 기록 바로가기

📝 사전 작업 회의 (작성일 : 2024 11 04)

📝 정리자료

📝 회의 안건

🧑‍💻 1번 안건 (식사 전)

🧑‍💻 2번 안건 (식사 이후)

🧑‍💻 3번 안건 (시간 남거나 에너지가 남을 경우)

📝 오전 회의 내용

✏️ 코어시간 및 MH 논의

🗣️ 코어시간에 대한 용어 정의

🗣️ MH에 대한 논의

📚 정리

✏️ 코드리뷰에 대한 논의

🗣️ 코드 리뷰를 어떻게 할 것인가?

📚 정리

✏️ PR 조건 논의

🗣️ PR Approve의 조건 논의

🗣️ PR 날라오면 몇 시간 내로 리뷰할 것인가?

📚 정리

✏️ 문서화에 대한 논의

🗣️ 기술문서에 대한 안건

🗣️ Github wiki를 어떻게 관리할 것인가?

🗣️ wiki를 어떤 목적으로 쓸 것인가

📚 정리

✏️ 용어사전집

🗣️ 도입에 대한 내용

📚 정리

✏️ 회의록 자동화에 대한 논의

🗣️내 클로바노트의 사용에 대한 논의

📚 정리

📝 오후 회의 안건

✏️ 모노레포에 관한 논의

🗣️ 모노레포에 대한 개념 일치

📚 정리

✏️ 브렌치 전략에 대한 논의

🗣️ 브렌치 전략 생각해오신게 있나요?

📚 정리

🗣️ 브렌치 명명 전략은 어떻게 할 것인가?

📚 정리

🗣️ 버전관리

📚 정리

🗣️ 배포 전략

📚 정리

🗣️ 커밋 메세지는 어떻게 할 것인가?

📚 정리

✏️ 컨벤션에 대한 논의

🗣️ ESLint 어떤 스타일로?

📚 정리

🗣️ React 관련된 코딩 스타일 컨벤션

📚 정리

🗣️ Prettier 어떻게 할 것인가?

📚 정리

🗣️ Tailwind 컨벤션

📚 정리

🗣️ 변수명 컨벤션

📚 정리

📝 백로그 설정

저작권 © 2024 DDara. All rights reserved.

💻 개발 문서

Clone this wiki locally

🗣️ `Github wiki`를 어떻게 관리할 것인가?

🗣️ `wiki`를 어떤 목적으로 쓸 것인가