1. 페어 프로그래밍 관련 질문
멘토님께서는 한달간 진행할 프로젝트에 페어 프로그래밍 방식을 적용해보는 것에 대해 어떻게 생각하시는지 궁금합니다!!
개발이 끝나고 부족한 코드부분을 개선하거나 리팩토링 할때, 서로의 코드에 대해 Sync를 맞출 때.
페어프로그래밍시, 코드에 대해 한번에 논의 한다. “저 이렇게 코드짰고,,,”, “같이 추상화해볼까요? “(이런 방식으로)
페어 프로그래밍 보다는 개인적으로 기능 개발하는 시간이 많을 확률이 높다.
제가 생각한 장점
- 같은 화면을 보면서 개발하기 때문에 동료가 작성한 코드의 맥락을 함께 이해할 수 있다는 장점과
- 서로 알고있는 지식을 공유하면서 함께 성장하기에 적합한 방법이라고는 생각되고는 있습니다.
제가 생각한 단점
- 그러나 한편으로는 두 사람이 같은 기능을 동시에 맡게 되는 것이니, 한정된 기간 안에 기능을 빠르게 구현하기 위한 과정과는 멀어지는 느낌이 있고
- 시공간적으로 함께 있어야 하다보니 제약사항도 존재할 것 같습니다!
궁금점
- 이번 프로젝트에 페어 프로그래밍을 적용해보기에 적합할까요?
- 적용해본다면, 어느 정도의 빈도로 페어 프로그래밍 방식을 적용해봐야 할까요?
- 저희 팀이 5인으로 홀수이다보니, 한 명이 짝꿍이 없는 상황이 나올 수도 있을 것 같은데 어떻게 해야할까요? 😂
- 짝을 만들 때 어떤 기준으로 정해야 효율적일까요? ex) 수면 패턴, 개인의 강점, 성향 등등..
2. 코드리뷰 방법 관련 질문
짧은 기간 안에 프로젝트를 완성해야 하다보니 각자 작업한 내용을 서로에게 컨펌 받기 위한 적절한 방법이 있을지 궁금합니다!
(우선 저희가 생각한 것은 최소 1명의 approve를 받으면 merge할 수 있다. 정도 였습니다.)
너무 코드리뷰의 비중이 커져도 기능 개발에 집중하지 못하는 일이 생길 수도 있을 것 같고,
그래도 최소한의 코드리뷰는 있어야 자신이 발견하지 못한 문제를 동료가 찾아줄 수 있다는 점이 있을 것 같긴 한데 어느 정도가 적정선일까요?
코드리뷰로 인해 블로커가 되면 안된다. 급하거나 꼭 해야되는 사항이면 self merge 하고 사후리뷰를 하면 좋다.
(부가내용: 코드리뷰의 양을 줄여서, 리뷰하는 사람들의 집중력을 높일 수 있다.
코드리뷰 하는 시간을 미리 협의하여, 빠르게 진행하는 방법도 있을 수 있다.)
3. API 요청 관련 반복 로직
저번 주 커피챗 질문에서 시간 관계상 호수님의 API 관련 질문을 다음 시간으로 연기하게 됐었는데요!
저도 궁금한 내용이어서 좋은 의견을 공유해주시면 감사하겠습니다!