페어 프로그래밍의 가능한 단점은 무엇입니까? [닫은]

페어 프로그래밍은 오늘날 매우 유명합니다.

다음과 같은 몇 가지 장점이 있습니다.

1. 버그가 적은 프로그램.
2. 포스트 프로덕션 유지 관리 비용이 훨씬 적습니다.
3. 확립 된 관행에 도전하여 새로운 아이디어가 등장합니다.
4. 프로그래머들은 서로 배웁니다.
5. 프로그래머는 부드러운 기술을 개발합니다.

그러나 페어 프로그래밍의 단점은 무엇입니까?

페어 프로그래밍은 상당한 명성을 얻었지만 몇 가지 함정도 있습니다.

그들 중 일부는 다음과 같습니다.

1. 페어 프로그래밍에서는 앉아서 자신의 코드를 자체 평가할 수 없습니다.
2. 쌍 중 하나가 적극적으로 참여하지 않을 수 있습니다.
3. 운전자는 "소리내어 프로그래밍"해야합니다. 조용히 프로그래밍하면 이점이 줄어 듭니다.
4. 동일한 기능을 생성하는 데 더 많은 시간이 소요됩니다. 코드 품질과 코딩 비용 증가간에 균형을 유지해야합니다.
5. 숙련 된 프로그래머와 초보자가 짝을 이룰 때 "마스터 마스터"현상이 발생할 수 있습니다. 초보자 회원은 대부분의 코딩을 완료 한 경험있는 회원과 함께 관찰자가 될 수 있습니다.
6. 두 명의 숙련 된 사용자가 짝을 이루면 "개발자의 자아"현상이 발생할 수 있으며 각 구성원은 자신의 아이디어를 추진하려고합니다.

모든 엔지니어에게 필수 프로세스로 롤아웃을 고려한 조직을 포함하여 페어 프로그래밍을 여러 번 시도했습니다 (아이디어가 얼마나 잘 전개되었는지 추측 할 수 있음). 개인적으로 나는 그것을 싫어했다.

아래에 열거 한 이유는 주관적인 경험 일 뿐이며 구체적인 용어로 그 영향을 '측정'할 수 없습니다. 그러나 여기 모두 동일합니다.

1- '네비게이터'와 '드라이버'를 갖는 것은 전자가 보컬이고 후자가 듣는 경우에만 도움이됩니다.

우리는 모두 이론적 관심사에 대해 고집이 세고 누군가가 문제를 제안 할 때 병리학 적으로 불가능한 (심리적으로) 오래된 작업을 '버릴'개발자를 만났습니다. 그리고 우리는 모두 개인이 너무 소심하거나 모호하여 우려를 제기하거나 모퉁이 사건을 제안 할 수 있음을 알고 있습니다.

이러한 종류의 개발자가 쌍을 이루면 네비게이터는 수동적 인 역할을 신속하게 수행하며, 결국 자동 코드 검토를 통해 단독 프로그래밍을 수행하게됩니다. 이것은 엄청난 자원 낭비입니다.

2-페어링은 창의성을 방해합니다.

이전에 '그룹 브레인 스토밍'의 가치에 대해 느꼈던 것과는 달리 요즘의 ​​합의는 창의적 지식 작업에는 독립성 과 자율성이 필요하다는 것 입니다. 혼자 일할 때 미친 아이디어를 빨리 해킹하여 실제로 실현 가능한지 확인할 수 있습니다. 말도 없이 이상한 프로토 타입을 조립할 수 있으며, 실패하면 아무도 모르기 때문에 중요하지 않습니다 .

새로운 개념을 시도하고 싶을 때, 파트너를 설득하고, 단계별로 구현을 통해 이야기를 나누고, 그들이 실패하면 나를 판단하지 않기를 바랍니다. 그런 환경은 새로운 아이디어를 만드는 데 유독 합니다.

3-최저 공통 분모 설계.

위와 같이 한 쌍이 새로운 아이디어를 내놓지 못하거나 개인이 기능을 디자인해야하는 기본 원칙에 동의 할 수없는 경우, 타협하지 않는 디자인은 누구도 타협하지 않고 만족 시키려고합니다.

