그동안 번역서만 마구 읽어대곤 했는데 번역서를 읽다보면 갑자기 머리가 띵해지는 경우가 많다. 반면에 이 책은 여름으로 가는 문이라는 블로그를 운영하시는 채수원님이 작가이고 실무경험에서 우러나오는 여러 알찬 정보들이 많다.

TDD는 예전부터 관심이 많았었고 켄트벡의 테스트주도개발책과 동영상 등을 접했으나 역시나 TDD는 어렵다는 생각이 든다. ㅠㅠ 특히 필자처럼 허접내공으로 무턱대고 달려드면 오히려 개발기간만 늘어나는 역효과를 가져올수도 있다.

그렇지만 배우기 어렵고 까다로운 TDD일지라도 일단 익숙해지면 그 무엇보다도 코드의 품질을 향상시킬수 있다. 게다가 개발의 단계가 테스트-코딩-리팩토링의 반복으로 단순화되면서 개발의 리듬감을 찾을 수 있게 된다.
필자도 지금까지 계속 나름대로 연습을 해오고 있지만 아직까지도 익숙하지 않다. 특히나 일정의 압박이 몰려오는 프로젝트후반부의 운영이 많이 힘든 것 같다.

일단 이 책을 다 읽는 데 그렇게 오랜시간이 걸리지는 않았다. 유닛테스트나 TDD에 관심이 있는 개발자라면 비교적 빠른시간에 지루하지 않게 볼 수 있는 내용이다.
또한 초보자가 접근하기에도 괜찮아보인다. 이 책의 시작부분에는 junit의 IDE 설정방법이라던지 초보자들도 참조할만한 내용이 많다. 시작부분은 켄트벡의 TDD책과 마찬가지로 간단한 은행계좌예제를 TDD방식으로 해결해나가는 방법으로 시작하고 있다. 중간부분에 Hamcrest와 Mock프레임워크를 이용하는 부분이 나오고 데이터베이스연동테스트를 수행하는 DBUnit에 관한 내용도 나온다. 마지막으로는 자동판매기 잔돈 계산 모듈을 TDD로 해결해 나간다.
중간중간에 주석과 저자한마디가 나오는데 내용의 흐름을 막거나 하진 않고 9장의 FAQ도 평소 궁금했던 점들에 관한 내용이 많아 만족스러웠다.

이책의 마지막 예제부분에 다음과 같은 내용이 나온다.
만일 개발할 부분에 대한 이해가 명확하지가 않다면, 개발 시작하기 전에 간단한 사용자 시나리오를 작성해 보는 것도 좋은 방법이다.
애자일방식으로 개발한다는게 설계와 시나리오도 없이 무턱대고 IDE 새파일로 달려드는건 아니라고 생각한다. 문서나 스펙협의에 들어가는 노력과 비중을 줄이고 빠른 피드백과 리팩토링을 선호하는 방식일 것이다.
그렇기때문에 TDD방식으로 개발을 진행할때도 어느정도의 설계와 시나리오를 가지고 접근하는게 더 좋다라는게 필자의 의견이고 100% 동감한다.

TDD는 어찌보면 외국어를 학습하는 것과 비슷하다는 생각이 든다. 이미 하나의 언어에 익숙해지도록 성장한 후에 다른 외국어를 배우려면 많은 노력이 필요하다. TDD도 마찬가지로 Top-down 방식과 납품일 위주의 개발스타일방식에서 전환하기엔 쉽지 않다. 아예 프로그래밍을 시작할때 TDD방식으로 시작하는게 가장 좋을 것이다. 하지만 대부분은 이미 다른 개발방식에 익숙해져있는 상황일 테니 이런 경우엔 계속 끊임없는 연습만이 해결방법일 듯 하다.

그런면에서 이 책은 TDD에 관한 많은 내용이 들어가 있고 또한 노하우가 담겨있다. 개발을 어느정도 해 왔던 경력자나 이제 개발을 시작하는 초보자 모두에게 권하고 싶은 책이다.


사진출처 : 강컴


저자블로그 : http://blog.doortts.com/
책주문 : http://kangcom.com/sub/view.asp?sku=201006080010




DDD에 대한 내용을 공부중인데 온라인을 통한 자료에 한계를 느껴 원서를 하나 주문했다.
가격은 자그만치 6만원이 넘고 총 페이지수가 500페이지가 넘는다 @_@
그나마 다행인게 글씨 크기가 크다는 거고 내용은 더 말할필요도 없이 DDD의 바이블이라고 해도 될 만큼 알차다.
이제 부지런히 읽는 일만 남았다.





켄트벡의 구현 패턴

2009.10.27 00:06

