Pair Programming

PairProgramming 을 적용해보는 방법, 스타일 등등

• Pair Refactoring - 꼭 소스 코드가 아니더라도 위키 페이지에 대한 문서구조조정 을 하는 경우에도 적용할 수 있다. 특히, 해당 토론이 벌어진뒤 양론으로 나누어졌을 경우, 각 의견 지지자들이 Pair 로 문서구조조정을 할때 이용할 수 있다.
  
• 5분 Pair-Change - 장과 단이 존재하긴 하는데. 장점으로 본다면, 자신의 프로그래밍 차례가 빨리 돌아오면서 Pair 끼리의 Feedback 이 빠르다는 점에서 집중도가 높다는 점이 있다. 단, Junior 의 경우 자신의 사고가 성숙해질 시간을 방해할 수 있다. 이 경우 5분으로 시작, 점차적으로 Change 의 기간을 늘려주는 방법이 있다.
  

• 코드 에러율의 감소 - 내가 간과하고 넘어가기 쉬운 에러들에 대해서 지적이 빠르다.
  
• Protocol Analysis, 지식의 전달 - CognitivePsychology참조. 다른 사람의 사고과정을 관찰하고, 또한 자신의 사고과정을 다른 사람으로 하여금 관찰할 수 있게 해준다. 이는 자신의 프로그래밍 과정중 잘못된 부분을 고치는데 도움을 준다.
  
• Communication
  
• 해당 시간 내 집중도의 상승, Pair Pressure - 평소 프로그래밍 외의 것(프로그래밍 중 음악듣기, 쓸데없는 웹서핑, 메일 읽기)에 대한 잡음을 없앤다. 작업 자체에만 몰두하게 해준다. TestDrivenDevelopment 와 상호작용이 빠른 언어(Python 등..)를 이용하면 Feedback 이 빠르므로 집중도가 더 높아진다.
  
  

• Pair 중 Expert는 Junior에게 많은 설명을 해줘야 한다? - 이는 Junior 의 Feedback 을 보고 결정하는 것이 좋다. 처음부터 Expert 가 꼭 '선생님'이 될 필요는 없다.
  
• Junior : Expert 간 격차에 따른 효율성의 문제 - PairProgramming
  
• Junior : Junior Pair 는 의미가 없다? - 결과물에 상관하지 않는 학습의 경우 그 의미가 있다. Junior 의 실력 한계 내에서의 Output 으로도 의미가 있다. 처음 프로그래밍을 익히는 사람에게 Pair 를 하는 것 자체가 새로운 학습경험이 된다.
  
  

PairProgramming 의 다른 적용 예로서 PairSynchronization 이 있다.

진행한 사람 : 강석천, 윤상혁

동문서버 프로그래밍 팀의 인수인계용으로 이용되었었다. PP를 주로 하고 한두번의 VPP를 했다. 해당 소스를 같이 만들어가면서 기존의 프로그램을 설명했다.

Expert : Junior . 즉, 해당 분야에 대한 전문가 : 초심자 의 문제이다. 이 경우 그 진행이 늦어질 수 있다. (Expert : Expert는 최고의 효율성을 가진다. 물론 이것도 열린 마음을 바탕으로 한다. Junior : Junior 도 나름대로(?) 빨리 움직인다. (제대로 움직인다는 보장은 못한다. -_-;)) 그리고 Expert가 해당 프로그래밍에 대한 답 (코드)을 이미 알고 있는 경우 Expert의 집중도와 긴장감을 해치게 된다.
이 때에는 Expert는 놀지말고 (-_-;) Observer의 역할에 충실한다. Junior 의 플밍하는 부분을 보면서 전체 프로그램 내의 관계와 비교해보거나, '자신이라면 어떻게 해결할까?' 등 문제를 제기해보거나, reference, 관련 소스를 준비해주는 방법이 있다.

