실용주의 프로그래머 8. 실용주의 프로젝트

1. 실용주의 팀

지금까지 살펴봤던 실용주의 기법들은 개인뿐만아니라 팀 전체에도 적용할 수 있다.
아래에서 그동안의 기법들 중 일부를 팀 전체에 어떻게 적용할 수 있는지 살펴보자.

• 깨진 창문 없애기
  팀 전체가 상품의 품질에 책임을 져야 마땅하므로 깨진 창문을 용납해서는 안된다.
  품질은 한 사람의 담당자가 책임지는 것이 아니다.

• 삶은 개구리
  프로젝트가 변화하는 것을 팀 전체에서는 느끼지 못할 수 있다.
  누군가 처리하겠거니 생각할 수도 있다.
  항상 변화에 민감하고 합의사항에 있지 않았던 것들이 있는지 점검해야 한다.

• 소통하라
  개인도 팀 안에서 소통해야 하지만, 팀도 다른 세상과 소통을 해야 하는 주체이다.
  훌륭한 팀은 밖에서는 한 목소리로 이야기하고 팀 내에서는 토론을 장려하는 팀이다.

• 반복하지 마라
  중복은 코드에 독이 된다. 쓸데없는 노력을 하게 만들고, 유지보수도 어렵다.
  이 때 필요한 것이 팀 내의 프로젝트 사서이다.
  프로젝트 사서는 문서와 코드 저장소를 관리하며 관련된 정보를 가장 잘 파악하고 있는 사람이다.

• 직교성
  코드를 직교적으로 작성하여 결합도를 줄이듯, 팀도 직교적으로 구성할 수 있다.
  팀을 작은 팀으로 나누어 각각 특정 기능을 책임지도록 하면 한 팀에서 생긴 변화가 다른 팀에 영향을 줄 가능성을 낮출 수 있다.
  이를 통해 품질 향상과 오류 감소를 이끌어낼 수 있으며, 팀원들도 각 팀의 기능을 자신들이 책임지고 있다는 것을 알기 때문에 주인의식을 더 느낄 수 있다.
  다만 이 기법은 개발자 개개인의 책임감과 강력한 프로젝트 관리가 반드시 수반되어야 한다.

2. 유비쿼터스 자동화

자동화는 모든 프로젝트 팀에게 필수불가결한 요소다.
프로젝트에서 자동화가 가능한 부분들을 아래에서 설명하고자 한다.

• 컴파일
  프로젝트를 컴파일 할 때는 makefile을 사용할 수 있다.
  셸을 사용하지 않고 IDE에서 작업하더라도 makefile로 컴파일이 가능하고,
  손쉽게 자동으로 컴파일이 가능해진다.

• 코드 생성
  makefile에 규칙을 추가함으로써 다른 소스에서 자동으로 파일을 생성하도록 하는 것도 무척이나 간단하다.

• 빌드 자동화
  빌드는 비어있는 디렉터리 하나를 가지고 프로젝트를 밑바닥부터 만드는 과정이다.
  이 과정에서 makefile을 통해 빌드를 하게 되고, make test 명령으로 테스트를 실행할 수 있다.
  이 때의 테스트는 전체 빌드의 모든 테스트를 수행해야 한다.

3. 가차 없는 테스트

테스트를 좋아하는 개발자가 얼마나 있을까?
테스트는 미루기 십상이지만 일찍 테스트하면 할수록 고치는데 들어가는 비용이 줄어든다.
코드를 작성하면 바로 테스트하는 것이 좋은데, 프로젝트에서 이루어지는 테스트의 여러 측면을 확인해 보자.

무엇을 테스트할지

• 단위 테스트
  단위 테스트는 하나의 모듈을 테스트한다. 프로젝트에서 각각의 모듈들이 모두 개별 테스트를 통과해야 다음 단계로 넘어갈 수 있다.

• 통합 테스트
  통합 테스트는 결국 단위 테스트의 확장이다. 프로젝트의 주요 서브시스템이 다른 부분과 제대로 연결되어 잘 작동하는지를 확인한다.

• 유효성 평가와 검증
  요구사항을 만족시키지 못했다면, 아무리 버그가 없는 코드라도 쓸모가 없을 것이다.
  최종 사용자가 어떻게 접근하는지, 그리고 그것이 개발자 테스트 데이터와 어떻게 다른지 관심을 가져야 한다.