아시는 분은 다 아시는 켄트벡의 구현패턴이다(Implementation Patterns). 보통 디자인패턴하면 GOF(Gang of four)를 떠올리게 되지만 GOF의 패턴은 왠지 어렵고 쉽게 개념이 다가오지 않는다.
(게다가 샘플소스가 C++이다 -.-)
하지만 켄트벡의 구현 패턴 책은 일단 얇다 ^^;  그리고 실질적으로 당장 응용가능한 주옥같은 정보들이 얇은 책 안에 가득차 있다. 

이 책 2장에 보면 다음과 같은 내용이 있다.  심금을 울릴만한 내용이다.
  • 프로그램을 새로 짜는 경우보다는 기존 프로그램을 읽는 경우가 많다.
  • 프로그램에 있어 "완성"은 없다. 최초에 프로그램을 개발하는 데 드는 노력보다는 이후 프로그램을 수정하는 데 들어가는 노력이 더 크다.
자바로 코딩을 한다면 마틴파울러의 Refactoring 책과 더불어 필독서라 할 만 하다.

바로가기



헤드퍼스트 시리즈를 좋아하기 때문에 이번에도 기대를 가지고 책을 보기 시작했고 다 보는데 딱 4일정도 걸린것 같다.
일단은 헤드퍼스트 시리즈답게 설명이나 내용을 이해하는데 큰 무리가 없다.  개발쪽 경험이 좀 있다면 이 책을 다 보는데 1주일도 안 걸릴것이다.
이 책에서는 XP니 Scrum이니 하는 구체적인 용어가 나오지는 않지만 애자일기반의 소프트웨어 개발 전반에 걸쳐 설명한다. 특히 스탠드업미팅, 30일 주기, 프로젝트 진행 현황판 등 Scrum의 주요 개념들이 많이 나온다.
하지만 책을 보다보면 다수의 오탈자가 보이는데 편집과정에서 충분히 체크되지 않은점이 아쉽다. 또한 애자일개발방법론에 대해 이미 스터디하고 있는 사람한테는 이 책의 위치가 좀 애매하다.
개인적으로는 다른 Head First 시리즈 책보다는 점수를 짜게 주고 싶다. 애자일 프로세스에 대해 가볍게 리뷰한다는 개념으로 접근하신다면 추천한다.





 아마도 모르는 분이 없을 정도로 유명한 마틴파울러 아저씨의 책이다. 참고로 난 이 책을 보고 과거 저질렀던 수많은 죄악이 떠올라 순간 당황한 기억이 있다.
 책 구성은 굉장히 독튼한데 초반부에 비디오 가게의 간단한 고객관리 프로그램을 리팩토링 해 가는 과정을 설명하고 있으며 후반부에는 상세 리팩토링 카탈로그를 설명한다.
여기 초반부에 보면 구조가 상당히 당황스러운 코드가 나오는데  그때 당시에는 내가 즐껴 쓰던 패턴이었다  아놔 ㅡ.ㅜ
 지금은 왠지 한 화면 넘어가는 메소드를 보면 자연스럽게 추출(extract method)하고싶은 충동이 생긴다 -.-
이 책에서는 쓸데없는 주석도 나쁜습관이라고 되어 있는데 코드가 명확하다면 주석자체가 필요없다는 논리다.
 



국내 소프트웨어 여건상 대부분의 작업이 제품 개발 형태가 아닌 커스텀 소프트웨어(고객 주문 소프트웨어)로 개발이 되는 것 같다.  그래서 요즘 읽고 있는 린 소프트웨어 개발의 적용이란 책에 다음과 같은 내용이 나오는데 흥미롭다.

'프로젝트와 제품 개발 모델 사이엔 다음과 같은 차이점이 있다. 프로젝트는 시작과 (명백한) 끝이 있다. 반면, 제품 개발에 시작은 있지만 (바라건대) 끝은 없다. 소프트웨어는 프로젝트라기보다 제품 개발에 훨씬 더 가깝다. 왜냐하면, 대부분 좋은 소프트웨어는 오랫동안 사용되고 변화해가기 때문이다. 전체 소프트웨어의 과반수 이상이 첫 공식 릴리스 이후에 개발되는것을 보면 쉽게 알 수 있다.'

또한 이 책에서는 같은 팀이 개발에서 유지보수까지 맡는 경우가 좋다라고 설명하고 있는데 그 이유는 대부분의 소프트웨어가 오랜 수명주기 동안 업그레이드와 개선이 이루어지는데 고객, 코드, 해당 분야에 대한 지식은 다른 팀에 전달하기가 어렵기 때문이라고 주장한다.

우리같은 경우 실상을 보면 프로젝트를 마감하고 유지보수는 별도의 SM이라는 전문 조직이 들어와서 관리를 한다. 이런 형식이 나쁘다는건 아니지만 우리도 제품이라고 할 수 있는 분야가 많이 늘었으면 하는 바램이다.