동영 1팀 중간 점검

1. main 브랜치의 최신화가 너무 뒤쳐저 있어요. 팀 차원에서 중간 발표와 최종 발표를 기점으로 코드를 통합한다는 규칙을 세워둔 걸 수도 있지만, 코드 통합은 부담이 되지 않는 한에서 자주해주는 편이 좋습니다. (너무 자주 하면 귀찮고, 너무 미뤄서 하면 고쳐야 할 일이 한 번에 밀려오거든요)

2. main 브랜치가 너무 오래된 상태라 develop 브랜치를 확인해봤는데 에러가 발생하고 있어요. PR을 올리기 전에 잘 작동되는지 확인한 뒤에 올리고 계신 게 맞겠죠...?

3. 철학자 니체가 남긴 말 중에 "Everything that one thinks about a lot becomes problematic"(많이 생각하는 모든 것들은 문제가 된다)이라는 말이 있습니다. 어떤 속성을 props로 받아야 할지 모르겠다면 일단 당장 필요한 것부터 넣어서 사용할 수 있게 만들어 보세요, 그게 MVP의 시작입니다.

4. 원래 프로젝트라는 게 마감 기한이라는 게 있다 보니 항상 어느 정도 촉박함(?)은 있기 마련이지만, 일정에 쫓기는 생각이 든다면 우선 순위가 낮은(중요도가 낮은), 지금 당장 필요하지 않은 기능은 뒤로 미루거나 과감하게 제거해버리는 결단도 필요해 보입니다.
1. 현재 repository를 보니 storybook을 적용하고 계신 것 같은데, storybook 사용에 들이는 시간 대비 얻을 수 있는 효용성이 떨어진다면 가장 쉽게 포기할 수 있는 부분이 storybook 같은 문서화 도구라고 말 할 수 있을 것 같네요.

5. '무엇'을 '어떻게' 하는지도 중요한 내용이지만, '왜' 하는지도 고민을 해보시면 더 좋을 것 같습니다!

6. 궁금하거나 막히는 부분이 있다면 언제든지 질문해주세요.

프로젝트를 학습하는 과정의 하나라 생각했을 때에도 기한 엄수가 하나의 문제를 깊게 파는 것보다 더 중요하게 생각되어야 할까요? 기한 엄수를 통해 저희가 배울 수 있는 것에는 무엇이 있을지 궁금합니다.

MVP를 설정하는데에 실패했다고 느끼는데, MVP를 설정하는 꿀팁이나 이를 설정하는 방법? 같은 구체적인 방향이 있을까요?

API에서의 예외처리를 공통적으로 처리해주는 로직이 있는지? 아니면 각 status 마다 다르게 처리해주는 식으로 전부 try, catch 해주어야하는 지 궁금합니다.

개발의 전체 흐름에 대한 이해가 없다 보니 이 단계 다음에 어떤 단계가 와야 하는지 감을 잡기가 어려운 것 같습니다. 현업에서 신입들은 개발 프로세스에 대해 어느 정도 이해하고 있어야 할까요? API를 이용한 기능 요구사항이 있을 때 혼자 힘으로 뚝딱 설계할 수 있을 정도는 되어야 하는 걸까요?

리아 매니저 피드백

발표 영상

• 소진님의 자신감있는 목소리와 톤은 매우 좋았습니다!
• 다만 문장 끝 '다'에 힘을 주거나 톤을 확 내리는 경향이 있어 이 부분을 조금씩 교정해나가면 좋을 거 같네용.
• 조금 더 호흡을 빠르게 가져가도 좋을 거 같아요~

• 이 프로젝트가 어떤 프로젝트인지 먼저 언급하는 발표 구성이 좋았어요. 다음 기술적인 것들을 볼 때에도 머릿속으로 그릴 수 있었어요.

• 주요 기능을 텍스트로만 보기에는 다소 복잡하겠다는 생각이 먼저 드네요.

• UI가 넘 맘에 드네요.....

• 명확하게 진척도를 볼 수 있는 발표였어요.

회고록

• KPT 회고를 잘 이용한 팀인 거 같아요.

• 다만 한 사람에게 일이 몰려있는 건 아닐까? 라는 생각이 들었어요. 일이 몰리지 않았더라도 한 사람에게 어떤 부담이 되는 일이 주어진 걸까? 어떻게 개선하면 좋을까? 다음 프로젝트에는 어떻게 임해야겠다! 라고 최종 회고 때 스스로 깨닫길 바라봅니다.