[책] Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

2007. 10. 22. 22:52나의 서재

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드 - 10점
자레드 리차드슨 외 지음, 최재훈 옮김/위키북스

 


전반적인 리뷰

래머를 다 읽을 무렵 에서 발견한 책입니다.

어디 한군데 밑줄 치지 않아야 할 곳을 찾기 힘든 래머를 읽고 나서 그 뿌듯함을 계속 간직하기 위해 구입한 책이었는데, 결론적으로 말하면 아쉬움이 많이 남는 책입니다.

실용주의 프로그래머시리즈로 발간된 이 책은 실용주의 프로그래머가 나아갈 보다 실천적인 방향을 제시하기 위해 쓰여졌습니다.  실제로 이 책의 저자는 래머의 저자인 앤드류 헌트와 데이비드 토머스의 열렬한 팬이고 앤드류 헌트가 이 책의 추천사를 직접 써 주기도 했습니다.

 

하지만, 책의 내용 중 상당부분은 이미 다른 책들, 특히 실용주의 프로그래머에서 많은 부분 설명되었거나 반복되는 내용이 많아 집중도가 떨어지고, 이로 인해 새롭다는 느낌이 없어 재미가 많이 반감되는 책이었습니다.

책의 편집상태도 최근에 나온 책들에 비해 아쉬운 부분이 많은데요. 글의 각 절들은 다른 절들과 페이지 구분 없이 바로 이어져 있고, 표나 그림에는 보기 싫게 밑줄로 표시되어 있어 눈이 피곤했습니다.

책의 편집이나, 전반적인 내용에는 아쉬움이 남지만, 지난번 포스팅 “1 회의 - 팀과 관리자를 위한 필수 선택” 에서와 같이 꼭 읽을만한, 도움이 될만한 내용도 분명히 있습니다. 책 한 권에서 배울 점 하나만 발견해도 책의 값은 분명히 한다고 봐야겠죠. 그런 면에서는 이 책은 Must Read 라고 할 만 합니다.

 

책의 주요 내용 정리

9월 달부터 읽기 시작한 책을 이제야 덮다 보니(그간 휴가다 추석이다 해서 책을 많이 멀리 했네요. 반성 하고 있습니다) 책의 내용이 잘 기억나지 않아 다시 한번 책을 뒤적이면서 책의 주요 내용을 정리했습니다.

 

2장 도구와 인프라스트럭쳐 개발을 위해 필히 갖추어야 하는 주요 Infra 에 대한 내용을 주로 기술하고 있습니다.

SCM(Source Code Management) - 주로 소스 코드 관리에 대한 얘기입니다. 저희 회사 같은 경우 아주 오래 전부터 Visual Studio 에 딸려 나오는 Source Safe를 사용하여 공동작업을 하고, 별도 빌드 서버를 두어 빌드를 하고 있었기 때문에 그다지 새롭지 않는 내용입니다.

자동 빌드 시스템 만들기, 지속적인 통합CI(Continuous Integration) – 명령 하나로 이루어지는 수동 빌드시스템을 먼저 구축한 후 자동으로 빌딩 & 배포까지 되도록 체계화 할 것을 권장합니다. 저희는 아직은 IDE 환경이나 간단한 Batch 파일에만 머물러 있어 꾸준히 그 필요성은 인지하고 있지만, 실천으로 잘 옮겨지지 않는 부분이네요

이슈 추적 시스템 주로 버그 등의 주요 개발 이슈들이 관리되고 재현되지 않도록 관리해주는 툴입니다. 저희 회사도 비슷한 시스템을 갖추고는 있으나 체계화 되지는 않았고 부족한 면이 많습니다.

자동화된 테스트 도구 자동화된 테스트 도구의 최종목적은 변경된 소스를 추적하여 자동으로 빌드하고, 이를 테스트까지 해 주는 도구를 말합니다. 저희가 만드는 윈도우 프로그램에서 어떤 식으로 이러한 도구를 적용할지, 이러한 도구가 있긴 한 건지 알 수가 없네요(이런 책들은 주로 자바 등 서버 기술 기반으로 나와 있기 때문에, 책을 읽고도 구체적으로 어떻게 알아 봐야 할 지 난감한 경우가 많습니다)

 

3장 실용주의적 프로젝트 기술 이 책의 핵심이 되는 전달내용이 담겨 있습니다.

