'XP'에 해당되는 글 2건

  1. 2010/02/04 극한 상황(?)에서의 짝 프로그래밍 후기 (5)
  2. 2006/08/25 [책 리뷰] Refactoring : 나쁜 디자인의 코드를 좋은 디자인으로 바꾸는 방법 - 1 (2)

극한 상황(?)에서의 짝 프로그래밍 후기

Agile Story 2010/02/04 12:56

특정 클래스(이해 K class)를 사용하기 위한 Adapter interface를 만드는 작업을
같은 회사의 그레이스(저희 회사는 닉네임으로 부릅니다.) 와 짝 프로그래밍으로 수행하였습니다.

스톱워치를 옆에 놓고 10분 단위로 키보드를 바꾸어 가면서
한 사람이 코딩하고, 옆의 사람은 잔소리ㅎㅎ 를 하는 형식이었습니다.

만들어야 하는 interface의 과제는
K class의 메소드를 사용한 바이너리를 에뮬레이터에서 실행시키는 것도 필요한데,
K class의 메소드를 사용한 바이너리를 Dev phone에서 실행시키면 죽어버린다는 것입니다.
바이너리는 에뮬레이터, Dev phone에서 둘 다 실행시킬 수 있어야 하구요.
해서 상황에 따라 K class를 격리(?)시킬 수 있는 구조를 만들어야 한다는 것이 가장 중요한 핵심이었습니다.

짝 프로그래밍 전에는
'격리시키는 구조를 만들어야 한다',
'exception class도 K class의 일부이기 때문에 exception class를 재정의 해야 하나?'
라는 막연한 생각밖에는 없었습니다.

짝 프로그래밍을 진행하면서
우선, 그레이스의 제안으로 인터페이스 하나에서 클래스 2개를 상속받고
하나의 클래스에서만 K class를 사용하자는 생각이 나와서 실행에 옮겼습니다.

그리고, 뭔가 확실한 상황을 알기 위해서 테스트를 진행하였습니다.
둘이서 작업하는 것이라서 테스트 하는 상황을 끊임없이 말로 상대에게 알려 주면서 진행하니 20분 만에 정리가 되더군요
그 결과 'K class를 import/선언만 하고 사용하지 않는 경우에는 Dev phone에서 실행시킬 수 있다' 는 사실을 알게 되었습니다.

클래스, 메소드 naming 도 비교적 원할하게 이루어졌습니다.
한 사람은 생각만 하고 있는데, 다른 사람은 naver 영어사전을 뒤져보는 등의 스킬을 발휘할 수 있었구요

Exception 관련된 내용도
'K class를 사용하지 않기 위하여
별도의 Exception class들을 정의하고, 이 Exception class에 errorCode를 설정하여
사용자가 errorCode에 맞게 handling을 하도록 하자.' 라고 정리가 되었습니다.

약 1시간 30분 정도 이와 같이 진행되었습니다.
이제 전체 클래스의 구조는 완성되었고,
각자 작업을 나누어서 하기만 하면 되는 상황이 되었습니다.

약 3시간 후에 완성된 작업 코드를 보니,
(당연하게도) 두 명이 각자 한 작업의 코드 형식이 거의 똑같았습니다.
마치 한 사람이 짠 것처럼...

이상이 어제 진행되었던 짝 프로그래밍의 시나리오(?) 입니다.

제가 생각하는
어제 했던 짝프로그래밍의 의의(?)는 다음과 같습니다.

- 위의 작업을 혼자서만 진행하였다면,
  두 사람이 사용한 시간(1시간 30분 * 2 = 3시간)을 훌쩍 넘겨 4시간 이상 걸렸을 것이라는 생각이 들었습니다.
  상대방의 생각으로부터 영감을 얻고, 내가 머릿속으로만 생각하고 있는 것을 말로 풀어내는 과정 속에서
  해야 할 것들의 우선순위가 드러나고, 일이 지속적으로 진행이 되더군요.

  게다가, 두 사람이 하나의 모듈에 대한 완벽한 이해도(자기 자신이 직접 만들었으므로)를 가지게 되었습니다.
  이것은 추후에 비상 사태(둘 중 한명이 없다던지, 수정해야 할 양이 많다던지)가 발생하였을 경우에
  상당한 시간 절약 효과로 나타날 수 있습니다.
 
- 짝 프로그래밍 때에는, 옆 사람이 지켜보고 있으므로
  혼자서 일할 때 보다 집중도가 두 배 이상이 됩니다.
  짝 프로그래밍은 빡셉니다. 지치더군요 ㅎㅎㅎ

- 짝 프로그래밍 때에는
  키보드를 안 잡은 사람이 마구 딴지, 수다를 떨어 주어야 도움이 많이 됩니다. (어제는 그랬습니다 ㅎㅎ)

- 무엇보다도 가장 인상 깊었던 것은...
  짝 프로그래밍이 여유있는 상황이 아닌 급한(Extreme한) 상황에서 진행되었다는 것입니다.
 
  짝 프로그래밍이 시작된 시간이 오후 4시, 종료되더라도 6시에 가까운 시간,
  그 이후에 약 3시간 정도의 작업량...
  다소 마음이 급한 상황이었습니다.

  그 상황에서 짝 프로그래밍은 위와 같은 성과를 보여 주었습니다.

  애자일 방법론에서 제시하는 여러 practice들(Scrum, TDD, 짝 프로그래밍 등...)은
  널럴한 상황에서 여유있고 재미있자고 적용하는 것이 아닌,
  급하고 빡센 상황을 대비하고, 헤쳐 나오기 위해서 위해서 시작되었습니다.

  저 개인적으로는 이러한 방법들이 급하고 빡센 상황에서 개발 기간을 단축하는 데
  일조할 것이라는 확신이 있습니다.

한줄로 요약하면
"짝 프로그래밍은 재미있고 유익했다" 입니다. ^^

,
트랙백 : 댓글 (5)

[책 리뷰] Refactoring : 나쁜 디자인의 코드를 좋은 디자인으로 바꾸는 방법 - 1

S/W 방법론 2006/08/25 09:15
참고 URL : http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=267290&CategoryNumber=001001003005006

넥슨에서 근무하며 게임 포털 사이트를 만들고 있을 때, 선배 개발자 형으로부터 한 책을 추천받았다. '리팩토링' 이라는 책이었으며, 간단하게 '리팩토링이란 소스를 다듬는 것이다...' 라고 들었던 것을 기억한다.

이 당시 Java로 커뮤니티 사이트(http://club.nexon.com)를 만들고 있었다. 개발 초창기에 다른 사람(알바)이 한달 정도 끄적거리던 소스를 넘겨받아 보았더니 JSP 파일에 DB 커넥션 하는 부분 및 business 로직까지 몽창 다 들어있던...소싯적 ASP 하던 때와 똑같은 분위기로 코딩되어 있던 것을 보고 경악했던 기억이 있다 -_-. 결국 DB 로직은 따로 빼고, business 로직 부분은 좀 귀찮아서(일정도 있고, 이런 저런 핑계로) 일부은 따로 뺐지만 일부는 걍 JSP 파일에 남겨두었던 것 같다. 다른 사람에 의해 구현되었던 부분이 별로 없었기에 가능했던 일이었을 지도 모르겠다.

암튼 사정이 이러다 보니 다듬는다고 다듬었는데 소스도 꽤 지저분하고, 개념도 덜 탑재되어 있던 상황이라서 소스는 중복에 중복 투성이(문자열 인코딩하는 부분의 소스가 특히 아주 지저분했던 것 같다. 만들었던 메소드 또 만들고 또 만들고 이름만 바꿔 추가하고 등등 -_-;) 였던 것 같다. 그럼에도 불구하고 나름대로 회사 다니면서 학교를 다니던 상황이라서 시간이 빡빡했던 것도 사실이었고(지하철에서 예습복습하고 회사에 늦게 가서 11시 넘어 퇴근하고 다음날 아침에 또 학교가는 생활의 연속 ㅠㅠ) 이러 저러한 핑계로 그 형의 제안을 묵살 아닌 묵살을 해 버리고 말았다.

LG전자에 들어와서 임베디드 S/W 개발자로 커리어 패스를 전환한 후에 이런 저런 스펙(WAP, MMS 관련) 스터디도 하고, XP 관련 세미나도 기웃거리고 하면서 느낀 점은 내가 전에 웹 개발을 하면서 너무 기본을 소홀히 하고 구현에만 급급했다는 생각이었다. 웹 개발자가 웹 스펙조차 본 적이 없었다는 점과 소스 리뷰를 소홀히 했다는 생각이 나를 자책하게 만들었다.

그래서 예전 선배 형에게 심정적인 사죄도 하고, 새로 옮길 팀에서도 리팩토링을 수행하고 있다고 하기에 대비도 할 겸 겸사겸사 책을 구해서 읽게 되었다.

서두가 너무 길었다.

책 내용은 리팩토링을 예제를 들어서 설명하고, 리팩토링의 원리에 대해서 간단히 설명한 후, 리팩토링을 해야 할 징후가 나타나는 코드 속의 징후에 대해 설명한 후에, 리팩토링 시 반드시 필요한 TDD 에서도 사용되는 자동 테스트 프레임워크인 JUnit에 대해 설명한 후, 여러 리팩토링 카탈로그(리팩토링 방법을 사전식으로 죽 나열한 것)에 대한 설명과 예제 나열로 구성되어 있다.

리팩토링을 간단하게 말하면 '코드 정리' 이겠지만, 보다 중요한 개념은 '코드의 의미 명확화' 이다. 저자는 코드 자체가 주석을 필요로 하지 않아도 될 정도로 의미가 명확하게 되는 것을 궁극적인 목적으로 하고 있다. '6. 메소드 정리' 의 내용을 보자면, 긴 메소드에서 짧은 메소드로 추출해 낼 때에도, 아무렇게나 추출하지 않고 적절한 기능을 가진 코드 라인을 그 기능에 걸맞는 명확한 이름을 부여하여 추출해 내야 한다고 말하고 있다. 코드에 임시 지역 변수가 남발되는 것 또한 경계하고 있는데 그렇게 되면 지역 변수가 어떤 역할을 하는지 의미가 모호해져 코드를 분석할 수 없게 되기 때문이다.

JUnit에 대한 설명이 나와 있는 것을 보고 알 수 있듯이, 리팩토링 또한 XP 방법론이 따라가는 철학의 일부라는 생각이 든다. 리팩토링을 완전무결한 Design을 통한 S/W 개발이 아니라, Design은 어느 정도만 하고 추가할 점이 발견되면 그때 그때 개선하는 S/W 개발 방법론(?)을 보조하기 위한 필수 단계로 설정해 놓은 점이 이채롭다.

리팩토링은 퍼포먼스 튜닝과는 대비되는 개념이지만, 퍼포먼스 튜닝을 보조할 수 있는 수단이라는 점도 흥미로왔다. 소스를 정리하고, 복잡한 메소드를 나누며, 복잡한 클래스를 서브클래싱 하는 등 소스를 리팩토링 하게 되면 인스턴스를 많이 생성하게 되는 등 퍼포먼스가 일시적으로는 떨어질 수 있지만, 리팩토링이 완성된 후에는 소스를 이해하기 쉬워지고 퍼포먼스 튜닝하기도 용이해지므로 우선 리팩토링을 한 후에 퍼포먼스 튜닝을 하라는 내용이 정말 공감이 갔다.
사실, 디버깅이나 튜닝이나 실제 디버깅 or 튜닝하는데 드는 시간보다는 디버깅 or 튜닝을 해야 하는 곳을 찾는데 시간이 90% 이상 드는 것이 사실이다. (현재 Trace32 같은 디버거도 없이 폰에 생긴 버그를 수정해야 하는 상황에 있는데 미쳐 버릴 것 같은 것이 현실이다. 더군다나 지금 쓰는 GSM 솔루션은 매우 지저분해서 하나의 함수가 1000 라인이 넘어가는 경우도 허다하다 -_-) 리팩토링은 그 찾는 시간을 줄여줄 수 있는 좋은 수단이 될 수 있을 것 같다.


팀을 무사히 옮기게 되면, 옮긴 팀에서는 리팩토링, TDD 등을 사용해 볼 수 있을 것 같기도 하다. 구슬이 서말이라도 꿰어야 보배라고...실무에 적용해 보고 이 내용에 깊이 공감해 볼 수 있게 되기를 바란다. 리팩토링은 현재 만들어 지고 있는 이론이고, 전산학의 전공 필수 과목처럼 정착된 분야가 아니기 때문에 책 내용은 따분한 이론의 나열이 아닌, 저자의 경험 중심으로 이해하기 쉽고 재미있게 되어 있다. 한 번 읽어 보면 소스 리팩토링할 때에는 물론 코드를 작성할 때의 나쁜 버릇을 고치는 데에도 도움이 많이 될 것 같다.
, , , ,
트랙백 : 댓글 (2)
◀ PREV : [1] : NEXT ▶