13

경영진이 페어 프로그래밍이라는 아이디어를 저나 다른 관리자 / 개발자에게 전달한 몇 개의 상점에서 일했는데 전혀 뒤쳐 질 수 없습니다. 개발자의 관점에서 볼 때이 코딩 스타일로 전환하는 것이 유리한 이유를 찾을 수 없으며 소규모 팀의 관리자가 어떤 이점도 보지 못했습니다.

기본 구문 오류에 도움이되고 무언가를 해시 해야하는 경우 도움이 될 수 있지만 프로그래밍 루프를 벗어난 관리자는 디자이너가 Facebook 또는 Reddit에 가지 않는 것보다 계속 보는 것처럼 보입니다. 디자인 툴.

개발 현장에 가까운 사람이 책에서 주제에 대한 내 길이나 wiki 페이지를 완전히 이해하지 못했을 것입니다 ... 높은 수준의 관리 위치에서 Scrum 또는 Agile을 다룰 때 페어 프로그래밍의 이점은 무엇입니까? 환경?

— 제프 랭 메이에
소스

2

매우 구체적인 상황에서 유용하다고 생각합니다. 그러나 일반적인 개발 모델로는 쓸모가 없습니다.

— Ryan Kinal

4

보기에 색을 입힐 수있는 소프트웨어에 따라 다를 수 있습니다. 작은 위젯이 많고 매일 다른 작은 사용자 정의 소프트웨어에서 작업하는 경우 유용하지 않을 수 있습니다. 개발자가 구현 한 기능으로 인해 시스템 전체에서 캐스케이드를 설명해야하는 대기업 시스템을 다룰 때는 매우 가치가 있습니다. 30 개가 넘는 개별 장소에서 사용되는 데이터에 영향을 미치는 하나의 수업을 작성하는 것은 일반적으로 다양한 정신 과정을 가진 두 사람이 더 잘 추론 할 수 있습니다. 사전 결함 찾기를위한 몬테 카를로 방법과 같습니다.

— Jimmy Hoffa

@JimmyHoffa 따라서 주요 사고 과정은 버그를 수용 테스트하기 전에 버그를 발견하면 코드 검토 / 테스트에서 잃어버린 시간을 크게 줄일 수 있다는 것입니다.

— Jeff Langemeier

3

@JeffLangemeier 실제로는 그 이상입니다. 서브 시스템 A를 구현하는 도중에 두 개발자 사이에서 발생하는 자연적 담론으로 인해 A1 이전에 서브 시스템 A의 섹션 A1 디자인에 결함이있는 경우 섹션 수정에 소요되는 시간을 절약 할뿐 아니라 A1 및 A1에 종속 된 섹션 A5 및 A7 (또는 A1 수정으로 인한 캐스케이드로 인해 해당 종속 섹션에서 버그를 발견)은 해당 불량 섹션을 작성하지 않음으로써 시간을 절약 할 수 있습니다. 테스트 시간은 단축되지만 이러한 방식으로 개발 시간은 더욱 단축됩니다.

— Jimmy Hoffa

@MartinWickman 이것은 중복되지 않습니다. 제목이 찬반 양론을 요구하더라도 링크 된 링크에서 실제로 찬반을 찾고있었습니다. 또한 전문가들에 대한 더 철저한 답변이 이것에 주어졌습니다. 요컨대, 커뮤니티가 서로 근접하더라도 이것을 보유하는 것이 유익하다.

— Jeff Langemeier

25

부분적으로는 쌍 프로그래밍을 수행하는 방법에 따라 다릅니다. 일부 경우에, 쌍의 운전자는 코드를 작성하는 동안, 쌍의 제 2 구성원은 시스템의 설계 및 구현 세부 사항을 관찰하고 논의한다. 페어 프로그래밍의 또 다른 사례는 사람들이 동시에 코드를 작성하는 것입니다. 한 사람은 구현 된 기능을 작성하고 다른 한 사람은 단위 및 통합 레벨에서 테스트 코드를 적극적으로 개발 및 작성하여 시스템의 설계 및 구현 세부 사항에 대해 다시 논의합니다.

페어 프로그래밍 유형에 관계없이 지속적인 코드 검토 역할을합니다 . 코드에 대해 두 사람의 눈을 가지고 있으며, 나중에 시스템 / 수락 테스트 환경이나 현장으로 빠져 나가기 전에 오류를 관찰합니다. 또한 버스 요소 를 최소화하기 위해 중복 기능을 수행하기 위해 시스템의 특정 부분을 잘 이해하는 두 사람이 있습니다. 결함을 조기에 파악하고 팀 전체에 시스템 지식을 전파하면 시스템 구축 비용이 줄어 듭니다.

