페어 프로그래밍 중에 흐름을 어떻게 달성하고 유지할 수 있습니까?

흐름 은 Mihaly Csikszentmihalyi가 도입 한 개념입니다. 즉, "영역"에 들어가는 것을 의미합니다. 당신은 당신의 임무에 몰입하고 집중되어 있습니다. 작업은 어려울 수 있지만 동시에 어려울 수 있습니다. 사람들이 흐름을 달성하면 생산성이 향상됩니다. 프로그래밍은 종종 한 번에 여러 가지 생각을 저글링해야하기 때문에 많은 정신적 집중이 필요합니다. 많은 사람들이 조용한 환경에서 작업에 전념 할 수있는 작업을 좋아합니다. 중단되면 다시 유입되는 데 몇 분 또는 몇 시간이 걸릴 수 있습니다.

민첩한 개발과 페어 프로그래밍이라는 극단적 인 프로그래밍에 대한 관행이 있음을 이해합니다. 의사 소통이 원활하도록 전체 소프트웨어 개발 팀을 한 방에 배치한다는 의미입니다. 이 방법으로 즉시 코드 검토를 받고 버그가 덜 발생하므로 쌍으로 코드를 작성하십시오.

끊임없는 중단으로 인해 페어 프로그래밍을 수행하는 동안 항상 흐름을 달성하는 데 문제가있었습니다. 나는 문제에 대해 깊이 생각하고 있는데 갑자기 누군가가 다른 사람에게 나에게 질문을합니다. 내 생각의 기차가 없어졌습니다.

페어 프로그래밍 중에 흐름을 어떻게 달성하고 유지할 수 있습니까?

편집 : 면책 조항-이것이 "영역"을 정의하는 방법입니다. A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

이 상태를 피하려고합니다. 존에서 올바른 코드를 생성 할 수는 있지만 나중에 나와 다른 개발자가 이해하기가 어려울 수 있습니다. 간단히 말해서 : 영역에서 작성된 코드를 읽으려면 영역에있는 리더가 필요할 수 있습니다. 그 제약은 내 문제입니다.

클린 코더 (Clean Coder) 에는 밥 아저씨가 왜 "영역에 들어가는"것이 설득력이 나쁜 아이디어인지 설득력있게 설명 하는 멋진 장이 있습니다.

여기에 "지역에 도착하는 것"보다 더 나은 대안이 있습니다. 똑바로 생각하고 자신이하고있는 일을 침착하고 전문적으로 고려하십시오. 소통하다. 파트너와 생각을 공유하십시오. 실제 문제를 식별하십시오. 가능한 해결책을 토론하십시오. 초자연적으로 집중되지는 않지만 좋은 결정과 접근하기 쉬운 디자인을 만들 것입니다.

귀하와 귀하의 파트너가 귀하의 두 가지 모두에 중점을 두지 않고 문제를 논의 할 수 있다면, 문제를보다 단순한 본질로 요약 할 가능성이 있습니다. 따라서 필요할 때마다 다시 이해할 수 있습니다.

반대로 ... 머리를 똑바로 세우기 위해 혼자 시간이 필요한 경우 (우리 모두는 가끔 그렇습니다) 그냥 가져 가십시오. 함께 생각하십시오. 먼저 머리에 문제를 해결하십시오.

그러나 중요한 것은 프로덕션 코드를 작성하는 데 그 시간을 사용하지 마십시오. 대신 샘플 코드와 프로토 타입을 가지고 놀아보십시오. 아직 해결책을 생각하지 않고 문제를 이해하려고 노력하십시오. 모든 내용을 똑바로 기록한 후에는 팀 및 페어 파트너 또는 책상의 고무 오리와상의하십시오. 그래도 설명 할 수 없거나 이해할 수 없으면 아이디어를 구체화하십시오. 모든 문제를 해결 한 후에는 모든 생각과 샘플 코드를 실제 작동하는 솔루션에 통합하십시오.

페어 프로그래밍은 때때로 파트너와의 격리 기간이 필요합니다.

예