또 하나의 문제점으로 제기된 것은, Junior 가 Expert의 권위에 눌릴 수 있다는 것이다. Junior 는 질문에 용감해야 한다. Expert는 답변에 인색해서는 안된다. 열린 마음이 필요한 일이다. (Communication 과 Courge 는 XP 의 덕목이다. ^^)

전문가라 하더라도 프로그래밍의 실력과 다른사람에게 답변해주는 능력은 다르다. 커뮤니케이션 능력은 실제 도메인에 대한 지식과는 다를 수 있다. Expert 는 Junior 에게 설명을 해줌으로서 기존의 지식에 대한 정리를 해 나갈 수 있다. Junior 는 혼자서 삽질하는 것보다 더 빨리 필요한 지식에 대해 접근할 수 있다.

진행한 사람 : 강석천, 박지환

간단한 아날로그 시계를 만드는 프로그램이였다. MFC + CppUnit 로 작업했다.

• Pair 의 진행을 이끌어가는 것 - 프로그래밍의 흐름이라고 해야 할까. 디자인을 어느정도 선정도로 맞추고 어떠한 문제를 풀 것인가에 대한 약간의 선이 필요할 것 같다. 이 경우에는 초반 디자인이 허술했었다는 약점이 있었다. '전체적인 관점에서 무엇무엇을 하면 프로그램이 완성될 것이다' 라는 것. UserStory 만 생각하고 EnginneringTask 를 간과한 것이 큰 문제였다. (그때 EnginneringTask 에 대한 개념이 없었었다는. 어디서 함부로 주워만 지식. --; 사고를 하자 사고를. -_-)
  
  • ExtremeProgrammingPlanning 이라는 책을 보면 해결책을 구할 수 있을 것 같다. (Xp 책들의 장점이자 단점이라면 얇은 두께의 분책이려나.. --a)
    
• Pair 의 분배 - TFP를 공부하느냐고 시작한 것이였던지라, 상대적으로 CppUnit 에 익숙하지 않은 사람에게 코딩을 주도하게 했다. 한 1주일정도 되는 프로젝트라면 Junior로 하여금 경험을 쌓게 함으로써 오히려 장점으로 작용할 수도 있을 것 같다. 하지만, 역시 적절하게 분배를 했었어야 할 것 같다.
  
• 집단 삽질. --; - 이것은 헤프닝이라고 보는 것이. -_-;; Test Code 에서 둘이 라디안 구하는 공식을 거꾸로 쓰고 '왜 값이 틀리다고 하는거야!' 하며 1시간을 삽질했다는 후문이 있다는. --;
  
  • 하지만 UnitTest도 그렇듯이, 많은 장점을 가진 방법을 완벽하지 않다는 이유로 사용하지 않는다는 것은 아쉬운 일일 것이다.
    
• 아직은 효율성이.. - 일종의 Learning Time 이라고 해야 할까? 대부분 실험에서 끝난다는 점. 퍽 하고 처음부터 효율성을 극대화 할 순 없을 것이다. 참고로 이때는 아날로그 시계 만드는데 거의 3시간이 걸렸다. Man-Hour 로 치면 6시간이 된다.
  
  

집중도는 거의 최고라는 점! (이 점에서 둘이 서로 동의를 했다.) 평소 혼자 프로그래밍할때는 중간에 웹서핑을 하는 등 주위가 산만해지는 경우가 많았다. 하지만 이 Pair 중에는 사람들이 프로그래밍과 토론에만 전념할 수 있었다. (오히려 중간중간 일부러 10분 휴식을 두어야 했다.)

TestFirstProgramming 과 PairProgramming 은 집중도에 관해서는 가장 훌륭한 선택인 것 같다. (단, Pair와의 담합행위가 이루어지면 곤란하겠다. -_-;)

진행한 사람 : 강석천, bioinfomatix 에서 일하시는 분들

