Skip to content

Meeting Log #1 (24.11.23)

Shinwon Jang edited this page Dec 28, 2024 · 1 revision

1. 개발 프로세스 관련

PR 및 코드리뷰

  • PR 병합 기준: 1명의 approve로 충분
  • 사후 리뷰 허용
  • 알림 관리: 팀 전용 슬랙 노티 채널 생성 예정 (효진님 담당)

테스트 관련

  • 테스트 커버리지 범위에 대한 논의
  • 가장 작은 단위부터 시작하여 점진적 확장
  • 의문점 발생 시 즉시 팀원들과 논의

2. 팀 컨벤션

히딩크 모드 도입

  • 모두가 서로에게 반말 모드
  • PR도 반말로
  • 존댓말하면 패널티 (구현해야하는 컴포넌트 추가)

3. 코드 컨벤션

Props 관리

  • ✅ 모든 props bypass 방식으로 확정
  • ✅ forwardRef 사용 확정

함수 선언

  • 익명함수(arrow function) 대신 명시적 함수 선언 선호
  • 모듈 내부 상수는 함수 내부에서 관리 가능

패키지 폴더 네이밍

  • kebab-case 사용 확정 (예: design-token)

4. 디자인 시스템

색상 토큰

  • 직관적인 색상명 사용 (예: surface → black)
  • chakra-ui의 색상 정의를 기본으로 채택
  • 세부 색상은 추후 조정

폰트 토큰

  • fontSize, fontWeight 정의 필요
  • 의현님이 관련 초안 작성 예정

반응형 디자인

  • device-size 정의 필요
  • PC/Mobile 두 가지로 구분하여 관리

글로벌 스타일

  • reset-css 등 글로벌 스타일을 위한 별도 패키지 생성 예정
  • packages 폴더 내에서 관리

5. 외부 통합

설치 완료된 도구들

CodeRabit

  • 코드 리뷰 자동화 도구

주요 기능 :

  • AI 기반 자동 코드 리뷰
  • PR 분석 및 피드백 제공
  • 코드 품질 개선 제안
  • 보안 취약점 탐지

Chromatic

  • UI 컴포넌트 테스트 및 문서화 플랫폼

주요기능:

  • Storybook 호스팅
  • 시각적 회귀 테스트
  • UI 변경사항 추적
  • 팀 협업을 위한 UI 리뷰
  • 자동화된 스크린샷 테스트

Codecov

  • 코드 커버리지 분석 도구

주요기능:

  • 테스트 커버리지 측정 및 보고
  • PR별 커버리지 변화 추적
  • 커버리지 리포트 시각화
  • 커버리지 목표 설정 및 모니터링

6. 다음 회의 안건

  • 컴포넌트 명세 작성 및 기능 구현 실습
  • 직전까지 추가 예정. 각자 원하는 안건 올려주기바람
  • 신원 : 템플릿 제너레이터 관련

7. 라이브러리 활용

  • 외부 라이브러리 사용은 구현 속도와 효율성을 고려하여 자유롭게 각자가 결정
  • 먼저 구현 후 필요에 따라 리팩토링하는 방식 채택

8. 참석자 발언 상세 논의 내용

컴포넌트 만들면서 고민이 되거나 힘들었던 점 있었나요?

대엽 : 테스트 커버리지를 어디까지 높여야하는지에 대한 고민이 있음. 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) 추가가 필요한데 권한이 없음. 권한 요청으로 모두 설치 완료