훌륭하고 웅장하며 기능적인 프로그래밍 추상화를 작성하는 개발자를 빠르고 더러운 성능 괴물과 결합하면, 함께 생성 할 코드는 일반적으로 매우 우아하거나 빠르지 않습니다.

4-자율성과 폭력적인 투명성 부족.

폭력적인 투명성 은 스크럼 방법론에 대해 적당히 유명한 (그리고 논란의 여지가 많은) 논쟁에서 뽑아 낸 문구입니다. 일부 조직이 개발자를 영 유화하고 비전문가 근로자를 위해 일반적으로 예약 된 의심으로 개발자를 대하는 방식을 설명합니다.

개발자의 작업을 완전히 투명하게 만드는 '유해'에 대해 어떻게 생각하든 (실제로 해롭다는 데 동의하지 않을 수도 있음) 많은 개인이 자율성과 혼자 일할 수있는 능력을 소중히 여깁니다. 그것은 중요한 심리적 요구이며 개발자가 (적어도 하나의 상점에서 일어난 것처럼) 페어링하도록 강요하면 직원들이 당황하고 화를 내고 소외됩니다.

5-일부 개발자는 쌍으로 멋지게 연주하지 않습니다.

일부 사람들은 페어링 된 환경에서 적절하게 행동하지 않거나 수행 할 수 없습니다. 그들은 나쁜 위생, 열악한 작업 습관, 거친 성격, '큰 소리'와 '강렬한'방식, 또는 개별 속성을 훌륭하게 만드는 다른 속성들, 그러나 열악한 쌍 프로그래머를 가질 수 있습니다.

이 문제를 해결할 수 있습니까? 실제로는 아닙니다. 개인적인 행동을 바꾸는 것은 어렵습니다. 페어 프로그래밍 샵은 고용에 대해 매우주의를 기울여야하고 누군가의 작동 방식과 동료들과 잘 어울릴 수 있는지에 많은 시간을 투자해야합니다. 그러나 성격에 대해 더 열심히 차별한다는 것은 기술과 전문 지식에 대한 기준을 완화하지 않는 한 고용이 더 오래 걸린다는 것을 의미합니다.

상황이나 관점에 따라 다릅니다.

페어 프로그래밍은 조직에 좋습니다. 그러나 개인에게 좋은가요?

결국 비용 절감 (조기 피드백) 및 생산성 방법입니다. 그것은 당신에 관한 것이 아니라 프로젝트, 제품, 회사 ($ $)입니다.

개인적인 혜택을 누릴 수 있지만 개발 방법론의 이유나 끝이 아닙니다. 예를 들어 (풀 타임) 페어 프로그래밍은 느슨해 짐, 서핑 등을 막아줍니다. 파트너에게 일시 중지를 정당화해야합니다.

당신의 (회전하는) 파트너는 최고의 감시 카메라가 될 것입니다 : 작업 강도 증가.

또는 지식을 배포함으로써 개인은 회사에 덜 위험하게되고 (예 : 필수 지식으로 회사를 떠날 수 없음) "협약 칩"이 줄어 듭니다.

관리자의 관점보다는 회사의 실제 상황 / 관점에서 긍정적 인 기사를 더 비판적으로 읽으면 더 많은 포인트를 찾을 수있을 것입니다.

거의 모든 방법론은 관리자의 관점에서 작성되었습니다.

1. 갑자기 화장실에 가거나 커피를 마시려고 할 때 누군가에게 말해야합니다. 최소한 허가를 요구할 필요는 없습니다.

2. 다른 사람의 위생 기준에 대처해야합니다.

다른 답변 외에도 :

1. 프로그래머가 랩톱으로 문제를 해결하기 위해 노력한 많은 회사 (고객 사이트를 기반으로-퇴근 후 집으로 가져 가면 장비를 안전하게 유지하고 집에서 VPN으로 이상한 일을 할 수있는 등) 수년 전 이미 다른 사람의 ( "드라이버") 랩톱 화면에서 어깨 서핑 관점에서 볼 수있는 문제가있었습니다. 나이가이를 개선 시키지는 않을 것입니다 (어떤 경우 든 이상적인 화면 각도 이상에서는 일부 화면을 읽기가 어려워집니다).

   따라서 페어 프로그래머에게는 충분히 큰 화면이 필요하므로 하드웨어 비용이 증가하고 위치에 대한 적응성이 제한됩니다. 어떤 경우에는 문제가되지 않을 수도 있고, 다른 경우에는 문제가 될 수도 있습니다.

