멘토링 일지

프로젝트 기간 내 진행되는 멘토링 내용 정리

1회: 2023/01/07(토) 10시

FigJam 공유

기획서

• 기능에 대한 정의는 한 곳에서 한번에 스펙을 파악할 수 있어야 함
• 기획 문서 변경 시 언제 어떤 부분이 업데이트되었는지 체크
• 우리 서비스의 핵심이 되는 기능을 한 가지씩만 정해보기
  • 각자 생각하는 핵심 기능이 다를 수 있는데 그 중 한두 가지에만 집중하기
  • e.g. 일대기 나열, 다른 사람과의 공유, 사진 업로드

글 형식으로 태스크 정리하기

• 태스크 단위: 공통으로 사용되는 컴포넌트 단위 또는 페이지 단위
• GitHub Issue
  • 제목: [5MD]처럼 MD(Man day)를 prefix로 사용
  • 본문: 스펙 문서 작성
• GitHub PR(Pull Request)
  • PR 본문에 #issue_number 링크 추가
• GitHub Project의 칸반보드 활용

업무 분장

• 각 태스크별로 몇 MD가 소요되는지 고려하고 한 태스크 당 한 MD 내 끝낼 수 있는지를 확인
• 다섯 명의 개발 역량과 들이는 시간의 차이가 크게 나지 않을 것 같으니 똑같이 몇 MD가 필요한지 나열
• 본인이 MD를 초과해서 작업을 하더라도 다른 사람이 MD 이상 하지 않는 것에 대해 불만 표하지 않기
  • 어차피 면접 때 이 프로젝트의 전반적인 코드를 설명할 수 있어야 함(본인이 담당하지 않은 부분이더라도)
  • 프로젝트를 이해하려면 시간을 많이 투자해야 하니 미리 준비한다고 생각하기
• 일을 잘하는 것에 대한 영역이기도 함. 많이 시도해보고 연습하기
• 태스크가 지연될 경우 그 원인이 무엇인지, 같이 해결할 수 있는 것인지 등을 논의할 수 있는 환경이 만들어져야 함

일정 산정

• 마감일까지 간트 차트에 태스크 배치
• 태스크의 우선순위와 순서 정하기. 태스크 나열에 시간을 너무 많이 쓰지 않기
  • 유동적으로 조절하되 기간을 단축하는 방향(연장 X)으로 진행
• 최소 마감일 2~3일 전에는 모든 기능 개발 완료 후 배포 진행하기
• 로컬이 아닌 실제 환경에서 배포하면서 생기는 문제를 미리 경험하고 대처해보는 게 좋음

스크럼

• 끝 스크럼을 할 경우 다음 날 업무 내용이 마지막 스크럼에 정리되어 있어야 함. 시작 스크럼 추천
• 스크럼 때는 한 일과 할 일 공유만 하기(5분 이내로)
• 논의가 필요한 경우 회의 시간을 별도로 확보하고 미리 안건을 정해서 해당 안건에 대해서만 논의
  • 회의 시간 줄이고 개발 시간 확보하기
  • 문서화 중요
• 팀장은 스크럼 시간에 각 팀원들의 업무 흐름을 전반적으로 파악하고 필요한 경우 조율하기
  • 팀원들은 팀장에게 업무 현황 잘 전달하기

코드리뷰

• PR에 대한 코드리뷰 반드시 진행하기
• 코드 내용을 검증한다기보다는 어떤 흐름으로 개발을 했는지, 어떤 기술을 사용했는지 등을 확인하기 위함
  • 원래는 기능이 제대로 동작하는지를 확인하는 것까지 코드리뷰의 영역
• 코드리뷰 시 확인할 사항과 기준을 미리 정하기

Git 전략

• Git-flow, GitLab-flow, GitHub-flow 등
• 프로젝트의 성격을 고려하여 채택
• 배포되는 브랜치에는 동작하는 코드만을 머지해야 함

발표

• 더미데이터를 넣고 테스트하고 발표해야 함
• 서비스에 맞지 않거나 동일한 사진과 텍스트를 보여주면 서비스의 완성도가 좋아보이지 않음
• 실제 서비스 사용자라고 생각하고 적합한 데이터를 넣어 테스트하기

2회: 2023/01/11(수) 17시

진행상황 공유

• 이번 주에 전체 기능의 70%는 마무리해야 함

성능 개선

• 시간이 되면 성능 개선 시도
• 공통 컴포넌트를 많이 나열했을 때의 성능 측정해보고 느려진다면 개선
• lazy loading 등 여러 최적화 기법 찾아보고 적용

프로젝트 리뷰

• 태스크 관리 점검
  • 합의한 MD보다 좀 더 하게 됨
  • MD는 식사 시간은 빼고 휴식 시간을 포함해서 산정(회사 생활에 대입해서 생각해보기)
  • 프로젝트를 하면서 1MD 당 본인의 작업량이 어느 정도 되는지 파악해보기
• 사용하고 있는 기술에 대한 소감 공유(Vite, TypeScript)
  • 참고: The State of JS 2022
• 전반적인 코드 리뷰 진행
  • 타입 사용 시 가급적 as나 any 사용 지양
  • 사용하지 않는 인터페이스는 아예 적지 않아도 됨
  • API 통신
    • 아직은 이르지만 아키텍처를 고민해보고 프로젝트에 적용해봐도 좋음
    • 클린 아키텍처(외부 API가 변경되더라도 내부 컴포넌트가 크게 변경되지 않도록 중간에 레이어를 두는 방식)
    • e.g. react-query

배포

• PR별로 배포해보기
• 온전히 서비스가 되는 상태일 때에만 머지
• 빌드 자동화를 해놓으면 편리함
  • CI/CD 도구 소개: Github Actions
  • 가장 직관적이고 문서도 잘 정리되어 있음
  • 커밋 푸시, 머지할 때마다 검증

타입스크립트 공부 방법

• 책(이펙티브 타입스크립트, 러닝 타입스크립트(최근 출간)), 인터넷 강의
• 프로젝트에 적용해보면서 다른 분들의 코드를 참고하고 스타일을 따라함
• 타입스크립트 릴리즈 노트의 새로운 키워드를 공부하면서 업데이트하기