페어 프로그래밍 준비하기
어떻게 해야 페어 프로그래밍을 효율적으로 할 수 있을까?
곧 있으면 우테코가 시작된다!(두근두근..) 하지만 위와 같이 우테코에서 미션을 진행할 때 서로 페어 프로그래밍을 통해 미션을 해결하고 성장한다고 적혀있다. 페어 프로그래밍을 하기 앞서 페어 프로그래밍이 뭔지, 어떻게 진행하는 건지, 또 어떻게 하면 더 효율적으로 할 수 있을지 알아보자!
페어 프로그래밍(Pair Programming)이란?
페어 프로그래밍은 애자일 개발 방법론 중 한개로 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법이다. 코드를 작성하는 사람이 진행자가 되고 다른 한 사람이 관찰자가 되어 코드리뷰를 하며 프로그래밍을 하고 역활은 중간중간 계속 바꾸며 진행한다.
어떻게 진행해볼 수 있을까?
다음 영상을 참고해서 상세한 예를 들며 설명하겠다! 조금이지만 직접 다른 분과 함께 진행하는 과정을 볼 수 있으니 한번 봐보자. (TMI: 우테코 프론트엔드 코치님이신 준님 영상이다! 😆 ㅋㅋㅋ 볼 때마다 밝은 에너지가 나에게도 전파되는 거 같아 기분이 좋고 빨리 한번 뵙고 싶다 ㅎㅎ )
아웃라인(outline)을 잡자
먼저 코드를 구현해 보기 전에 우리가 무엇을 할지, 어떤 식으로 할지 아웃라인을 만들고 시작해 보자. 예를 들어 카운터 앱을 만든다면 다음과 같이 아웃라인을 작성해 볼 수 있다. 여기서 중요한 점은 서로 능동적인 태도로 의견을 나누며 번갈아가며 작성하는 것이다.
- 초기값 0 표시
- + 버튼을 누르면 1씩 올라간다.
- - 버튼을 누르면 1씩 내려간다.
- reset 버튼을 누르면 0으로 초기화
- … 등등
아웃라인을 따라 코드 구현
이제 아웃라인을 보며 코드를 같이 구현할 건데 이때도 가장 중요한 것은 코딩이 아닌 팀원과 대화를 하면서 문제를 같이 풀어 나가는 것이 중요하다. 코딩을 하면서도 자신이 어떻게 짜려고 하는지 왜 이렇게 하는지에 대해 항상 파트너와 대화를 하면서 진행해야 한다. 그렇지 않으면 진행자(코드 작성자)는 코드만 작성하게 될 것이고 관찰자는 관객 모드로 화면만 계속해서 보게 될 것이다.
위 영상에서 나온 대화 몇 가지를 통해 한번 분석해 보자.
(4분 12초부터)
정수님: 나중에 카운터를 계속 갱신해야 되니까 id 속성 값도 필요할까요?
준님: 그렇네요. 저 안에 텍스트를 계속 바꿔주어야 하니깐 뭔가 구분할 수 있는 id가 좀 있으면 좋겠네요.
정수님: counter-value? 어떤 게 좋을까요?
준님: counter-value로 일단 가보고 하다가 어색하면 그때 바꾸어 볼까요?
그냥 간단한 코드 작성이라도 어떻게 짜려는지, id 값을 왜 넣을려는지 그리고 질문(어떤 게 좋을까요?)을 통해 상대방과 끊임없이 대화하려고 하고 있는 걸 볼 수 있다.
(5분 37초부터)
정수님: 일단 counter라는 변수를 만들어 볼까요?
준님: counter는 전체 앱인데 counter란 변수명이 전체 앱을 나타내는 걸로 쓰고 있는 것 같다는 생각이 들어요.
정수님: counter value?
준님: counter value가 여기서도 그렇고 똑같이 맞추는 게 어떨까요? 그리고 요즘은 변수를 const 또는 let으로 선언하거든요. counter value 같은 경우는 let으로 변수를 선언하면 더 좋을 것 같아요.
정수님: 제가 너무 옛날에 했어서..ㅎㅎ
준님: 저도 최근에 배워서 이 정도 조금 알고 있습니다.ㅎㅎㅎ
관찰자가 그냥 단순히 진행자가 코드를 작성하는 것만 지켜보는 게 아니라 더 좋은 방법(counter -> counterValue, var -> let)이 있으면 제안하고 이유를 설명함으로 써 더 좋은 코드를 작성하도록 개선하려고 노력하고 있다. 그리고 마지막 두 줄의 대화를 보면 서로 존중하면서 대화를 진행하며 커뮤니케이션 스킬도 늘 수 있을 것 같다는 생각도 든다.
(8분 54초부터)
준님: 그리고 textRender인데 생각해 보니깐 getElement인데 counter-value만 가져오는 역할을 해서 이게 좀 헷갈리는 것 같다는 생각이 드는 것 같아요. 어떻게 리팩터링 해보면 좋을까요?
정수님: 어떻게 하면 좋으시겠어요? 생각하시는 걸 한번 보여주시면 getElement 함수에서
준님: getElement 함수에서 여기서 인자로 그냥 selector를 받으면 좋을 거 같거든요. 여기서 selector를 받고 그리고 여기는 byId라고만 하면은 id 값으로 만 가져올 수 있는데 querySelector라는 메서드를 이용하면 id도 가져올 수 있고 class도 가져올 수 있거든요. 그래서 textRender인데 여기서도 뭔가 selector를 받아와야겠네요. 이게 너무 일반적인 네이밍이어서 가지고 그게 좀 어려운 거 같은데 textRender라기보다는 counterRender가 더 어울릴 수 있겠네요.
정수님: 그렇네요.
준님: 지금은 당장 숫자를 업데이트해 주는 게 하나의 엘리먼트뿐인데 너무 일반적인 함수를 만들다 보니깐 뭔가 비대해진 느낌인 것 같아요.
정수님: 하는 역활이 좀 크다는 거네요.
준님: countRender 하고 getElement 해서 여기에 counter-value를 넣어주면 훨씬 낫지 않나 생각하는데 혹시 어떠세요?
정수님: 좋은 것 같아요.
어떻게 하면 더 좋은 구조로 개선할지에 대해 계속해서 의견을 나누고 있다. 위에서는 준님이 어떤 좋은 방법을 제안한 뒤에 이유를 설명하고 나서 정수님도 적극적으로 이해하며 확인을 한 후 수용하여 더 좋은 코드가 나오게 되었다.
페어 프로그래밍 하는 걸 보고 개인적으로 느낀점
- 계속 티키타카(의견을 주고받으며)를 통해 더 좋은 코드를 짜게 되는 거 같아 너무 좋은 것 같다. 왜 이렇게 짜게 되었는지 페어에게 설명을 해주면서 하게 되어 나도 더욱 근거 있고 정확한 코드를 작성할 수 있고 그걸 페어가 재확인해 주거나 또는 더 좋은 방법이 있으면 페어가 의견을 제시해 줄 수도 있다.
- 서로에게 잘하는 것을 배울 수 있음.
- 의사소통(커뮤니케이션) 능력 증가
어떻게 페어 프로그래밍을 더 효율적으로?
- 가장 이상적인 페어는 실력이 비슷한 페어.
- 짝을 이룬 두 사람이 실력 차이가 나더라도 한 사람이 일방적으로 강의하는 방식은 권장 X.
- 가능한 번갈아가며 눈높이를 맞추려는 노력을 해야 두 사람 모두 성장 가능
- 서로 더 좋은 방식으로 코드를 짜려고 노력해야 됨.
- 생각하는 걸 멈추지 말자!
- 진행자: 나 홀로 코딩 금지, 관찰자: 멍 때리지 말고 집중
- 자주 스위칭하기(진행자 <-> 관찰자)
- 한 명만 키보드를 잡고 있는 것은 좋지 않다.
- 정기적인 휴식 갖기
- 페어 프로그래밍은 다른 사람과 같이 집중하는 것만큼 피로감도 엄청나기 때문에 정기적으로 휴식시간을 갖도록 노력하자
참고:
*틀린 부분이 있으면 언제든지 말씀해 주시면 공부해서 수정하겠습니다.