프로젝트 피드백
💻 프로젝트 컨셉 및 기획 의도
- 1차 피드백을 할 때에도 했던 이야기인데, 특정 사용자를 타겟팅 한다는 점에서 얻어갈 수 있는게 많을 것 같습니다.
- 페르소나와 시나리오를 활용해서 프로젝트의 의도를 설명하는 것, 필요성을 설명하는 것이 인상 깊은 점이네요!
- 백로그도 잘 정리되어서 보기 좋습니다.
추후에 여기서 프로젝트의 완성도를 높이기 위해서 해보면 좋은 시도들이 있습니다.
- 테스트 코드를 작성하면 좋겠지만, 테스트 코드 없이 스펙에 대해 직접 테스트를 해볼 수 있으면 좋겠죠?
- 이 때 고민이 필요한 부분은 “스펙에 대한 예제”입니다.
- 즉, 현재 요구사항(스펙)에 대한 예제를 만들고, 이를 실행할 수 있는지 고민해보는거죠.
- 그래서 중요한건 “예제”를 서비스가 제대로 실행할 수 있는지, 이 때 필요한 기능이 적절하게 있는지 입니다.
- 서비스에서 사용자에게 제공하고자 하는 것 (목적) 을 분명히 한 다음에 이를 기준으로 우선순위를 매기는거죠!
- 즉, 이게 없이 우선순위만 있다는건 조금 추상적일 수 있습니다.
✅ 프로젝트 구조 및 설계
- 프로젝트 구조는 전체적으로 깔끔하게 유지되고 있습니다.
- 특히 컴포넌트가 잘 분리되어 있어서 보기 좋네요!
- 다만 컴포넌트 하위에 컴포넌트 폴더가 또 있어서 조금 헷갈릴 수 있지 않을까 싶어요.
- custom hook 같은 경우 아예 hook 폴더 하나에 몰아놓은 상태인데요, 이렇게 하기보단 관심사 단위로 묶어주면 좋습니다.
- 훅이 쓰이는 스코프를 생각해보고, 쓰이는 곳과 가까운 곳에 위치시키는거죠!
- 상수의 경우에도 무조건 const 폴더에 모아놓고 있는데, 스코프를 고려해주면 좋을 것 같아요!
- Query와 Mutation이 분리되어있는데, 이렇게 했을 때의 장단점이 있을까요?
- 가령, 같은 관심사를 다루는 것들의 query와 mutation을 하나로 묶어서 사용할 수도 있을 것 같아요.
- 지금 한 페이지에 쓰이는 query가 여러 개인 경우가 있는데요, 이게 나뉘어져 있는게 정말 좋은걸까? 하는 생각도 해보면 좋아요
- 이런건 백엔드 분들과 협의를 해보면 좋긴 한데요, 메인페이지에서 꼭 두 번에 api 호출을 해야하는 걸까요? 그냥 한 번 요청을 보냈을 때 모든 데이터를 가져오도록 하면 안 되는 걸까요?
- 이건 나중에 커피챗을 할 때 이야기해보는걸로!
🛠️ 기술 스택 및 협업툴
- 기술 스택은 초반에 잘 협의가 되어 좋아보입니다.
- 협업툴은 노션과 깃허브 프로젝트를 잘 사용해주시고 있는 것 같네요!
🗓️ 일정 산정 및 관리 방법
- 일정 산정의 경우, 노션과 깃허브 양쪽에 혼재되어 있는게 약간의 단점 아닌 단점일 수 있답니다.
- 가령, 해당 프로젝트를 포트폴리오로 사용한다고 했을 때 일정을 어떤식으로 관리했는지를 보여주는 것도 좋은 방법인데, 프로젝트를 관전하는(?) 사람 입장에서 조금 헷갈릴 수도 있지 않나 싶어요.
- 그래서 github 내에서 어떤 방식으로 일정을 산정하고 있는지, 백로그를 어떻게 관리하고 있는지, 이런 것들을 작성해주시면 좋을 것 같습니다.
- 요약하자면 일정관리는 잘 하고 있는 것 같지만, 당사자들이 아닌 사람의 경우 이를 트래킹하기가 조금 힘들어보인다는 것. 그래서 우리 잘하고 있어요! 를 어떻게 보여줄지 고민해보면 좋을 것 같습니다.
- 현업에서는 이런게 성과를 관리하는것과 연관지어서 생각해볼 수 있답니다
- 그리고 테스크 하나를 마무리 했을 때 소요시간 같은 것들도 습관적으로 기록해보세요!
- 빠르게 끝났으면 어쩌다 빠르게 끝났는지. 어떤 방법을 사용했는지.
- 느리게 끝났으면 어떤 점들 때문에 힘들었는지. 다음에 어떻게 하면 좋을지.
- 적고나서 찾아보니 이렇게 discussion 에서 관리되고 있었군요!
- 이게 조금 더 테스크 하나하나와 연관되어 기록되면 좋지 않을까 싶어요!
- 최대한 파편화되지 않도록?
🧑🏻💻 기능 구현 및 주요 개발 포인트
- 대부분의 페이지에 가로 스크롤이 항상 존재하고 있어요
- 스크롤이 있는 사람들에게는 꽤 거슬릴 수 있답니다!
- 깃허브나 프로젝트 페이지에 배포 링크를 넣어주세요!
- 배포는… 지속적으로 하고 있는걸까요? 제가 확인할 수 있는 방법이 없네요 ㅠㅠ
- 찾아보니 여기서 확인해볼 수 있군요!
- 현재 페이지의 경로(breadcrumb)가 있으면 좋지 않을까 싶어요
- 뒤로가기만 있는 것 보다, 이 페이지가 어디를 통해서 들어왔는지를 표기해주면 사용자 입장에서 서비스를 이용하기가 더 편하지 않을까요!?
- 다만 경우의 수가 좀 많을 것 같기도 하고..
예시)
- 전체적으로 API 요청이 무척 많은 것 같아요. 중복 요청이 되기도 하고?
- 메인페이지는 위에서 언급하긴 했는데, API를 따로따로 호출할 필요가 없어보입니다!
- 크루 페이지는.. 미친듯이(?) 요청을 많이 하고 있네요.
👥 협업 방식
- 매일 스크럼을 잘 하는 중
- 그런데 스크럼을 의무적으로 하고 있는지, 효과적으로 하고 있는지 점검해보면 좋을 것 같아요!
- 스크럼을 통해서 우리가 어떤 문제를 해결하고자 하는지 리마인드 해보면 어떨까요?
- 노션의 데이터베이스를 이용해서 개인이 현재 담당하고 있는 테스크와 진행 상태를 한 눈에 볼 수 있도록 만들어보면 좋을 것 같아요~
- 개개인에 대한 부하도 한 번 점검해보고?
- 이 외에는 특이사항 없습니다!
💡 기타
피드백 정리
- 코드는 관심사 단위로 묶어서 관리하자
- 우리가 하고 있는 일을 한 눈에 볼 수 있도록 해보자
- 노션에다가 다 표현하거나
- 깃허브에다 다 표현하거나
- 배포 링크나 프로젝트 진행 현황 같은걸 공개된 곳에다가 표기해보자.
- API 요청이 많이 가지 않도록 튜닝 해보자.
QnA
Q) 커스텀 훅을 재활용하는게 아님에도 분류해도 좋은가?
- 관심사 단위로 분리해서 관리하면 좋다.
- 테스트 코드도 작성 가능.
- 컴포넌트 입장에서는 input에 대한 렌더링만 잘 해주면 그만.
- 그니까 input을 만들어내는 과정은 컴포넌트의 관심사가 아니다.
- 과정을 hook으로 분리하고, 결과만 컴포넌트에게 알려주면 끝
Q) 면접관들이 주로 보는 것들
- 코드
- 깔끔하게 작성 되었는지
- 테스트 코드 같은게 있다면, 얼마나 잘 작성 되었는지
- 커버리지는 얼만큼인지
- 효율성을 위해, 생산성을 위해 한 노력들
- 사람이 수동으로 하는 것들을, 기계한테 시키는 작업들 (전환한 것들) 이 있는지
- CI/CD
- PR을 올릴 때 마다 코드에 대한 정적 검사
- 머지가 되면 배포한다거나
- 서비스 자체의 퀄리티
- 정말 잘 만들어진 서비스가 아니라면 굳이 그 완성도를 가지고 잘했따 못했따 라고 이야기 하기가 애매하다
- 프로젝트의 결과물을 가지고 이야기를 하기 위해선, 사용자가 있어야 됨. 그런데 사용자는 없는데 만들어 놓기만 했다 → 의미 없음
- 프로젝트의 완성도를 높이고 싶다면, 정말 실제 사용자의 피드백을 들으면서 프로젝트에 어떻게 녹여냈는지의 과정이 있으면 좋다.
- 장애도 한 번 겪어보고
- 되게 이상한 QA도 처리해보고
- 장애가 발생 했을 때, 버그가 있을 때, 어떤식으로 그 문제를 찾아내서 해결하는지
Q) 이력서에 수치화할 수 있는 것들
- 한 일 / 과정 / 기여도 (영향력)
- 어떤 일을 얼만큼 했는지
- 테스크의 갯수
- 프로젝트에 대한 기여도
- 커뮤니케이션 비용 절감을 위한 노력
- 기존에 회의시간이 1시간 이엇는데, 이걸 개선하기 위해서 어떤 방법들을 썼고, 그랬더니 평균적으로 20분 정도 단축할 수 있었다.
- 테스트 코드를 작성했다면, 커버리지
- 문서를 작성했다면, 전체 문서의 갯수와 내가 기여한 혹은 작성한 문서의 갯수 혹은 비율
- 이런 일들을 통해서 내가 어떤 영향을 줬는지 (긍정적인 영향, 사람들의 동기부여, …)
- 과정 → 간략하게. 어떤 기법을 사용해서 어떤 점이 나아졌다.
- what, why, how, result
- 무엇을 했고
- 왜 했고
- 어떻게 했고
- 결과가 어떤지
- 성능개선 관련
- 성능 개선 전의 상태 (얼마나 최악인지)
- 성능 개선 후의 상태 (얼마나 좋아졌는지)
- 이를 위해 어떻게 했는지.
- 라이트하우스
- 개선 전
- 개선 후
- 어떤 점들이 어떻게 나아졌는지
….