프로젝트 기간 내 진행되는 멘토링 일지 관리
1월 7일 토요일 오전 10시
- 피그잼 공유
- 주제 설명: 자서전 SNS
- 화면 흐름 공유
- 공통으로 사용되는 컴포넌트 단위 / 페이지 단위로 역할을 나눌 수 있음
- 글로 태스크가 나열되어야 함
- GitHub Project의 칸반보드를 활용해보자.
- PR 본문에 #issue_number 링크 추가하기
- issue에는 스펙에 대한 문서 작성
- 스프레드시트가 굳이 필요할까 싶다. 기능에 대한 정의가 한 곳에 한번만 되고 스펙을 파악할 수 있게 하는 게 좋다. 기획 문서가 변경될 경우 언제 어떤 부분이 업데이트되었는지 체크해놔야 한다.
- 일을 잘하는 것에 대한 영역이기도 함. 많이 시도해보고 연습해보면 좋을 것 같다.
- 각 태스크별로 몇 MD가 들어갈지를 봐야 한다.
- 한 태스크별로 5시간(MD) 내 끝낼 수 있는지를 확인해야 한다.
- 다섯 명의 개발 역량과 들이는 시간 차이가 크게 나지 않을 것 같으니 똑같이 몇 MD가 필요한지 나열해본다.
- 마감일까지 각 태스크를 간트 차트에 배치해본다.
- 태스크의 우선순위와 순서를 정해야 한다. 태스크 나열에 시간을 너무 많이 쓰면 안 된다.
- 유동적으로 조절하되 기간을 단축하는 방향(연장 X)으로 진행해야 한다.
- 우리 서비스의 핵심이 되는 기능을 한 가지씩만 정해서 이야기를 해봐야 한다.
- 각자 생각하는 핵심 기능이 다를 수 있다. 그 중 한두 가지에만 집중해야 한다!
- e.g. 일대기를 나열하는 게 중요, 다른 사람과 공유하는 게 중요, 사진을 편하게 업로드하는 게 중요하다 등
제목 맨 앞에 [5MD]처럼 prefix를 붙여봐도 좋다.
기획단계에서는 Project에 정리하고 작업할 때 칸반보드로 정리하면 된다.
예상 시간보다는 MD로 산정하면 된다.
- 마감일 2~3일 전까지는 모든 기능 개발 완료 후 실제 배포를 해야 한다. 멘토님이 체크해주실 예정!
- 로컬이 아닌 실제 환경에서 배포하면서 생기는 문제를 미리 경험하고 대처해보는 게 좋다
- 더미데이터를 넣고 테스트, 발표할텐데 같은 사진과 텍스트로만 보여주면 서비스의 완성도가 좋아보이지 않는다. → 발표 시 실제 서비스 사용자라고 생각하고 적합한 데이터를 넣어서 테스트해봤으면 좋겠다.
- 본인이 MD를 초과해서 작업을 하더라도 다른 사람이 MD 이상 하지 않는 것에 대해 불만을 표하면 안 된다.
- 어차피 면접 때 이 프로젝트의 전반적인 코드를 설명할 수 있어야 한다(본인이 담당하지 않은 부분이더라도). 그만큼 프로젝트를 이해하려면 시간을 많이 투자해야 한다.
- 스크럼
- 끝 스크럼을 할 경우에는 내일의 업무 내용이 마지막 스크럼에 정리되어 있어야 한다. 5분 안에 끝낸다. → 퇴근시간에 회의를 잡는 느낌,,
- 스크럼 때는 한 일과 할 일 공유만 하기
- 회의 시간에는 미리 안건을 정하고 해당 안건에 대해서만 이야기한다. 문서화를 잘 해야 한다. 회의 시간을 줄이고 개발 시간을 확보해야 한다.
- 팀장님은 스크럼 시간에 각 팀원들의 업무 흐름을 전반적으로 파악해야 한다.
- 나머지 팀원들은 팀장님께 업무 현황을 잘 전달해야 한다.
- 태스크가 지연되는 상황이 발생할 경우 지연되는 원인이 무엇인지, 같이 해결할 수 있는 것인지 등 논의할 수 있는 환경이 만들어져야 한다.
- PR 코드리뷰 반드시 진행하기!
- 코드 내용을 검증한다기보다는 어떤 흐름으로 개발을 했고, 어떤 기술을 사용했는지 등을 확인하기 위함
- 코드리뷰 시 확인할 사항과 기준을 찾아보고 이를 따라 진행해도 좋다.
- 코드리뷰를 하는 회사에 가면 어떻게 코드리뷰를 해야 하는지 알려주지 않음,, 미리 코드리뷰를 하는 연습을 해보면 좋겠다. 코드리뷰 자체가 중요하고 많은 시간을 들이게 되는데 절대 낭비되는 시간이 아니다.
- 기능이 제대로 동작하는지를 확인하는 것까지 원래 코드리뷰의 영역이다.
- 배포되는 브랜치에는 프로젝트가 깨질 가능성이 있는 코드를 직접 머지해서는 안 된다. 동작하는 코드만을 머지해야 함!
- Git 전략
- main - develop - feature
- feature → develop 머지
- 배포 시 develop → main 머지 (결국 배포는 한 번)
만약 위 방식이 아니라 아래처럼 배포를 여러 번 하게 된다면
배포 자체가 안정적이라면 main 브랜치가 없어도 됨
git-flow
gitlab-flow
github-flow
프로젝트의 성격에 따라 정해져야 한다. 연습용이더라도 굳이 필요하지 않을 수도 있다
- 논쟁할 거리가 생길 경우 팀장님이 잘 조율해주세요..ㅎㅎ 인간적으로 비하하지 말고 생산적으로 진행할 수 있길
1월 11일 수요일 오후 5시
- 진행상황 공유
- 이번 주에 전체 기능의 70%는 마무리해야 함
- 합의한 MD에 맞춰서 진행하고 있는지?
- 좀 더 하게 됩니다..ㅎㅎ
- MD는 식사 시간은 빼고 휴식 시간을 포함해서 산정한다. 회사 생활에 대입해서 생각해보면 된다.
- 회사에서 MD를 물어보면 너무 짧게도 길게도 잡지 말자
- 자신의 능력을 알아주길 기다리기보다는 어필할 줄 알아야 한다..!
→ 1MD에 처리하는 작업량이 어느 정도 되는지 파악해보자
- 기업 스토리
- 시간이 되면 성능 개선도 해보자
- 공통된 컴포넌트가 많이 나열되었을 때 성능을 측정해보고 느려진다면 개선해보자
- lazy loading 등 여러 최적화 기법 찾아보고 적용해보자
- 프로젝트는 리뷰를 해주시나요? → 필요하면 같이 봐도 좋을 것 같다
- 프로젝트 리뷰
- 태스크 관리 잘 되고 있는지 점검
- vite 써보니까 어떤지? 2022년에 매우 인기 많았음! 프로덕트 레벨에서 쓰일 수 있을지에 대해서는 검증이 안되긴 했지만 성능 좋음
- 타입스크립트는 어떤지?
- 쉽지 않네요,,
- 타입을 사용할 거라면 as나 any 사용을 지양하자
- 안전하게 코드를 작성하기 위함이므로!
- 코드 전반적으로 리뷰해주셨습니다! 멘토님 감사합니다
- 인터페이스를 따로 분리한 이유?
- 사용하지 않는 인터페이스는 아예 적지 않아도 됨
- API 통신을 할 때 컴포넌트와 직접 하지 않는 방법도 있음 - 클린 아키텍처를 추상화해서 적용해봐도 좋을 것 같다. 외부 API가 변경되더라도 내부 컴포넌트가 크게 변경되지 않도록 중간에 레이어를 두는 방식을 고려해보면 좋겠다.
- react-query
- 시니어 개발자들이 아키텍처를 결정하고 구성하게 되는데 아직은 이르지만 아키텍처를 고민해보고 프로젝트에 적용해보면 좋겠다.
- PR별로 배포해봐도 된다. 온전히 서비스가 되는 상태일 때에만 머지가 되도록 한다. 빌드 자동화를 해놓으면 편리하다.
- CI/CD 도구: github actions → 제일 편하고 직관적임! 문서도 잘 되어 있다. push, merge할 때마다 검증할 수 있음.
- 타입스크립트 공부 방법
- 책(이펙티브 타입스크립트, 러닝 타입스크립트(최근 출간)), 인터넷 강의
- 제대로 활용하고 있는지 의문이 들어도 일단 계속 공부는 한다
- 프로젝트에 적용해보면서 다른 분들의 코드를 참고하고 스타일을 따라함
- 타입스크립트 릴리즈 노트의 새로운 키워드를 공부하면서 업데이트하는 게 좋다!