• 자원 고갈, 에러 그리고 복구
  작성한 코드를 테스트하는 환경은 다분히 이상적인 환경이다.
  실세계는 코드에게 더욱 가혹하다.
  자원이 부족할 때 어떤 식으로 해결할지, 시스템이 실패하면 어떻게 실패할 것인지에 대해서도 테스트가 필요하다.

• 성능 테스트
  성능 테스트, 스트레스 테스트를 통해 성능 요구사항도 만족시키는지 확인한다.

• 사용편의성 테스트
  지금까지의 테스트와는 다르게 사용편의성 테스트는 실제 사용자들이 시행한다.
  인간적 요소라는 측면에서 사용편의성을 바라보고, 소프트웨어가 사용자에게 잘 맞는지 확인해야 한다.

어떻게 테스트할지

• 회귀 테스트
  이전 값과 현재 테스트의 출력을 비교한다.
  오늘 고친 버그가 어제 작동하던 것들을 망치지 않았는지 확인할 수 있다.

• 테스트 데이터
  테스트를 위해서는 데이터가 필요하다. 이러한 데이터들을 어디서 얻을 수 있을까?
  하나는 실세계 데이터이다. 말그대로 실제로 존재하는 데이터, 사용자 데이터를 뜻한다.
  다른 하나는 합성 데이터이다. 인공적으로 생성할 수 있는 데이터로, 통계적 조건하에서 생성된다.

• GUI 시스템 테스트
  GUI 비중이 큰 시스템이라면 특화된 테스트 도구가 필요하다.
  비록 테스트 도구는 여럿 있지만 모든 것을 자동화하기는 어렵다.
  대신 코드를 작성할 때 GUI가 표시되지 않은 상태에서도 로직을 테스트할 수 있을 만큼 결합도가 낮게 설계하기 위해 노력해야 한다.

• 테스트를 테스트
  소프트웨어가 완벽할 수 없는 만큼, 테스트도 완벽할 수 없다.
  따라서 테스트를 테스트할 수 있어야 한다.
  테스트를 작성한 후, 의도적으로 버그가 생기도록 하여 테스트가 이를 감지하는지를 확인한다.

• 철저한 테스트
  테스트 케이스는 버그가 존재함을 보여줄 수는 있지만 버그가 없다는 것을 보여주지는 않는다.
  코드를 충분히 철저하게 테스트했는지는 알 수 없다.
  하지만 커버리지 분석 도구를 통해 테스트가 코드를 얼마나 커버하는지를 알 수는 있다.
  물론 모든 라인이 실행되었다고 해도 모든 상태를 다 커버하는지는 별개의 문제이다.

언제 테스트할지

테스트를 미뤄서는 안된다.
코드가 작성되자마자, 나아가 TDD에서는 코드를 작성하면서 테스트를 수행할 것을 권한다.
테스트를 자동화해서 최대한 자주 실행해야 한다.
자동화하기가 어렵다면 주기적으로라도 할 수 있도록 해야 한다.

4. 결국은 모두 글쓰기

실용주의 프로그래머는 문서화를 전체 개발 프로세스의 한 부분으로 생각한다.

코드내에 있는 주석은 코드가 왜 이렇게 되었는지를 설명할 수 있어야 한다.
어떻게 되어 있는지는 코드 자체로 알 수 있기 때문에 이에 대한 주석은 불필요하다.
또한 프로젝트에서 잘 빠져나갈 수 있는 부분들을 문서화할 수 있는 것이 소스코드의 주석이다.

변수 이름을 정할 때도 의미가 충분히 전달되는 것으로 해야 한다.
foo, manager는 의미가 없는 변수명이다.
객체지향 시스템이라면 헝가리안 표기법을 사용할 이유는 없다.
그리고 의미가 없는 변수명보다 안좋은 것은 오해를 불러일으키는 변수명이다.
이로 인해 같은 실수를 반복하게 된다.

소스코드의 주석에 나와서는 안될 것들은 다음과 같다.

• 파일 내의 코드가 export하는 함수들의 목록

• 리비전 기록

• 파일이 사용하는 파일 목록

• 파일 이름

문서화라고 해서 반드시 종이에 작성해야 하는 것은 아니다.
오히려 모두가 같은 정보를 공유하기 위해서는 종이보다는 웹상에서 같은 문서를 보도록 하는 것이 문서를 유지하기가 쉽다.