2. 또한 개인 충돌뿐만 아니라 개인 위생 선호도 (흡연, 식사 및 음주 포함)의 차이로 인해 생산성이 저하되는 것으로 나타났습니다. 두 명의 프로그래머에게 "빨리 빨아 들인다"는 말을하는 것은 쉬운 일이다. 종종 사람들은 수동적 인 공격적인 행동을 통해 입을 다물고 조용히 방해하여 서로의 분노를 분개하게한다.
3. 소음. 나는 조용한 작업 환경을 좋아합니다. (페어링을 위해 대화해야 할 때) 일부 페어 프로그래머 그룹의 끊임없는 대화를 상상할 수 없습니다. 헤드폰의 성악조차도 내 집중력을 방해하는 경향이 있습니다 (사무실 청취를위한 평범한 악기). 유비쿼터스 개방형 사무실에서 전용 2 인실로 이동하면이 문제를 해결할 수 있지만 비용이 다시 증가 할 것입니다.

즐거움을위한 일화 :

• 이전 고용주는 한 번 다른 국가에서 계약자를 확보했습니다 (유죄를 보호하기 위해 익명으로 유지해야 함). 고용주는 숙박 시설을 제공했지만 운송은 제공하지 않았습니다. 계약자가 일하기 위해 길을 따라 살았 기 때문에 나는 그를 데리러 다시 데려가도록 자원했다. 그의 개인 위생은 내가 익숙했던 것과 같은 표준에 있지 않았으며, 내가하지 않는 동안에도 그는 아주 많이 피 웠습니다 ( "가장 강합니다!"). 사무실로 15 분 동안 여행을 갔을 ​​때 나는 심지어 겨울에도 창문을 내린 채로 두 달간 담배를 피우지 않았다. 그러나 그는 나를 기다리는 동안했다).
• 우리는 또한 페어 프로그래밍을하지 않았지만 회의 테이블에서 (한동안) 서로 옆에 앉았습니다. 약 한 달 후, 테이블의 인조 나무에는 동료의 마우스 손 위치 주변에 멋진 갈색 고리가있었습니다. 그 시점에서 나는 콜센터 오픈 플랜 영역 옆에 열린 책상을 얻었습니다. 헤드폰의 도움으로 선호했습니다.
• 그리고 유비쿼터스 사무용 음료 인 커피가 있습니다. 나는 그것을 마시지 만 다른 동료들처럼 자주 마시지 않고 마시지 않습니다. 빈 거리의 머그잔 냄새와 비슷한 근거리 호흡은 매우 불쾌 할 수 있습니다. 향기를 "안개"라고 부르 자 ...

사회적 및 실제적인 이유로 쌍 프로그래밍이 실패한다고 생각합니다. 본질적으로 당신은 한 사람에게 끊임없는 감시하에 일하라고 요구하고 다른 한 사람은 구멍을 찌르기 만하면됩니다.

잠시 후 불가피하게 발생하는 일은 쌍이 '이메일 확인'또는 '실시간 문제에 대한 잘못된 점검 수행'등으로 분리 된 것입니다.

코드 출력을 개선하는 대신 볼륨이 줄어 듭니다. 실질적인 이유로 '저는 당신과 동기화되지 않은 점심 / 미팅으로 가야합니다'와 소셜은 '밥이 다시 페어링에 대해 묻기 전에 밥이 그 일을 마칠 때까지 기다릴 것입니다.

귀찮은 장점에 관해서는 더 간단하고 효과적인 방법으로 달성하는 많은 일반적인 관행이 있습니다.

두 명의 수석 개발자에게 자신이 일을 할 수 있다고 확신하는 경우 "통증 프로그래밍"을하도록 지시하는 것은 가장 큰 단점이 있습니다.