목록에 따른 일 처리 프랭클린 플래너의 일일 우선 업무와 같이, 모든 일을 목록화 하고, 각각의 목록은 우선순위를 두어 우선순위가 높은 일 먼저 처리하도록 해야 한다고 역설하고 있습니다. 다들 그렇게 하고 있지요? ^^;

기술 리더 기술적으로 능력 있는 기술리더를 프로젝트 리더와는 별도로 두어 기술리더가 개발자와 사용자, 개발자와 임원들의 중간자 역할을 해야 한다고 조언합니다. 기술리더는 팀이 나가야 할 방향과 프로젝트의 주요 기능 목록을 관리하고, 목록의 우선순위를 부여하는 등의 일을 맡아야 합니다.

매일 협력하고 의사소통하기 - “1 회의 - 팀과 관리자를 위한 필수 선택” 글을 쓰게 된 계기가 된 내용입니다. 매일 팀원들과 특정 시각을 정해 미팅을 하면서, 전일 한 일과, 오늘 할 일을 각자가 1-2분만 구술 하는 회의입니다. 이전 포스트와 중복되어 중략하겠습니다.

코드를 모두 검토하세요 책의 내용은 모든 코드를 제품으로 내보내기 전(Check In)에 코드 검토를 먼저 통과하도록 조언하고 있습니다.  코드 검토의 유용성은 개인적으로도 충분히 공감하지만, 아직 저희 회사에는 이 부분을 강제화 하지는 못하고 있습니다. 가끔씩 후배들의 소스를 코드 읽기를 통해 한 두 시간 투자해서 보는 경우가 있지만, 강제화 된다면, 확실히 지금보다 나은 코드를 만들 수 있을 것 같긴 한데요. 코드 읽기를 하려면, 어느 정도 상급자가 하급자의 코드를 읽도록 해야 하는데 (같은 동료가 코드 리뷰를 할 경우에는 중간에 조정자가 없다면 감정이 상하거나 할 수 있어서) 저희 회사의 경우에는 대부분 동급인 후배들이 많아, 이런 부분에서 어려움이 있어 잘 지켜지지 않고 있습니다.

 

4장 예광탄 개발

예광탄 개발(Tracer Bullet Development)는 큰 그림먼저 그리고 그 큰 그림의 주요 객체를 인터페이스로만 정의한 다음 서로 다른 개발자가 각 인터페이스의 주요 사항을 차차 완성해 나가는 개발방법입니다. 어떻게 보면 테스트 주도 프로그램(TDD – TBD 와 이름도 비슷 ^^)과 상당히 비슷한 개발방법입니다. 내용은 뭐 제 생각에는 당연한 내용인 듯 해서 술술 넘겼습니다.

 

5장 일반적인 문제와 해결방법 – Q&A 식으로 개발하면서 부딪히는 실무적인 문제에 대한 해결 방법을 개발자, 관리자, 사용자 입장에서 답변하고 있습니다.

Daum 블로거뉴스에서 이 포스트를 추천해주세요. [추천]


  • 프로필사진
    BlogIcon 오스카2007.10.23 00:47

    일일 회의를 이제 2년째 하고 있는데 이젠 거의 습관화 되어버린 듯.. 강추입니다. ^^

    테스트 도구는 아직 C++ 개발에 있어서 java나 c# 등에서 가능한 도구에 비해선 아직;;; (상용 툴도 써봤지만.. 글쎄요.. 입니다.)
    특히 UI에 있어서는 역시나 그냥 매크로 툴로 테스트를 자동화하고 그에 대한 로그 파일로 테스트를 하는게 차라리 낫더군요.
    또는 QA 테스터의 입력 값을 저장해서 문제 발생했을 때 그대로 시뮬레이트하는 기능도 써먹을만 합니다.

    • 프로필사진
      BlogIcon esstory2007.10.23 07:53 신고

      저는 이제 겨우 2주째인데.. 2년째 하고 계시다니 대단합니다. 아마 저도 2년째 일일회의를 할 날이 꼭 올거 같습니다.^^;

      예전에 로터스 코리아에 있을때 잠시 QA 를 한적이 있었는데, 그때는 노츠 DB 에 QA 테이블이 있어서 그곳에 모든 테스트 항목을 기록하고, 매번 릴리즈 버전 나올때마다 테스트 항목을 단순 반복해서 문제여부를 확인했었던 기억이 납니다. 아주 짧은 시간동안만 그곳에 일했지만 지금 생각하니 좀 단순 무식했던 것 같네요. UI 개발 프로그램도 좀 더 쉽게 테스트를 자동화 할 수 있는 방법이 있음 좋겠네요..