학습목적이 아닌 실질적인 개발을 위한 PairProgramming 으로는 처음인듯 하다. 2주간 격일로 일을 했었는데, XP 스타일로 프로젝트를 진행하였다.

* Junior 로서의 실수 - 기존 앞에서의 경험에서는 상대적으로 내가 Expert 의 위치에서 작업을 하였다. 이번에는 Junior 의 입장에 서게 되었는데, 기존에 Junior 의 위치에 있었던 사람들의 실수를 내가 하게 되었다. 어려운 부분에 대해서는 이해를 제대로 하지 못했음에도 불구하고 Expert의 속도를 저해할지도 모른다는 생각을 하며 대강 넘어갔었다. (다른 Junior 의 경우도 PP에서 어려움을 겪는 부분중 하나가 이것일지도 모른다. 특히 선후배 관계의 경우) 하지만, 이는 오히려 사태를 악화시킬 수 있다. 프로그래밍 작업을 계속 Expert에게만 의존하게 되기 때문이다. 확실하게 개념을 공유해야 Observer 의 역할과 Driver 의 역할 둘 다 잘할 수 있다. (쉬운 일은 아니다. 확실히)

• 보통 코딩을 주도하는쪽이 빨리 지치며 집중력도 떨어지게 된다. 특히 PairProgramming 의 경우는 상대편 Pair에 대한 배려상 해당 시간에 작업 이외의 다른 일을 거의 하지 않는다. (화장실도 자주 안간다;;)
  
• 상황에 따라 다르겠지만, Driver / Observer 의 교체시간을 두는 것이 좋은 것 같다. 위의 이유에서.
  
• 상황에 따라서는 말로 하는 것 보다 코드로서 이야기하는 것이 더 직관적일 때가 많다. 코드로 이야기 하고, 다시 의견을 듣고 수정하거나 키보드를 넘겨서 리펙토링 하는 식으로 대화할 수 있겠다.
  

• 자존심문제? - Pair를 의식해서여서인지 상대적으로 Library Reference나 Tutorial Source 를 잘 안보려고 하는 경향이 있기도 하다. 해당 부분에 대해서 미리 개인적 또는 Pair로 SpikeSolution 단계를 먼저 잡고 가벼운 마음으로 시작해보는 것은 어떨까 한다.
  

• On-Side Customer 와의 PairProgramming - 프로젝트 중간에 참여해서 걱정했었는데, 해당 일하시는 분과 직접 Pair를 하고 질문을 해 나가면서 전체 프로그램을 이해할 수 있었다. 특히 내가 BioInfomatics 에 대한 지식이 없었는데, 해당 도메인 전문가와의 Pair로서 서로 상호보완관계를 가질 수 있었다.
  
• Junior 의 위치에서 바라본 학습 효과 - 이전에 상경이형이 채팅 프로그램 만드는 법을 직접 보여줬을때가 생각이 난다. (그때 '자. 15분동안 하나 만들어줄께~' 하면서 후다다닥 MFC로 서버/클라이언트 예제를 바로 보여주던 모습은 잊혀지지 않는다;) Junior 의 입장에서 Expert 행동 하나하나는 Check Point 이다. 좋은 습관과 프로그래밍 스타일, 디버깅하는 모습을 직접 눈으로 확인할 수 있었다.
  

진행한 사람 : 강석천, 류상민

ProgrammingContest 에 있는 K-In-A-Row 문제를 푸는 일을 했다.

• 아쉽다면.. 페널티; 흑;;; 답이 안나왔다. --;
  
• 대화 - 상대방이 '알고 있을 것이다' 라는 점도 실제는 모르고 있는 경우가 많다라는 생각을 해본다. 친한친구 이더라도, 상대방을 잘 안다라고 생각하더라도, 상대로부터 읽지 못한 정보는 너무나 많기에.
  
  • 보간법의 오차를 줄이려면 Control Point 를 늘리고, 간격을 좁혀야 할것이다. 잦은 대화는 그 자체가 부하일지 모르겠지만, 또한 오해를 줄일것이다.
    

