서로 관련 있는 페이지를 분리하고, 팀 내에서 두 팀으로 나누어 작업하는 방식은 어땠나요?
서로의 코드를 파악하기 위해 PR 만으로 충분했는지, 더 보완했으면 하는 점이나 좋았던 점이 있다면 무엇인지 회고해봅시다.
👍🏻 기능 분리 PR 리뷰
기능개발을 페이지별로 구별해서 각자 전담하고 비슷한 페이지끼리 묶어서 팀을 나누어서 작업을 하였다. 추가로 필요한 페이지나 기능이 필요할 때에는 비슷한 페이지나 기능을 개발했거나 하고있는 팀원이 전담함으로써 이미 해본 기능과 비슷하기 때문에 이해도가 높아서 금방 개발할 수 있었고 시간을 많이 단축할 수 있었다. PR 리뷰도 연관된 페이지나 기능을 개발중인 팀원에게 받음으로써 확실하게 리뷰를 받아서 문제없이 머지할 수 있었다.
👎🏻 기능 분리
비슷한 페이지만 개발하게 되는 부분이 조금 아쉬움이 있다. 개발시간은 단축할 수 있었지만 한 사람이 비슷한 페이지 전체를 개발하다보면 구조와 코드가 비슷한것을 알 수 있다. 프로젝트를 업무적인 측면에서 본다면 빠르게 개발할 수 있었지만 학습적인 면에서 본다면 성향이 다른 페이지도 개발해보았으면 좋은 경험이 되었을 거 같고 시야를 넓게 볼 수 있고 전체적인 프로젝트의 프로세스도 잘 파악할 수 있었을 것 같다.
👍🏻
개발 방식 선정 과정
우리 팀의 개발 방식은 체계적이고 계획적이기 보다는 실전적이었다고 생각한다. 세부적인 개발 방식, 계획들은 개발이 진행되는 와중에 대부분 결정되었다. 나는 우리 같이 경험이 많지 않은 주니어 개발자들에게 이 방식이 아주 적합했다고 생각한다. 완벽하고 체계적인 계획을 세우는 건 불가능에 가깝다. 오랜 시간을 들여 계획을 세웠다고 해도 분명 실천하기 쉽지 않은 내용이었을 것이다. 따라서 직접 부딪혀가며 필요성을 느낄 때 협의 하에 개발 방식을 정한 점이 좋았다.
PR 리뷰
PR 리뷰를 해서 정말 다행이라고 생각한다. 영역을 나누어 개발하다 보니 서러 어떤 코드를 만들고 있는지, 어느 정도의 퀄리티를 유지하고 있는지 확인 할 수 있는 유일한 장치였다. PR리뷰를 통해 컨벤션을 지키고 통일성을 부여할 수 있었다. 이런 장치가 몇 가지 더 있었다면 더 좋았을 것 같다.
👎🏻
기능 분리
사실 기능 분리는 내가 제안했지만 속 시원하게 효과적인 방식이었다고 말하기는 힘들다고 느낀다. 서로 작업하는 영역이 분명하게 분리되어 기술적으로는 좋았지만, 학습하는 입장에서 효과적이었나? 의구심이 조금 든다.
👍🏻
팀 분리
테마 별로 팀을 나누어서 진행했다. 팀을 이루어 진행하니 소통할 때 서로 이미 어느 정도 코드를 이해하고 있었기 때문에 논의가 쉬웠고 결정도 빠르게 이루어졌다.
PR 리뷰
PR 리뷰를 통해 놓치고 있었던 코드 컨벤션을 체크할 수 있었다. 정해 놓은 PR 규칙(구현 내용과 PR 포인트 작성) 덕분에 PR한 코드를 확인할 때 많은 도움이 되었다.
개발