-
Notifications
You must be signed in to change notification settings - Fork 1
Meeting Log #1 (24.11.23)
- PR 병합 기준: 1명의 approve로 충분
- 사후 리뷰 허용
- 알림 관리: 팀 전용 슬랙 노티 채널 생성 예정 (효진님 담당)
- 테스트 커버리지 범위에 대한 논의
- 가장 작은 단위부터 시작하여 점진적 확장
- 의문점 발생 시 즉시 팀원들과 논의
히딩크 모드 도입
- 모두가 서로에게 반말 모드
- PR도 반말로
- 존댓말하면 패널티 (구현해야하는 컴포넌트 추가)
- ✅ 모든 props bypass 방식으로 확정
- ✅ forwardRef 사용 확정
- 익명함수(arrow function) 대신 명시적 함수 선언 선호
- 모듈 내부 상수는 함수 내부에서 관리 가능
- kebab-case 사용 확정 (예: design-token)
- 직관적인 색상명 사용 (예: surface → black)
- chakra-ui의 색상 정의를 기본으로 채택
- 세부 색상은 추후 조정
- fontSize, fontWeight 정의 필요
- 의현님이 관련 초안 작성 예정
- device-size 정의 필요
- PC/Mobile 두 가지로 구분하여 관리
- reset-css 등 글로벌 스타일을 위한 별도 패키지 생성 예정
- packages 폴더 내에서 관리
CodeRabit
- 코드 리뷰 자동화 도구
주요 기능 :
- AI 기반 자동 코드 리뷰
- PR 분석 및 피드백 제공
- 코드 품질 개선 제안
- 보안 취약점 탐지
Chromatic
- UI 컴포넌트 테스트 및 문서화 플랫폼
주요기능:
- Storybook 호스팅
- 시각적 회귀 테스트
- UI 변경사항 추적
- 팀 협업을 위한 UI 리뷰
- 자동화된 스크린샷 테스트
Codecov
- 코드 커버리지 분석 도구
주요기능:
- 테스트 커버리지 측정 및 보고
- PR별 커버리지 변화 추적
- 커버리지 리포트 시각화
- 커버리지 목표 설정 및 모니터링
- 컴포넌트 명세 작성 및 기능 구현 실습
- 직전까지 추가 예정. 각자 원하는 안건 올려주기바람
- 신원 : 템플릿 제너레이터 관련
- 외부 라이브러리 사용은 구현 속도와 효율성을 고려하여 자유롭게 각자가 결정
- 먼저 구현 후 필요에 따라 리팩토링하는 방식 채택
대엽 : 테스트 커버리지를 어디까지 높여야하는지에 대한 고민이 있음. Avatar 컴포넌트 구현부와 테스트에대해서 범위를 어디까지 가져가야할지?
의현 : 완성도와 상관없이 스스로 생각한 가장 작은 단위로 테스트하는 것이 좋아보임 가장 단순한 형태도 궁금증이 생긴다면 의견을 물어보면 될 것
성현 : radix와 같은 라이브러리를 살펴봤을 때, helper 함수를 만들어놓고 공통적으로 사용함. 어디까지 라이브러리의 도움을 받아야할지 고민.
의현 : 빠르게 구현이 가능하다면 자유롭게 적용하고, 먼저 구현하고 계속해서 수정해나가는 방향으로 작업.
내부 구현은 언제든지 변경될 수 있음. 일단 사용해보자는 의견
희지 : PR을 합치는 기준이 무엇인지?
의현 : 단 한명의 approve. 사후 리뷰를 해줘도 좋음. (적극적인 사후 리뷰 완전 환영)
희지 : 이메일 알람 꺼놓았는데 다들 어떻게 알림을 받는지?
효진 : 저희만의 슬랙 노티 채널을 파서 같이 확인하는 방법이 어떤지? 만든 뒤 공유하겠음.
의현 : props를 bypass할지? 원하는 props만 넘겨주는 식으로 할지?
본인은 모두 bypass하도록 구현했고 희지는 정의한 props만 넘겨주는 식으로 구현함.
성현 : 확장성있게 bypass하는게 좋아보임.
의현 : 이견이 없다면 모두 bypass 하도록 확정
의현 : forwardRef를 모두 해줄지?
신원 : 찬성
의현 : ref 전달 방식 확정
성현 : arrowFunction은 사용 안하는지
의현 : 일종의 익명함수라서 명시되도록 사용을 안하고 있음
진현 : Typography 컴포넌트 내부에서 const가 함수 내부에 들어있는 이유가 무엇인지? (ex. lineHeight)
의현 : lineHeight는 전역에서 알필요 없는 모듈만의 관심사라고 생각했기 때문.
스타일 차이이기 때문에 상수로서 전역에 빼놓아도 된다고 생각한다면 그렇게 관리해도 좋음.
효진 : 일단 사이프 홈페이지 디자인에서 정의해둔대로 사용하고 있음 (figma 홈페이지 페이지 기준)
진현 : 직관적인 이름을 사용하는 것이 좋다고 생각함. 예를 들어서
surface
보다는black
으로 표현효진 : 컬러명으로 위계를 표현하는 것이 좋아보임
신원 : AI 돌려서 확인해보는 것은 어떤지? (답변 aqua, cyan 이 나옴)
효진 : 사이프의 경우는
primary
색상이 기수마다 바뀌는 경우가 있음. 하지만, 컬러명으로 하기로 했으니 그렇게 하기로.의현 : 좋아하는 레퍼런스인
chakra/ui
의 색상 정의를 가져와서 사용하는 것으로하고 세부적인 색상은 세부 조정하는 것으로.
효진 : font 토큰은 어떻게 관리할지?
의현 : 본인이 정의해서 사용할 수 있도록 하겠음. (fontSize, fontWeight)
효진 : 기존 사이프 홈페이지는 폰트 토큰이 존재하지 않아서 폰트 토큰을 적용하지 못했음.
진현 : device-size도 정의하는 것이 좋아보임
효진 : 기존에는 tablet 사이즈는 의미 없을 정도로 디자인이 같았음. 그래서 크게 pc, mobile로 구분해서 관리해도 좋을 것 같음.
효진 : global-css 적용은 어떻게 하는게 좋을지? (ex.reset-css) 이게 없다면 작업이 어려워지지 않을지?
의현 : 우리 팀만의 패키지로 관리하면 좋을 것 같음. (packages 폴더 내부) 이슈등록 바람.
효진 : packages 폴더 내부 이름 컨벤션은 소문자인지?
성현 : kebab-case 사용이 어떤지? (확정)
의현 : 시간이 안될 것 같아 다음 시간에 하도록 하겠음
의현 : 레포에 Integration (CodeRabit, Chromatic, CodeCov) 추가가 필요한데 권한이 없음. 권한 요청으로 모두 설치 완료