페어 프로그래밍: 애자일 프로그래밍 모범 사례
페어 프로그래밍은 두 명의 프로그래머가 하나의 공유 워크스테이션에서 함께 작업하는 소프트웨어 개발 워크플로우로, 협업이 가장 중요합니다!
페어링 메커니즘
페어링은 두 명의 프로그래머가 하나의 워크스테이션에서 작업하는 것을 의미합니다. 한 프로그래머는 키보드를 조작하는 "드라이빙"을 하고, 다른 프로그래머는 "네비게이션"을 하며, 관찰하고, 배우고, 질문하고, 말하고, 제안합니다. 이론적으로, 드라이버는 코드 자체, 즉 구문, 의미, 알고리즘에 집중합니다. 네비게이터는 코드 자체보다는 더 높은 수준의 추상화, 즉 통과하려는 테스트, 다음에 수행할 기술 작업, 모든 테스트 실행 후 경과 시간, 마지막 저장소 커밋 후 경과 시간, 그리고 전반적인 설계의 품질에 더 집중합니다. 이론에 따르면 페어링은 더 나은 설계, 더 적은 버그, 그리고 개발 팀 전체에 대한 지식 확산을 촉진하여 장기적으로 측정했을 때 단위 시간당 더 많은 기능을 제공합니다.
지식 확산
멘토링 메커니즘으로서 페어링은 분명 탁월한 선택입니다. 페어링이 정기적으로 (그럴 만하죠) 바뀌면, 페어링은 코드베이스 지식, 디자인 및 아키텍처 지식, 기능 및 문제 도메인 지식, 언어 지식, 개발 플랫폼 지식, 프레임워크 및 도구 지식 등 여러 종류의 지식을 팀 전체에 매우 효율적으로 전파합니다. 리팩토링 지식그리고 지식을 테스트합니다. 페어링 방식이 전통적인 코드 리뷰나 덜 공식적인 방법보다 이러한 종류의 지식을 더 잘 전파한다는 것에는 큰 이견이 없습니다. 그렇다면 지식을 그렇게 잘 전파하는 데 드는 생산성 손실은 무엇일까요? 만약 있다면, 어떤 손실이 있을까요?
페어링과 생산성
연구 결과와 일화적인 보고에 따르면 단기 생산성은 소폭(약 15%) 감소할 수 있지만, 생성된 코드가 훨씬 더 우수하기 때문에 장기 생산성은 향상됩니다. 물론 이는 생산성을 어떻게, 그리고 어떤 기간 동안 측정하느냐에 따라 달라집니다. 애자일 환경에서 생산성은 종종 반복 작업 및 릴리스당 실제로 제공되는 테스트된 기능의 실행 횟수로 측정됩니다. 팀이 주당 코드 줄 수로 생산성을 측정한다면, 페어링을 통해 이 수치가 실제로 감소하는 것을 확인할 수 있습니다(그리고 테스트된 기능당 코드 줄 수가 줄어든다면, 이는 긍정적인 신호입니다!).
생산성과 직원 이직률
페어링 지지자들은 직원의 채용과 이직을 포함하여 장기간에 걸쳐 생산성을 측정하면 페어링의 가치가 더욱 커진다고 주장합니다. 많은 주류 프로젝트에서 전문 지식은 "지식의 섬"에 축적되는 경향이 있습니다. 개별 프로그래머는 다른 프로그래머들이 잘 모르는 중요한 것들을 많이 알고 있는 경향이 있습니다. 이러한 지식의 섬 중 하나라도 팀에서 이탈하면 프로젝트가 심각하게 지연되거나 더 심각한 결과를 초래할 수 있습니다. 페어링 이론의 일부는 팀 내에 다양한 종류의 지식을 널리 퍼뜨림으로써 경영진이 직원 이직이라는 끊임없는 위협에 노출되는 것을 줄인다는 것입니다. 익스트림 프로그래밍(XP)에서는 트럭 대수를 이야기합니다. 트럭에 치여 프로젝트를 중단해야 하는 팀원의 수를 의미합니다. XP 프로젝트는 트럭 대수를 전체 팀 규모에 최대한 가깝게 유지하려고 노력합니다. 누군가 떠나면 보통 그 자리를 대신할 다른 사람들이 있습니다. 전문 분야가 전혀 없다는 것은 아니지만, 모두가 무슨 일이 일어나고 있는지 더 잘 알고 있다는 것은 확실합니다. 이러한 팀이 여러 차례 릴리스를 통해 제공한 기능의 측면에서 생산성을 측정한다면 페어링이 발생하지 않는 경우보다 더 높아야 합니다.
페어링 전략
영어: 규칙에 따른 XP에서 모든 프로덕션 코드는 쌍으로 작성됩니다. XP가 아닌 많은 애자일 팀은 페어링을 전혀 사용하지 않습니다. 하지만 페어링이 없는 경우와 모두가 항상 페어링하는 경우 사이에는 많은 중간 지대가 있습니다. 신규 직원을 멘토링할 때, 매우 위험한 작업, 디자인이 새로운 새 프로젝트를 시작할 때, 새로운 기술을 채택할 때 또는 월별 또는 주별로 순환할 때 페어링을 사용해 보세요. 페어링을 선호하는 프로그래머는 허용될 수 있지만, 원하지 않는 프로그래머는 허용되지 않을 수 있습니다. 페어링 대신 코드 검토를 사용하기로 한 결정이 인기가 있지만, 페어링을 최소한 실험하지 않을 이유는 없습니다. 팀이나 프로젝트에 해를 끼친다는 합리적인 증거는 없으며, 도움이 되는 모범 사례라는 증거가 점점 늘어나고 있습니다.