김희석

• 협업방식
  • 깃 이슈와 칸반보드를 사용해서 팀원들이 현재 어떤 일들을 하는지 알 수 있어서 좋았습니다.
  • 1명 이상의 승인을 받아야 머지가 되도록 하였습니다.
  • 머지를 할때 자신이 작성한 코드를 간략하게 설명하는 시간을 가졌지만 바쁠때는 못해서 아쉬웠습니다.
• 팀 리뷰
  • 모두 책임감 있게 맡은 기능과 페이지를 구현해서 좋았습니다.
  • 기능 구현을 하면서 어려운것이 있거나 잘 안되는 부분은 바로바로 말 할 수 있는 분위기가 좋았습니다.
  • 기능 구현에 초점을 맞추다보니 코드리뷰에 대한 시간이 많이 부족했던거 같습니다.
• 개인 리뷰
  • 리엑트의 훅과 타입스크립트에 대해서 공부가 많이 되었습니다.
  • 리코일을 사용해보고 싶었지만 시간이 부족해서 못적용해본게 아쉬웠습니다.
  • 기능 구현에만 치중했어서 조금 아쉬웠습니다.

정찬욱

• 협업방식
  • github의 칸반보드를 이용해 각자 현재 진행중인 일을 이슈로 발행해 확인할 수 있게 해서 팀원들이 무엇을 하고 있는지 알 수 있었습니다.
  • 각자 할 일을 다같이 정하고 정해진 기간동안 그 일을 수행해서 PR을 날리고 팀원들이 승인해 후 머지하는 방식으로 진행했습니다.
  • 혼자 해결하기 어려운 부분은 팀원들에게 도움을 요청해서 같이 해결했습니다.
  • PR리뷰를 꼼꼼하게 하면서 팀원들의 코드를 분석해보는 시간을 가졌으면 좋았겠다는 생각이 들었습니다.
• 팀 리뷰
  • 각자 책임감있게 본인이 구현해야하는 기능을 잘 마무리 지었고 결과적으로 기능이 다 잘 작동해서 어느정도 만족스러운 팀 프로젝트였던 거 같습니다.
  • 멘토님 말씀대로 일부러 충돌을 좀 내보면서 오류 해결을 다같이 해보는 시간을 가졌으면 어땠을까 하는 생각이 들었습니다.
  • 문서화 혹은 기록을 제대로 못해서 아쉬웠습니다.
• 개인 리뷰
  • 타인의 눈치를 보지않고 좀더 적극적으로 임했으면 어땠을까 하는 아쉬움이 남았습니다.
  • 지금까지 안써본 기술을 적용해서 학습적으로 도움이 되게끔하면 좋았을 거 같습니다.
  • 어떻게 렌더링이 일어나고 있는지 정확하게 알지못한 상태에서 구현하다보니 최적화를 제대로 못한 거 같습니다.
  • 다른 사람이 작성한 코드를 유심히 읽는 자세가 부족했습니다.
  • 지금까지 배웠던 내용을 제대로 적용해보지 못해서 아직 많이 부족하다고 느꼈습니다.

이찬

• 협업방식
  • 깃허브 액션으로 이슈발행 및 칸반보드 생성, 슬랙 연동등등 업무 프로세스를 상당부분 자동화하여 협업 능률을 올렸던 점이 인상 깊습니다.
  • 한가지 이슈가 발생했을 때 팀원들이 모두 논의해서 문제를 해결하는 방식을 채택했습니다. 의견충돌이 최대한 나지 않는 방식이기는 하지만, 거의 동기적으로 소통을 해야하고, 비동기적으로 소통을 했을 경우에는 문제 해결이 더뎌지는 문제가 발생했습니다.
  • 업무를 초반에 분배 해놓고 각자 맡은 업무를 해결하는 방식으로 협업이 진행되었습니다. 각자의 업무에 책임감을 가질 수 있었던 것 같습니다.
  • 프로젝트에 관련된 것들을 최대한 문서화했습니다. 이를 통해 꼭 필요한 비동기적 소통만 슬랙을 통해 할 수 있었으며, 그 외의 것들은 문서를 찾아보는 식으로 비동기적 소통의 비용을 낮췄습니다.
• 팀 리뷰
  • 전반적으로 리뷰에 대한 문서화가 이루어지지 못했습니다. 별도의 코드리뷰 작성없이, 대부분 체크인과 체크아웃시에 서로 작성한 코드를 실시간으로 공유하면서 머지를 시켰습니다. 실제 업무환경에서는 비동기적으로 코드리뷰가 진행되는 부분도 있을 것이므로 이에 대한 연습 또한 했으면 어땠을까 하는 생각이 듭니다.
  • 너무 컨플릭을 두려워하면서 작업을 했던 것이 아닌가 싶습니다. 이 프로젝트는 상기했듯 연습의 목적도 존재했으므로 컨플릭을 두려워 하지 말고 작업을 과감하게 해서 협업툴과 친해지는 기회를 마련했었으면 어땠을까 하는 생각도 돌이켜보니 듭니다.
  • 팀원들의 인성이 좋았습니다. 서로 모르는 문제를 과감하게 공유하고, 이를 해결하기 위해 함께 고민할 줄 알며, 본인의 과업이 끝나면 상대방을 도와주러 달려가는 등, 협업의 태도에 대해 돌이켜 볼 수 있게 만들어줬습니다.
• 개인 리뷰
  • 너무 MVP개발을 했던 것은 아닌가 하는 생각이 듭니다. 제품 개발이라는 측면에서는 상관이 없을 수도 있지만, 교육과정 안에서 진행했던 프로젝트이므로 조금 더 개발속도가 느리더라도 품질 향상에 대한 고민이 필요했을 수도 있겠다는 생각이 듭니다.
  • 계속적으로 언급하게 되지만, 학습의 목적 또한 있었던 프로젝트였으므로 평소에 써보지 못한 기술에 대한 과감한 적용 또한 필요하지 않았었나 싶습니다.(ex. customHook)
  • 타인의 코드에 대한 관찰이 상대적으로 부족하지 않았나 싶습니다. 프로젝트 막바지에 이미 만들어져있는 코드를 재활용하는 과정에서 타인의 코드를 들여다 보는것이 중요하다는 사실을 비로소 몸으로 깨닳았습니다.

이종현

• 협업방식
  • 팀원 분들 모두가 각자 맡은 일(API, 공통 컴포넌트, 페이지 구현)에 최선을 다했던 것 같고, 팀에서 정한 시간에 맞춰 일을 완수 하여서 시간에 쫓기지 않고, 큰 이슈 없이 프로젝트를 마무리 할 수 있었던 것 같다.
  • 각자 페이지를 구현 한 이후 본인이 맡은 부분에서 생긴 이슈, 버그, 에러를 알아서 잘 해결하고 PR을 올리면 빠르게 머지하면서 프로젝트를 진행 하였는데, 프로젝트가 진행되면 될수록 팀원분들의 코드(코드 리뷰) 보다는 문제가 해결되었는지에 집중이 되었던 부분이 조금 아쉬웠던 것 같다.
• 팀 리뷰
  • 팀원분들 모두 피그마에 정리된 디자인 시안에 95%이상의 싱크로율로 구현해주셨고, 이러한 실력을 바탕으로 디자인이 정말 잘 나온 것 같아 뿌듯하고 이쁘다고 생각이 들었다.
  • 잘 모르고 잘 안되는 부분들이 많은데 팀원분들께 여쭤보면 항상 흔쾌히, 그리고 본인이 하던 것을 바로 멈추고 최선을 다해 함께 고민해주고 해결해 주려 하시는 분들이라서 너무 좋았던 것 같다.
• 개인 리뷰
  • 리액트에서 아마 가장 많이 쓰이는 메소드라고 생각이 드는 useState와 useEffect만을 이용하여 구현을 하였던 것 같은데, 이러한 메소드가 왜 필요하고 어떨 때 사용하여야 하는지 100% 이해하지 못하고 구현한 후 동작이 되면 그걸로 끝 이였던 것 같다. 프로젝트가 끝나고 마지막 프로젝트가 시작되기 전 리액트와 타입스트립트에 대한 이해도를 좀 더 끌어 올리기 위해 개인적으로 시간을 할애하여 공부를 좀 더 깊게 해야 할 것 같다.
  • git저장소에 머지 된 dev브랜치의 코드를 pull 받은 뒤 구현을 위해 생성한 브랜치로 이동하고 코드 구현을 하는 도중 다른 내용이 dev브랜치에 머지 되었을때 어떤 방식으로 내가 작성 중인 코드를 중단 하고 pull을 받아야하는지 이론적으로 아직 머리에 적립이 되지 않은 것 같아서 git에 대한 이해도를 좀더 올리기 위해 공부를 좀 더 해야 할 것 같다.

송인재

• 협업 방식

  • 처음에 정해야 할 사안들을 미리 회의를 통해 모두 정해놓고 개발을 시작하는 방식으로 이루어졌다. 그리고 필요한 사안들이 생길 때, 다시 회의를 통해 진행했다.

  처음에는 모든 것들을 최대한 정해놓고 하는 방식이 시간이 오래걸릴 것 같다고 생각했는데, 프로젝트 시간을 단축시키는데 큰 기여를 한 것 같았다. 물론, 하나의 회의로 모든 상황들을 예측할 수는 없지만 정할 수 있는 사안들은 미리 정해놓고 시작하는 것이 흐름을 깨지지 않고 좋은 방식인 것 같다.

  • 깃허브 한 곳에서 칸반보드를 작성하고 할 일들을 정리하는 방식이 효율적이었던 것 같다. 여러 협업 프로그램들을 동시에 사용하지 않는 것이 좋은 것 같다.

• 팀 리뷰

  • 전에도 프로젝트를 해봤었지만 이번에가 정말 협업 프로젝트를 한 기분이었다. 하나의 문제가 생겼을 때, 다함께 토론하며 얘기하고 서로의 문제에 대해 관심을 가지고 이야기하는 것이 하나의 팀이라는 인식을 새겨주었던 것 같다.

  다만 문제가 생기지 않았을 때 즉, 문제없이 잘 돌아가는 코드에 대해서는 리뷰가 부족했던 것 같다. 우선 이 부분은 스스로가 가장 부족했던 것 같다. 문제없이 잘 돌아가는 코드에도 좀 더 관심을 가지고 코드를 봤다면 조금 더 서로의 실력 향상에 도움이 되지 않았을까하는 생각이 든다.