Head First Software Development

 Head First Software Development – 훌륭한 소프트웨어 개발을 위한 핵심 가이드

 

 아무생각 없이 이책을 처음 봤을 때(읽었다는 의미가 아니고 처음 접했을 때, Just See -_-), 헤드 퍼스트 시리즈가 대대적으로 나쁜 책이 없다는 걸 알고는 있었지만, 그렇게까지 좋은 책은 아닐꺼라고 생각을 했다.

 왜냐하면, 소프트웨어 개발 프로세서는 좀 복잡하고 깊은 내용이 필요해서, 이렇게 적은 페이지의 책으로 얼마나 충실히 표현했을 까 하는 의문이 들었기 때문이었다. 먼저 평점부터 매기자면 초보자에게는 꼭 읽어볼 것을 권하고 대략 80점 이상, 중급 이상에게도, Agile 이라는 프로세서를 맛본다는 점에서는 70점 이상을 주고 싶다.

 

 책을 보면서 느꼈던 것중에 하나가, 처음에 목차의 순서가 조금 맘에 안들었다.

 왜냐하면 이 책의 기본적인 흐름은 크게 다음과 같다.

 

  • 애자일 프로세스

    • 이터레이션
    • 사용자스토리
    • 스탠드업 미팅
  • 충분히 훌륭한 설계(완벽한이 아님)
  • 버전관리
  • 일일빌드
  • 지속적인 통합
  • TDD
  • 프로세스 정착하기

 

 훌륭하게 보이지만, 사실 개인적으로는 애자일 프로세스 윗단에

 버전관리, 일일빌드, 지속적인 통합 등은 기본적으로 들어가야 하지 않을까 하고 생각했다.

 

 그런데 책을 읽다 보니, 웬지 왜 저런식으로 목차를 잡아놓았는지 조금 이해가 갔다.(만구 내 생각)

 이유는, 모든 프로세스 중에서 가장 중요한 것은, 고객을 만족시키는 것이기 때문이다. 위에서 애자일

프로세스 라고 적었지만, 저것의 핵심은, “고객이 진정으로 원하는 프로젝트 성공시키기” 이기 때문이다.

 

 그래서, 최초에, 더 핵심에 가까운 부분을 배치시키고, 중요한 나머지는 뒷부분에 배치시킨 것이다.

 

개인적으로 이 책이 각 부분에 대한 깊은 지식을 전해주지는 못한다고 생각한다. 하지만, 입문서로는 꽤 훌륭하다고 생각한다. 왜냐하며, 위의 애자일 프로세스나, TDD 등은, 단순히 이론적으로 이해해서는 안되고, 스스로 익숙해지기 전까지는 제대로 되기 어렵기 때문이다. 나 역시 TDD를 조금씩 해볼려고 깔짝거리지만, 주화입마로 퍽퍽 떨어져 나가고 있다.

 

 진정으로 이해했다는 말은 스스로 행할 수 있다는 것이다. 단지 “지식” 만이 전부가 아니므로, 도전, 도전 도전이 필요하다.  

나의 첫 번째 TDD – 결과

  회사에서 해야하는 프로젝트에 TDD를 적용해 보겠다고 생각을 했었다.

 

보통 TDD의 단계는 다음과 같다.

  1. 실패하는 테스트를 작성한다.
  2. 실패하는 테스트를 간단하게 성공하게 만든다.
  3. 다시 실패하는 테스트를 작성한다.(1번 보다 더 테스트를 할 수 있는…)
  4. 다시 실패하는 테스트를 성공하게 만든다.

 

위의 단계를 기본적인 함수군을 테스트 하는데는 유효했다.

그런데 캡슐화된(? 정말일까?) 클래스를 테스트 하면서 부터, 인터페이스를 public 으로 고치든지

새로운 클래스로 상속받아 임시로 protected: 를 public 으로 수정한 함수를 제공한다든지의 방법을

사용하게되었는데 -_-;

 

 이러면서 테스트가 조금씩 문제가 발생하기 시작했다. -_-

 

 그리고 뒤의 테스트를 추가하기 위해서 인터페이스가 바뀌면 이전의 테스트를 수정해야 하는 문제도

발생했다.

 

 그리고 결정적으로, 어떤 식으로 클래스의 동작을 제대로 체크할 것인가가 문제가 되었다.

 

내가 작성하는 프로그램은, 네트웍, GUI를 모두 사용하는 데, 이에 대해서 Mock을 사용할 것인지 아니면

실제로 테스트를 붙일것인지도 문제가 되었다.

 

 단순 UI와의 통신이 아니라, 나의 클래스는 UI 생성을 내부적으로 해야하는 기능도 있었기 때문에, 제대로

UI가 나타났는지도 테스트를 해야만 했다. -_-

 

 결국 일정이 급해지고, 이것 저것 수정하면 TDD는 잠시 무너진 T.T 그러나 단순 함수들에서도 실수가 많았는데 TDD를 이용하면서 단순 함수군에 대해서는 꽤 좋은 효과를 볼 수 있었다.

 

 이번 실패의 큰 원인은,

  1. 테스트를 어떻게 할 것인지, 제대로 생각하지 못했다.

    1. 이게 제일 크다.
  2.  네트웍, GUI 등에 대해서 테스트를 할 수 있는 인터페이스를 제대로 뽑지 못했다.

    1. 즉, 기존 설계가 좀 잘못되었다. -_-

 

 이번 경험을 삼아서 좀 더 제대로 설계를 하고, 제대로 TDD를 전개해 봐야겠다.

 

 TDD 프레임웍은 구글 테스트를 이용했다. 환경은 Window Mobile 6.1