Q. git flow vs github flow
A
- 멘토님의 회사에서는
git flow를 사용 중.github flow는 회사에선 어울리지 않는다.
git flow⇒ 서로 다른 배포 주기를 가졌을 때 유리했다.
github flow⇒ 개발자끼리 했을 때 효과가 좋았던 것 같다.
- 우리 프로젝트에서는 ? ⇒ 심플한게 좋다.
github flow가 유리할 듯
- merge 옵션 어떻게 할지 를 생각해보자
- 두 개의 브랜치에서 똑같은 파일을 건드렸을 때 ? ⇒ 충돌날 때 해결
- 멘토님 회사에선 프로세스로 해결중 ⇒ 매일 아침 데일리 미팅을 하면서 리뷰 과정에서 발견 후 수정
⇒ 매일 아침 PR 리뷰 하는 것을 해봤으면 좋겠다. 시간이 오래 걸리더라도
Q. github action 도입하면 좋을까요 ?
A
github action에 시간을 많이 쓰는 것은 알면 좋지만 우선순위를 낮춰도 될 듯하다. (해당 프로젝트에서의 취지와는 살짝 멀어보인다.) 여기에 시간 많이 써서 다른 것을 놓치면 안되니 !
- vercel 이라는 좋은 tool을 사용하고, 추후에 빌드 후 배포하는 과정 (AWS + action)을 해보자 !
Q. 슬랙 - PR 연동
A
- 하면 좋다.
- 구글에 정리된 것이 많다.
Q. 코드 컨벤션 관련 질문
- 컴포넌트명, 함수명, 상수(
API_KEY) 등 당연한 것
- 이벤트 핸들러 사용할 때 on~~
- 컴포넌트 생성할 때 함수 선언문 vs 화살표 함수
- ESlint, prettier
A
- 멘토님이 말해준 것대로 하지 말자 !!
- 모노레포 (?) ⇒ 여러 개의 서비스를 한 레포에 몰아놓은 것
- ESlint, prettier ⇒ 커스텀 보단 순정이 짱. 얘네가 추천해주는 걸로 설정 바꾸지 않고 + 추가로 필요한 것을 설정해서 사용 중
- gts
- 따로 추가하지 말고 기본 플러그인 만으로도 충분해보인다.
- on or handle ⇒ 이런건 취향이라 정답이 없다. 내부 회의 후 결정하자
- 폴더 구조
- 한꺼번에 하려고 하면 잘 생각이 안날 수 있다.
- 작업 하다가 떠오르면 다음 날 오전 회의 때 이야기 해보자.
- 코딩 하면서 생기는 이슈를 그 다음날 스크럼 때 해결해보면 좋을 듯 하다.
- 내부 상의 후 결정이 느려질 경우 멘토님 헲미
- 경로 별칭
- 파일 내보내기
- type 파일 이름
기본 설정으로 쓰고 떠오를 때 마다 회의 !!!!!!!
Q. storybook
스토리북은 컴포넌트 테스트 하기 쉬운 환경
A
- 독립된 환경에서 props 넣어보고 해보는 것이 좋다.
- 컴포넌트가 잘 나뉘어져 있냐에 따라 storybook 활용 의미가 커진다.
- 한 컴포넌트에 다 몰아져 있으면 쓰는 이유가 없잖아??
- 간단하게 필요한 기능만 사용해봐도 좋겠다.
Q. 테스트 (storybook + jest)
- 테스트는 어디까지 도입해야 할까요 ?
A
- 컴포넌트 테스트가 어려워 ! ⇒ testing library 를 써도 눈에 잘 안들어오더라. 사용경험이 좋지 않았다.
- 스토리북은 테스트 코드 보단 props가 뭐가 들어오고 등등 시각적으로 보이는 것을 보기 편한거지 테스트라고 보기 어렵다 ⇒ BackstopJS ????
⇒ storybook 도입해서 시각적으로 확인해봐도 좋을 듯하다 !
⇒ jest는 유틸 함수 체크할 때 ! : 동작을 잘 하고 있는지
Q. 상태관리 라이브러리
A
- 정답은 없다.
- Q. redux toolkit 사용하나요?
- redux 하드하게 쓰는 거면 redux toolkit 쓰면 좋아
- graphQL + react query 조합이 너무 좋았다
- redux toolkit vs react-query
- Q. recoil 별로인가요 ?
- 정답은 없다.
- 검색했을 때 정보가 많이 나오는 것을 좋아할 수 있고 길을 개척 해내가는 방향도 있지만 자료도 많고 질문도 많이 올라오는 기술을 쓰는 것이 좋아보인다.
Q. 차크라 UI or 테일윈드UI vs 수작업
A
선택하기가 어렵군요 ?
- 차크라UI를 쓰면 편해
- 0부터 시작하면 배우는 게 많다.
- 스타일을 하나하나 입혀야 하니깐 시간이 오래 걸릴 거 같은 ? 디자인에 시간을 많이 쓸 것 같다
⇒ 프로젝트 기간이 짧네 ? 스타일 라이브러리 써보자
⇒ 다른 팀들은 어떻게 했는지 염탐하고 오겠다.
Q. 커밋은 어떻게 나눠야 할까요 ?
A
- 잘게잘게 독립적으로
- PR단위를 작게해서
⇒ 전날 PR은 당일 오전에 머지한다
Q. tesk는 어떻게 나눌까요 ?
A
- 뷰 + 기능 단위로 하나씩 가져가면 좋을듯
- API 응답 타입 위치 : api 함수와 같이 둘 것인가? api 함수가 존재하는 파일에 type.ts로 따로 둘것인가?
- 재사용성 높은 것은 type.ts 폴더에 관리
- props 타입의 경우 컴포넌트 파일에서 관리
- api 호출 함수 네이밍을 어떻게 할것인가?
- 종혁님 믿고 가기
- test 폴더 및 파일 위치
- util 함수 근처에 ~~~.test.ts
- 파일 네이밍 이런건 어떨까? TodoList.tsx, TodoList.type.ts, XXX.constant.ts, XXX.enum.ts, 와 같이 middle name(?) 적극 활용
- 컴포넌트 등 export default VS export {}
- 요정도 참고만 해주세요 ㅎㅎ 나머지는 잘 작성해주셔서 이정도만 하고 진행하면서 정해보는 걸 추천드립니돠. 잘 안떠오르면 일단 넘어가고 코딩하면서 다시 얘기하면 더 의미있는 논의가 될 거 같습니돠