특정 클래스에서 함께 일하고 있으며 복잡한 논리에 대해 깊이 생각해야하지만 평범한 결과를 반환하는 메서드를 작성해야 함을 알고 있습니다. 해당 메소드에 대한 단위 테스트 작성을 위해 함께 작업하고 격리 된 상태로 작업하는 동안 해당 메소드 작성을 지연시킵니다. 방법이 완료되면 한 쌍으로 다시 모여 결과를 평가합니다.

페어 프로그래밍이 작동하는 작은 종류의 문제가 있음을 발견했습니다. 예를 들어, 크로스 플랫폼 제품을 작업 중이고 Winders guy가 OS 특정 코드를 요구하는 기능을 구현 한 경우 Mac guy가 운전하는 동안 Mac guy에서 Mac 코드에서 동일한 기능을 구현하도록 도울 수 있습니다.

그러나 내 경험에 따르면 페어 프로그래밍은 비정상적으로 생산성 손실을 초래합니다. 종종 두 명의 개발자가 한 명의 일을하도록 비용을 지불하는 것처럼 느껴집니다.

예, 개발자가 근무 시간 동안 스택 교환 휴식을 취할 수있는 끔찍한 가능성을 줄입니다.

IMHO 자신의 개발자를 경찰로 삼 으려는 회사는 모든 개발자를 개인 경비원과 짝을 지어 개발자 뒤에 서서 곤봉으로 타격을가하거나 본질적으로 중요하지 않은 피크에 도달하려고 시도하는 경우 저렴합니다. 웹 페이지.

개발자가 영역에 들어 가려고 할 때 마음을 편안하고 깨끗하게하기 위해 최선을 다해 자신을 격리 시키려고합니다. 페어 프로그래밍이 다른 이유는 무엇입니까?

귀하와 귀하의 파트너는 귀하에게 적합한 영역 유도 환경을 찾아야합니다. 이것은 아마도 타협이 필요할 수 있지만, 나의 주요 요점은 페어 환경이 솔로와 유사해야한다는 것입니다. 외부 세계를 끄십시오. 쌍은 함께 프로그래밍하고 있습니다. 다른 동료들 (일반적으로 다른 동료들)은 방해해서는 안됩니다 (중요하고 중요한 행동 문제 제외).

흐름은 문제를 해결하기위한 정확한 단계를 알고있을 때 가장 좋은 상태입니다. 즉 미지의 미지수. 조용한 구석에 앉아서 솔루션을 망치십시오. 그러나 대부분의 문제 / 스토리 / 기능은 프로그래밍을 시작할 때 명확하지 않습니다. 예상되는 최종 상태와 뇌의 계획 상태 사이에는 항상 "갭"이 있습니다. 실제로 "할 때"많은 것을 배웁니다. 당신의 두뇌는 저글링

• 코드 디자인

• 타자

• 도메인과 코드에 대한 새로운 것을 배우다

혼자서 프로그램 할 때 이러한 것들의 균형을 맞추는 데 어려움을 겪습니다. 나는 침몰 한 비용이 잘못되어 한 걸음 물러서서 큰 그림을보고 디자인을 바꾸지 못하게하는 "토끼 구멍"에 빠지는 경향이 있습니다. 또한 상상의 고무 오리 또는 그 문제에 대한 실제 오리와 이야기하기도 어렵습니다. 나는 결국 "흐름"에있다.

그래도 생산적으로 페어 프로그래밍을하면 타이핑이 교대로 반복되고 사고와 성찰이 반복됩니다. 여기에는 많은 숨겨진 것들이 드러나고 다른 디자인이 나타날 수 있습니다. 토끼 구멍에 들어가면 페어링 파트너가 나를 끌어낼 수 있습니다. 실제 인간에게 이야기하고 설명하는 것은 어떻게 든 생각을 더 명확하게하는 훌륭한 효과입니다. 때때로, 나는 "흐름"에 빠지는 것을 그리워하지만, 나는 솔로를 프로그램 할 때보 다 프로그램을 페어링 할 때 팀에 훨씬 더 많이 기여한다고 생각합니다. 모든 프로그래밍 후! = 타이핑. 두뇌에서 프로그래밍이 일어나고 두 두뇌가 서로 협력하고 비판 할 때 더 나은 프로그래밍이 일어난다.