지식의 확산은 팀의 기술 지식에만 국한되지 않습니다. 쌍이 누구인지에 따라 코딩 스타일, 회사 문화, 기대 등 프로젝트를 초월하는 다른 것들에 대해 회사의 상급 멤버와 새 멤버간에 정보가 전달 될 수 있습니다. 또한 기술이나 도구에 더 익숙한 사람이 해당 기술이나 도구에 대한 지식을 실제 적용 환경에서 공유 할 수 있습니다.

언급했듯이 개발자의 집중력과 흐름을 유지하는 데 도움이 됩니다. 흐름 외에도 많은 개인이 여러 사람이 특정 작업을하는 것보다 여러 작업을 방해 할 가능성이 적습니다. 다른 사람의 책상을 걷다가 혼자 일하고 있지만 그들과 대화해야 할 경우, 두드리고 대화 할 수 있습니다. 두 명 이상의 사람들이 공동으로 작업하거나 토론하는 것을 보더라도 방해 할 가능성이 적습니다. 중단은 시간이 걸리고 더 많은 시간을 소비하면 비용이 높아집니다. 직원의 생산성을 극대화하는 것이 비즈니스의 이익에 달려 있습니다.

그러나 페어 프로그래밍을 실행 가능하게하려면 극복해야 할 몇 가지 과제가 있습니다. 성격이 충돌하거나 지식을 올바르게 분배하기 위해 쌍을 선택하는 것과 같은 것을 고려하십시오. 정확히 언제 쌍을 회전해야하는지 고려해야합니다. 아마도 페어 프로그래밍은 아마도 계획된 것만 큼 효과적이지 않을 것입니다. 팀 구성에 따라 사람들을 한 쌍으로 만드는 것은 효과적이지 않을 수 있습니다.

— 토마스 오웬스
소스

큰 답을 얻으려면 +1하십시오. 나는 여전히 그 아이디어를 강력하게 싫어하지만 당신은 그 이점을 잘 제시합니다.

나는 당신의 지브 컷을 좋아합니다.이 설명은 실제로 이것이 실용적이라고 느끼게합니다.

— Jeff Langemeier

9

현재 요구 사항에 따라 페어링이 더 임시적인 하이브리드 모델을 선호합니다. 또한 혼자서 일하는 것이 더 효율적이고 파트너와 함께 일하는 것이 더 좋은 때가 있습니다. 영구적 인 쌍으로 강요당하는 것은 자의적이고 융통성이 없어 보입니다.

— jfrankcarr

아주 좋은 대답입니다. 또한 민첩한 팀의 프로그래머이며 많은 페어링 작업을 수행합니다. 처음에 우리는 회의적이었습니다. 우리는 혼자 일하는 것이 최선의 방법이라고 생각했습니다. 팀 진화의 어느 시점에서 우리는 페어 프로그래밍을 부과했습니다. 페어 프로그래밍되지 않은 경우 생산 코드가 커밋되지 않았습니다. 이것은 페어링 개념을 인공적으로 시행 한 것이었지만 팀에게 많은 도움이되었습니다. 마지막으로, 우리 모두가 기술에 익숙해 졌을 때 우리는 스타일을 변경했으며 임시로 팀을 구성하고 있으며 대부분 구현이 더 복잡하거나 오류가 발생하기 쉽습니다.

— Patkos Csaba

@jfrankcarr, 아무도 영구적 인 쌍을 제안하지 않았다. 나는 당신이 그 아이디어를 어디서 생각해 냈는지 확실하지 않습니다. (이 답변은 특별히 "쌍을 회전시킬 때"라고 언급했습니다.) 우리 팀은 같은 두 사람이 하루나 이틀 이상 서로 짝을 지도록하는 것이 정말 나쁜 생각이라는 것을 알았습니다. 당신은 틀에 박 히기 시작합니다. 일부 팀 은 1 시간 반마다 회전합니다 (PDF 링크).

— Joe White

3

최종 코드의 오류 감소 (효율)
코드 검토를 완전히 대체하지는 않지만 조기에 작업을 수행하는 데 매우 효과적입니다. 그 방향을 지적하는 연구가 있습니다.
빠른 완료 (효과)
이를 지적하는 여러 연구가 있습니다. 복잡한 특징에 관해서는 2 헤드가 더 효과적입니다. 페어링 경험이 필수입니다.

