팀 활동 기록

08/09

팀 이름

• 차카니
• 문방구에서 파는 음식 중에 제일 맛있다는데 다들 공감함

한 일

• 간단한 자기소개

할 일

1. 그라운드 룰, 깃헙 세팅, 코딩 컨벤션 등
2. 사용할 툴, 기술
3. 애자일 프랙티스가 뭔지 학습, 공유
4. -> 어떤 식으로 일정을 잡을지도 어느 정도 나올듯?
5. 기획서 만들어보기 시작 (+디자인, 기능도 나중에 다시 상의할 필요 없을 정도로 상세하게)
6. DB 설계 / API

지난 프로젝트에서 느낀점들

저번 프로젝트 때 좋았던 점

• 베이스코드를 같이 짜두었더니 기능별로 개발할 때 생산성이 좋았다. 생각하는 방향도 같아졌고, 나중에 다시 상의하기도 좋음
• 잘 모르는 부분(백엔드, 배포 등)을 우선적으로 개발해서 불확실성을 줄였던 것.
• 하고 싶은 것, 해보고 싶은 것 자유롭게 해보고 무엇을 어떻게 했는지 팀원들과 공유

아쉬웠던 점

• 코드리뷰를 상세하게 하려고 했었는데, 뒤로 갈수록 잘 지키지 못했었음
• 결과 vs 과정 / 일관성 있게...
• 베이스 코드 짤 때 충분히 의견을 교환하지 못했던 것
• 베이스 코드를 짤 때 서로 이해할 수 있게 짰었으면 좋았을 것 같다.
• 이전 프로젝트들보다 나아진 점이 없는 것 같은 느낌? / 남은 게 없는 것 같은? / 목표가 명확하지 않았던 것 => FE 개발자로서의 고민 / 기술적인 목표를 잡고 해봤으면 / 기능구현 외의 예) 테스트 코드를 잘 작성 / 데이터 페칭에 있어서 예외, 오류 처리를 정말 잘 해본다든지 -> 기획서 단계에서부터 고민해보고, 기획에 포함해보기

팀의 우선적인 가치 / 슬로건 / 공통의 목표

• 우선적인 가치: 기능보다는 퀄리티

• 공통의 목표: 깔끔하고 견고한 코드

• 기능은 제한한다

• 기능 하나를 구현하더라도 테스트코드, 예외 처리 등 잘해서 견고한 코드를 짠다.

• 리팩토링은 시간을 따로 내서. 나중에 해야지하면 안하게 됨..

• PR 올리기 전에 체크리스트 같은 것을 세부적으로 (예시: 메서드의 깊이가 1인가? 등등). 셀프 리뷰같은 느낌?

• 적어도 서로가 짠 코드가 무엇을 하는지는 알 수 있을 정도로 공유하고, 리뷰하기. (그만큼 코드도 남들이 읽어도 이해할 수 있게 짜기?)

그라운드룰

• 개발 집중시간 (코어타임: 슬랙/게더는 들어와있지만 카메라, 마이크는 꺼두고 개발에 집중. 다만 모르는 것 있거나 할 때는 자유롭게 말)
  • 09:30 ~ 11:30 / 13:00 ~ 18:00 (이후로는 자유롭게)
  • 화, 목에 수업 끝나고 30분 정도 모여서 가벼운 이야기 (친해지기)
• 의사 결정은 서로 충분히 이야기하되 너무 길어지지 않게
  • 주장을 하고 싶은것이 있다면 근거를 토대로!
  • 결정을 미루고 싶다면 미룬 사람이 다음 회의까지 자료든 뭐든 준비해서 설득
  • 자기 의견과 다른 방향으로 정해져도 기분좋게 따르기
• 말, 행동, 코드리뷰에 prettier 적용하기
  • 의문형이나 청유형으로.. 이런건 어때요? 제 생각은 이런데..
  • 코멘트에 이모지 하나씩은 달기 😄
  • 기분 나쁘게 말하고 듣지 않기
• 불만이 있다면 담아두지 않기 (스크럼, 티타임, 언제든 이야기해도 좋음)

깃 룰

커밋

• 작은 단위로 하려고 노력합시다! 리뷰어를 배려하는 커밋
• ${prefix}: 내용은 한글로 작성
  • 설명은 필요한 경우에
• Prefix
  • add: 기능을 만들 때 필요한 작은 요소들 (스타일링, 일부 로직.. 등)
  • fix
  • docs
  • wip: 아직 작업 중일 때
  • chore

브랜치명

• ${prefix}/브랜치명 (feat, fix, docs, chore)
• 이슈를 발행할 때 브랜치명도 같이 정하기

이슈 형식

• 공통적으로 들어갈 내용: 브랜치명, 예상시간
• 이슈 내용은 자유롭게 쓰되 다른 사람도 충분히 이해할 수 있도록
• 이슈 발행을 어떤식으로 할지는 애자일, 기획서 등 나오면 다시 이야기하기

PR

• 제목: [#이슈번호] 설명
• 공통적으로 들어갈 내용: 관련 이슈, 실제 소요시간
• 내용은 이슈와 마찬가지로 자유롭게, 설명도
• 연결된 이슈 등록 가능

코딩 컨벤션

• webpack, babel 같이 세팅
• eslint 기본값으로 우선 설정. 하다가 불편한 점이나 추가하고 싶은 룰 생기면 바꿔나가는 걸로.
• prettier(formatter)도 세팅
• TS 설정
• 변수명(camelCase), 컴포넌트 파일명 / 클래스(PascalCase), 컴포넌트가 아닌 파일명(리액트: camelCase / 서버: kebab-case)

사용할 툴 / 기술

• 협업: 웬만하면 게더에 있고, 잘 안 되면 슬랙 통화로
• 팀 채널로 소통
• 문서 정리: Github 위키
• React + styled components (2주차부터는 만든 라이브러리로 전환) + TypeScript
• Mobx: 아키텍쳐가 자유로운 편. 규모가 작을 때 (간단하게 만들 때?) 좋았음.
• Recoil: useState같은 기본 훅이랑 비슷하게 사용할 수 있음. 단점은 아직 불안정하다는 것?
• Redux: 구조가 정해져있어서 프로젝트 규모가 커졌을 때 좋았던 것 같다. 비동기 처리할 때 saga, thunk 같은 것 쓰는게 불편
• useSWR: data fetching할 때 사용하는 도구(?)
• 상태관리 라이브러리는 기획하면서 아키텍쳐를 고민해보고, 라이브러리 관련해서도 좀 더 조사해보고 정하는 걸로
• 테스트: jest (react-testing-library)

내일까지 각자 공부하고 공유해서 의사결정에 도움주기

• 애자일 (공통으로 각자 서칭)
• 아래는 각각
• 주영: 테스트 전반 (라이브러리, UI 테스트는 어떻게 해야되는 건지 등)
• 진우: Recoil, Mobx
• 태형: Redux, zustand
• 상인: react-query, useSWR

추가로 할만한 것

• 환경세팅 같은 것 미리 알아보기: eslint, prettier, webpack, babel, TS, testing 등등