Yonghwan's Blog

애자일 프랙티스 : 빠르고 유연한, 개발자의 실천 가이드

인사이트; 벤캣 수브라마니암, 앤디 헌트 지음; 신승환, 정태중 옮김

요즘 읽고 있는 책이다. 3주 전부터 읽기 시작했는데 아직이다. 워낙 책 읽는 속도가 느리기도 하고, 또 출퇴근 버스 안에서 주로 읽다 보니 통 진도가 나가지 않는다. 편안히 앉아서 책을 읽을 수 있는 환경이... 간절하다.

실은, 오늘 남은 1/4 정도를 다 읽어야 한다. 회사 도서관에서 빌린 책인데, 기본 2주에 1주 연장한 기한이 오늘이다. 3/4를 이미 읽은 상태인데, 이제 반납 시간이 다가오다보니 별 희한한 생각이 다 든다. 뭐냐면, "살까?" 이런거. 말이 좀 길었는데... 결국 하려던 말은 괜찮은 책이라는 얘기.

먼저, 가벼운 책이다. 복잡한 기술적 설명과 이해가 필요한 책도 아니고 실습이 필요한 책도 아니다. 읽으면서 공감하고, 느끼고, 생각을 배우는 그런 책이다. (요즘 우리 분야에서 이런 책들이 유난히 많이 보이는 것 같다. 나 역시 이런게 목마른 중이라... 이런 책 대환영이다.)

45개의 작은 주제를 악마의 속사귐, 본문, 천사의 충고, 정리/균형잡기의 네 단계로 짤막 짤막하게 이어가고 있어서 나의 경우처럼 토막시간을 이용하여 읽기에 매우 적당하다. 마치, 직장 동료나 선배와 커피 한 잔 마시면서 짧은 대화를 나누는, 그런 느낌으로 읽을 수 있었다는 점이 물리적으로 편안했다.

개념적인 부분부터 세부적인 행동에 이르기까지, 애자일 개발 방법론을 실제로 실무에 적용하기 위한 다양한 실천적 방법들을 설명하고 있다. 간략히 목차를 보면,

 1장 애자일 소프트웨어 개발

 2장 애자일 시작하기

 3장 애자일 기르기

 4장 사용자가 원하는 내용을 제공하기

 5장 애자일 피드백

 6장 애자일 코딩

 7장 애자일 디버깅

 8장 애자일 협력

 9장 에필로그: 애자일로 이동하기

1~3장은 "애자일"의 본질, 개념에 가까운 내용으로 구성되어 있고 4~8장은 주로 그것을 행동에 옮기는 방법에 대하여 다루고 있다. 행동에 대한 부분은 굳이 애자일이라는 용어로 설명하지 않더라도 유용한 부분이며 이미 많은 사람들이 실천하고 있거나 최소한 적용을 위한 노력을 기울이고 있는 내용들이긴 하다. 하지만 이렇게 "애자일 방법론"이라는 주제 안에서 바라보니 왠지 새로운 느낌을 준다.

음... 특히 변화를 꿈꾸는 팀에게 권하고 싶다. 확실히 또는 막연히 느끼고는 있으나 뭘 어떻게 해야 할지 갈팡질팡 헤메고 있는 팀이 있다면, 이렇게 부담스럽지 않은 분량의 짧은 주제를 한 주에 한 두 개씩 함께 읽고, 토의하고, 적용해 나가는 방식으로 변화의 흐름을 타 보는 것도 좋을 것 같다.

코드리뷰에 대한 좋은 글이 있어서 인용한다. 그런데, 한 문장도 빼놓기가 아까운게... 잔뜩 인용해버렸다. :-)

BSBlog » Blog Archive » The Power of Code Review

For the most part, reviewers are not responsible for ensuring correct code function: unit tests are much better suited to that task. What reviewers are responsible for is much more “social”, and typically does not require a detailed line-by-line analysis of the code to perform a review. In many cases, important parts of the review process should happen before a coder starts working on a patch, or after APIs are designed but before implementation.

There are some important side effects of the review process that are also beneficial:

• More than one person knows every piece of code. Many Mozilla modules have grown a buddy system where two people know the code intimately. This is very helpful because it means that a single person going on vacation doesn’t imperil a release or schedule.
• Reviewing is mentoring. New hackers who are not familiar with a project can be guided and improved through code review. Initiall, this requires additional effort and patience from the reviewer. Code from inexperienced hackers deserves a much more detailed review.
• A public review log is a great historical resource for new and experienced hackers alike. Following CVS blame and log back to bug numbers can give lots of valuable historical information.

There can’t really be general guidelines on how much time to spend reviewing. Some experienced hackers may spend up to 50% of their time doing reviews (I typically spend two days a week doing design and code reviews and various planning tasks). This can be hard, because coding feels much more productive than reviewing.

나의 지론, 휴가 가고싶으면 잘 하란 말이다.