(참고 : 이것은 관리자를위한 영업 기회입니다.보다 효율적으로 더 적은 수의 버그를 얻을 수 있고 더 빠른 완료로 더 효과적이기 때문에 재정적으로 건전한 결정)

주니어 교육
보다 숙련 된 프로그래머에게 주니어를 직접 추가 할 수 있습니다. 절대 초보자 그룹이 있다면 쉽게 고수하고 기본적으로 쌍을 이루도록 할 수 있습니다. 주위에 붙어 조언을 제공하십시오. 이 개념은 분명히 매우 오래되었으며 장인 정신에서 비롯된 것입니다.

— bs
소스

3

빠른 답변 : 대부분의 혜택과 비용은 Wikipedia에 게시되어 있지만 조금 다른 각도에서 살펴 보겠습니다.

블로그 게시물 에서 가져온 민첩 / 스크럼 개발 환경에 적용되는 페어 프로그래밍 이점의 특정 사례를 언급하고 싶습니다 .

소프트웨어의 성공 또는 실패는 품질에 달려 있으며 페어 프로그래밍은 다양한 방식으로 품질을 직접 향상시킵니다. 두 개발자가 함께 작업하면 버그가 적고 코드가 짧고 간단하며 유지 관리가 쉬운 개발로 디자인 패턴 품질이 향상됩니다. 버그는 소프트웨어 개발에서 주요 품질 문제입니다. 코드를 작성하는 두 가지 눈으로 더 많은 실수가 포착되어 개발 비용이 감소합니다. 개발 과정에서 늦게 발견 된 버그는 종종 수정 비용이 많이 듭니다. 소프트웨어 결함을 조기에 발견하면 어려운 문제를 예방할 수 있습니다. 복잡성은 종종 프로그래밍에서 발생하며 문제를 함께 해결하기 위해 노력하는 두 사람은 더 많은 옵션을보고 결론보다 더 빨리 결론을 도출 할 수 있습니다.

요약해서 말하자면:

팀 커뮤니케이션 촉진
효율적인 응용 지식 전달 촉진
설계 접근에 대한 책임을 장려
더 좋고 유지 관리하기 쉬운 코드 결과
초기 단계에서 버그가있는 코드를 제거합니다.
코딩하는 동안 팀원들이 나름의주의를 기울일 것이기 때문에 팀 생산성 향상
팀원의 커뮤니케이션 및 협업 기술 향상
직장에서 동지 건설
일을 더 재미있게 만듭니다

— 유수 보프
소스

When two developers work together design pattern quality improves-> 그 말은 전혀 이해가되지 않습니다. When two bakers work together wheat quality improves또는 보다 더 이상 의미가 없습니다 When two race drivers work together asphalt quality improves.

— phresnel

그것은 당신이 볼 수있는 블로그의 인용문입니다. 그러나 필자의 의도는 각 개발자가 생성 된 코드에 대해 자부심을 가지고 노력함에 따라 기술적 인 유형의 코드와 코드 품질에 중점을 두어야한다는 것입니다.

— Yusubov

2

페어 프로그래밍에는 몇 가지 이점이 있습니다.

두 프로그래머는 디자인에 대해 함께 협력하여 더 나은 아키텍처 / 코드를 생성 할 수 있습니다. 두 쌍의 눈은 실수를 발견 할 수 있습니다
기관 지식이 더 잘 보존됩니다. 한 프로그래머가 떠나거나 사용할 수없는 경우 다른 프로그래머는 생산성을 크게 떨어 뜨리지 않고 작업을 계속할 수 있어야합니다.
새로운 개발자를 빠르게 훈련시키는 한 가지 방법입니다. 숙련 된 개발 팀원과 짝을 이루어 팀의 베테랑 관점에서 코드 기반을 경험할 수 있습니다.
더 나은 훈련 – 한 쌍의 프로그래머가 활동의 파열을 대신 할 수 있기 때문에 한 쌍의 프로그래머는 더 오랜 기간 동안 생산성을 높일 수 있습니다. 단위 테스트와 같은 잠재적 인 지루한 작업은 솔로 개발자보다 덜 자주 건너 뛸 수 있습니다.

Wikipedia에는 또한 위키 항목 의 비용과 이점에 대한 요약이 있습니다.

— JW8
소스

페어 프로그래밍의 이유

요약해서 말하자면: