발표 / 회고
- 발표 톤은 안정적이고 좋은데, 소리가 너무 작고 중간중간 노이즈 및 말 소리에 비해 너무 큰 소리가 끼어 들어서 영상 시청이 많이 불편했어요. 🥲 향후 영상으로 제출해야 하는 과제물이 있다면 여유 시간을 가지고 녹화 전 / 제출 전 자가 체크를 해보시면 좋을 것 같습니다.
- 적은 시간 내에 Context API에 익숙치 않아서(?) 익숙한 redux를 사용했다고 하셨는데, 이 부분이 살짝 부자연스럽게 느껴져요. 절대적인 러닝 커브만 놓고 비교해봤을 때도 Redux가 Context API보다 훨씬 높은 편이고 발표 중 말씀하시는 내용 그대로 Redux에서 요구하는 스트럭처로 인해 작성해야 하는 코드 분량은 몇 배씩 늘어나는 반면 정작 그만큼 사용되지는 않기 때문에 이번 프로젝트에서는 Redux를 선택한 부분이 미스 매칭이 아니었을까 하는 생각이 듭니다. 이건 익숙하지 않으니까 익숙한 것을 사용하자!는 식으로 결정하기보다는 라이브러리와 프레임워크 선택에 있어 합당한 근거와 이유를 가지고 선택하는 편을 권장해드립니다.
- 특히 업무의 분배에 관해선 드리고 싶은 말이 많은데, 다 쓰기엔 너무 길어질 것 같네요. 아마 이번 프로젝트에서 직접 겪어보셨겠지만, 팀원이 세 명이라고 해서 4:3:3 같은 비율로 업무를 분담하기는 굉장히 힘든 일입니다. 특히나 팀원 간 실력 차이가 많이 발생할 경우 이 격차가 더욱 커질 수 있는데, 이 경우는 업무를 분해하고 각 팀원의 상황과 수준을 고려해 그에 알맞는 난이도, 분량을 담당할 수 있도록 관리하는 게 협업의 포인트가 아닐까 싶습니다.
GitHub
- 근 한 달 정도 진행한 팀 프로젝트 치고는 절대적인 커밋 수가 너무 적어 보이는데요. squash merge를 적극적으로 활용해서 그런 건가?를 고려해봐도 그렇지는 않은 걸로 보입니다. 그런데도 LOC는 어느 정도 비등한 분량인걸로 봐서 이 경우는 하나의 커밋이 너무 많은 분량을 포함하고 있기 때문이라고 추측됩니다. 커밋 하나가 하나의 범위만을 다룬다면 그에 따라 커밋의 수도 자연스럽게 늘어나기 마련이니까요. 커밋을 진행하기 전에 어떻게 하면 커밋을 의미 있게 유지할 수 있을지 고민하면서 커밋을 이어나가시면 좋을 것 같습니다.
master와production의 경계가 모호한 느낌이 들어요. 아마 현재 배포를 진행하고 있는 branch가production이라고 생각되는데,production이라면 가지고 있어야 할master의 내용을 가지고 있지 않고,production의 커밋 로그를 보자니master에 들어가야 할 내용이production에만 남아 있는 모습입니다.branch의 life cycle을 더욱 엄밀히 지켜주시면 좋을 것 같습니다.