• 협동 - 이번경우는 비교적 협동이 잘 된 경우라고 생각한다. Python 으로 문제를 풀기 위한 프로그래밍을 하는데는 석천이, Idea 와 중간에 데이터 편집을 하는데에는 정규표현식을 잘 이용하는 상민이가 큰 도움을 주었다. 적절한 때에 적절하게 주도하는 사람이 전환되었던 것으로 기억.
  
• 집중 - 이번 경우에는 '시간제한' 이라는 것까지 있어서인지; 석천은 더더욱 프로그래밍 자체에 집중했다. (스크립트 언어 스타일의 접근방법과 이전의 TDD 연습도 한몫 거든듯. 조금씩 만들고 결과 확인해보고 조금 또 만들어보고 결과 확인을 했다. 단, 이번엔 Test Code 를 안만들어서, 뒤에가서 버그가 났을때 대체를 못했다는.-_-; 잘될때는 문제가 아니다. 잘 안될때, 문제상황에 대한 대처가 중요하다고 생각.)
  

장소와 시간 등의 문제로 PairProgramming를 진행하지 못할때에는 Virtual PairProgramming 을 시도 할 수 있다.
넷미팅, VNC 등의 개발 프로그램을 공유할 수 있는 프로그램과 음성채팅 등으로 Virtual PairProgramming을 할 수 있다. (오.. 좋아진 세상~) 단,PairProgramming 에 비해 아쉬운점들이 있다. (관련 책들을 찾아서 보여주지 못한다는 것 등등) 나중에는 PC카메라와 스캐너 등등 이용할 수 있지 않을까.
1002는 VNC와 넷미팅 (그때 넷미팅 화면공유시 XP가 뻗었던 관계로. -_-;) 을 이용, Python을 공유해서 다른 곳에 있는 사람과 SpikeSolution 을 VPP로 시도한 적이 있다. VNC가 화면 refresh가 느리다는 단점 빼고는 별다른 지장이 없었다. 모르는 라이브러리들을 Pair 하는 사람이 다운받아주고, 라이브러리를 설치하고. 모르는 것은 Pair 에게 물어보고, 어떻게 만들까 토론했던 경험이 좋았다.
대인관계에 대해 소극적인(?) 사람들은 오히려 말이 많아질 수도 있는 방법일듯 하다는. -_-a (하지만, 얼굴 안보이는 사람이라 하더라도 지킬 것은 지키자.!)

• 언어 : PHP
  
• 파트너 : 직장동료
  
• 드라이버 : Benghun
  
• 구현과제 : 데이타베이스 클래스(Database.inc)
  

참고사항 : 몇몇 함수에 대해서만 TDD를 적용시켰다.
나는 .NET의 System.Data의 구조를 보고 즉시 PHP에 적용시키고 싶어졌다. ASP.NET에는 SqlConnection , OdbcConnection , OleDbConnection을 제공해 준다. 이 클래스들을 잘 사용하면 DataTier의 종류가 바뀌어도 코드의 수정을 최소화 시킬 수 있다. PHP는 여러가지 종류의 데이타베이스 관련함수를 제공해준다. 어떠한 데이타베이스를 사용하느냐에 따라 동일한 기능을 하는 다른 이름의 함수를 호출해야만 한다.
IConnection을 이용해 각각의 Connection에 대해 단일의 인터페이스를 제공하고 IConnection을 구현하는 MySqlConnection , SqlConnection , OciConnection을 만들자는 것이 나의 생각이었다. 파트너는 switch구문을 이용해 클래스의 상속 구조를 없애는 것과 비교해서 어떠한 이점이 있는가에 대해 질문했다. 이것은 장시간의 토론으로 이어졌다.
나의 생각은 다음과 같았다.

~cpp 
class IConnection
{
    function Connect(){}
    function Execute(){}
    function Close(){}
    ...
}
 
class OdbcConnection : IConnection
{
    function Connect(){ odbc_connect(); }
    function Execute(){ odbc_do(); }
    function Close(){ odbc_close(); }
}
 
class MySqlConnection : IConnection
{
    function Connect(){ mysql_connect(); }
    function Execute(){ mysql_query(); }
    function Close(){ mysql_close(); }
 
}

파트너의 생각은 다음과 같았다.
하나의 클래스를 구현하고 구현된 하나의 클래스에서 switch로 호출되어야 하는 함수를 결정하면 된다는 것이었다.

~cpp 
class Connection
{
    function Connect()
    {
        switch(UsingDatabase){
            case Odbc: odbc_connect();
            case MySql: mysql_connect();
            ...
        }
    }
 
    function Execute()
    {
        swtich(UsingDatabase){
            case Odbc: odbc_do();
            case MySql: mysql_query();
            ...
        }
    }
}

나는 일차적으로 switch코드를 없앨 수 있다는 점을 설명했다. 우리는 Connection클래스가 그다지 크게 바뀌지 않을 것이라는 것에 대해 동의했었고 이 점을 근거로 switch를 사용하는 것이 유지보수를 힘들게 하는가에 대해 질문했다. 솔직히 이정도 코드라면 누구나 수정할 수 있을 것이라고 생각한다. 그리고 그렇게 많은 시간을 필요로 하는 작업도 아니라고 생각한다. 파트너는 Connection을 생성하는 부분을 include 화일로 관리하고 그곳에 한번만 define문을 작성하면 문제가 없다고 주장했다.

~cpp 
// in GetConnectionObject.inc file
 
define("UsingDatabase", Odbc);
 
function GetConnectionObject()
{
    return new Connection(); 
}

나는 이에 대해 하나의 프로젝트에서 여러개의 데이타베이스를 사용하게 될 경우 여러개의 추가적인 파일들을 관리해야 될지도 모른다고 했다. 그리고 new SqlConnection(); , new MySqlConnection()과 같은 방식으로 사용하는 것이 더 직관적인 것 같다고 설명했다.
추가적으로 토론했던 사항 : Connection 클래스의 생성자에 매개변수로 데이타베이스 타입을 넘겨주면 된다는 것과 파생된 클래스를 생성하는 것
긴 토론 끝에 파트너는 나의 의견에 동의했지만 만약 계속 이런 속도로 작업이 진행된다면 회사에서 가만있지 않을 것이다. (어제도 TDD를 사용했었는데 기존의 코딩시간에 비해 3배정도 더 늦어졌다. 그리고 다 끝내지도 못했고 무엇을 먼저 테스트 해야할지 갈팡질팡했었다. 처음부터 함수단위 테스트만 시도해야겠다는 생각이 원인같다.)
PP의 장점은 토론을 많이할 수 있다는 것(의사소통 + 지식공유?)과 집중력이 높아진다는 것이었다. 처음이라 그런지 코딩시간보다 토론시간이 더 길었다. 기존의 방식대로 혼자 코딩하면 PP를 하는 것 보다 더 많은 코드를 생산할 수 있었다. PP에 익숙해지고 서로의 의견차이를 줄이면 점점 생산속도가 나아지리라 예상해 본다.

See Also

• http://pairprogramming.com - 관련 사이트
  
• http://www.objectmentor.com/publications/xpepisode.htm - Robert C.Martin 과 Robert S Koss 이 대화하면서 Pair를 하는 예제.
  
• http://c2.com/cgi/wiki?PairProgramming - 'PairProgramming Pattern' 이라고 써놓은 것이 재미있다. 어느새 '패턴화' ^^;
  
• PairProgramming토론, PairProgrammingForGroupStudy
  
• PairProgramming, PairProgramming, PairProgramming
  
• http://no-smok.net/nsmk/PairProgramming
  

ExtremeProgramming