8장 : 실용주의 프로젝트

📔실용주의 팀

이 챕터는 팀 전체에게 실용주의 기법들을 어떻게 적용할 수 있는지에 이야기한다.

 

깨진 창문을 없애라

팀 전체가 깨진 창문을 용납하지 않아야 한다.

 

삶은 개구리

단단히 통제되는 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에 대해 둔감할 수 있다.

모든 사람이 적극적으로 환경변화를 감시해야 한다.

애초에 합의사항에 있지 않았던 것들을 항상 점검하도록 하라.

새 요구사항에 대해서는 수치를 보유하라.

이미 일어난 변화를 거부할 필요는 없다 단지, 그런 일이 벌어지고 있다는 것을 알고 있으면 된다.

 

소통하라!

소통이 제일 중요하다!

프로젝트 팀 이름을 유별난 이름으로 지어라!

ex) 신화의 도시, 양을 잡아먹는 앵무새 등등

팀은 정체성 확립의 기반을 얻을 것이다.

 

반복하지 마라

의사소통으로 중복된 일을 제거한다

팀원에게 역할을 부여해서 관련된 일은 해당 팀원에게 물어보는 식으로 하면 좋다.

ex) 팀원 A에게 프로젝트 사서로 임명하여 문서와 코드 저장고를 관리하는 책무를 맡김 다른 팀원이 어떤 정보를 찾을 때 A를 1번째로 찾아간다.

 

직교 성

팀을 기능 중심으로 조직하라.

팀을 기능적으로 분리하고 그 기능에 대해 책임지도록 한다.

이렇게 하면 어떤 변화가 생기더라도 전체가 영향받는 일이 없게 된다.

자신의 산출물에 대해 주인의식을 더 많이 느낀다.

 

자동화

일관성과 정확성을 보장하는 훌륭한 방법은 팀이 하는 모든 일을 자동화하는 것이다.

 

덧칠을 언제 멈출지 알아라

팀은 개인들로 이루어진다는 사실을 명심하라.

각 팀원이 자신의 방식대로 빛나게 해 주어라

그러고 나서 계속 덧칠하려는 욕구를 참는 것이다.

 

📔유비쿼터스 자동화

생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다.
			-알프로드 노스 화이트헤드-

수작업 절차를 사용하지 말아라.

반복적이고 지루한 작업은 컴퓨터에게 시키자 우리에겐 더 중요하고 어려운 일들이 있다.

 

📔가차 없는 테스트

버그 찾기는 그물낚시와 비슷하다

잔챙이를 잡기 위해 촘촘한 그물을 사용 : 단위 테스트

식인 상어를 잡기 위해 큰 그물 : 통합 테스트

일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.

코드를 작성하자마자 테스트해야 한다.

버그가 빨리 발견될수록 고치는 비용이 적어진다.

 

모든 테스트가 통과하기 전엔 코딩이 다 된 게 아니다.

 

무엇을 테스트할지

• 단위 테스트
  • 하나의 모듈을 테스트하는 코드이다.
  • 부분이 그 자체로 작동되지 않는다면 합쳐졌을 때도 당연하게 작동되지 않을 것이다.
  • 모든 모듈이 어떻게 시스템 전체를 통틀어 제대로 사용되고 상호작용하는지 테스트해야 할 필요가 있다.
• 통합 테스트
  • 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다.
  • 통합 테스트는 단위 테스트의 확장에 지나지 않는다.
• 유효성 평가와 검증
  • 실행 가능한 UI나 프로토타입이 갖춰지자마자 질문을 해야 한다.
  1. 사용자들은 무엇이 필요한지 이야기해줬지만 그게 정말 필요한 것인가?
  2. 시스템의 기능적 요구사항을 충족하는가
• 자원 고갈, 에러, 복구
  • 시스템이 실세계의 상황에서 어떻게 작동할지 무한한 자원을 보장받지 못하고 여러 가지로 부족하기 때문에 몇 가지 제한 사항을 맞닥뜨릴 것이다.
    1. 메모리
    2. 디스크 공간
    3. CPU 대역폭
    4. 벽시계 시간 : wall-clock time
    5. 디스크 대역폭
    6. 네트워크 대역폭
    7. 칼라 팔레트
    8. 비디오 해상도
• 성능 테스트
  • 스트레스 테스트 혹은 부하가 걸린 상태에서의 테스트 역시 중요한 부분이다.
• 사용 편의성 테스트
  • 실제 환경의 조건 하에서 실제 사용자들이 시행한다.
  • 인간적인 요소라는 측면에서 바라보라.

 

어떻게 테스트할지

• 회귀 테스트
  • 이전 값(알려진)과 현재 테스트의 출력 값을 비교한다.
  • 오늘 고친 버그가 어제 작동하던 것들을 망치지 않는다고 확신할 수 있다.
  • 새로운 코드를 개발하면서 이전의 것을 잃지 않았다는 확인을 주는 것이다.
• 테스트 데이터
  • 테스트 데이터는 어디서 얻나
  • 실세계의 데이터 : 기존 시스템 혹은 어떤 종류의 프로토타입 등에서 자료를 수집한다.
  • 합성 데이터 : 어떤 통계적 조건하에서 인공적으로 생성된다.
• GUI 시스템 구동
  • GUI 테스트 도구를 사용해서 테스트한다.
• 테스트를 테스트하기 파괴라를 써서 테스트를 테스트하라. 고의로 버그를 심고 테스트가 잡아낼지 검증하는 것이다.
• 철저히 테스트하기
  • 커버리지 분석 도구는 테스트 중에 코드를 지켜보고 코드의 어느 라인이 실행되지 않았는지 기억한다.
  • 코드 커버리지보다 상태 커버리지를 테스트하라.

 

언제 테스트할지

많은 사람들은 테스트를 마지막까지 미룬다. 하지만 일찍 시작해야 한다.

테스트는 대부분 자동화되어야 한다

 

그물 조이기

현존하는 테스트의 그물을 빠져나가는 버그가 있으면, 다음번에는 그걸 잡아 낼 수 있도록 새로운 테스트를 추가해야 한다.

버그는 한 번만 잡아라.

즉, 버그를 발견한 사람이 그때가 그 버그를 찾는 마지막 순간이어야 된다는 것이다.

 

📔결국은 모두 글쓰기

아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다.
			-중국 속담-

한국어도 하나의 프로그래밍 언어인 것처럼 다뤄라.

문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라.

 

코드 내의 주석

너무 많은 것은 너무 적은 것만큼이나 좋지 않다.

단순하고 간략하게 어떻게 사용되는지, 어떤 일을 하는지 설명하는 주석을 달면 좋다.

변수 이름 또한 유의미한 것으로 해야 하고 줄이지 말고 온전한 이름으로 사용해야 한다.

저자의 이름을 주석으로 넣으면 책임감도 생기고 문제가 일어났을 때 바로 찾을 수 있다.

 

온라인으로 출간하라.

웹 문서의 뷰를 최신의 것으로 유지하는 것이 더 쉽다.

 

📔위대한 유산

현실적으로 프로젝트의 성공은 사용자들의 기대를 얼마나 잘 충족하는가에 따라 측정된다.

그들의 기대에 못 미치는 프로젝트는 이론적인 면에서 결과물이 얼마나 훌륭하든 간에 상관없이 실패로 간주된다.

 

사용자의 기대를 부드럽게 넘어서라.

사용자와 소통하는 것이 중요하다.

그들이 기대하는 것보다 조금 더 해서 그들을 기쁘게 해 주어라

상대적으로 손쉽게 추가할 수 있는 기능

• 풍선 혹은 툴 팁 도움말
• 키보드 단축키
• 자동 설치 등등

이것들은 모두 상대적으로 표면적인 것들 이기 때문에 기능 팽창으로 시스템에 영향을 주지 않는다.

 

📔오만과 편견

자신의 작품에 서명하라

자신의 코드뿐만 아니라 다른 사람들의 코드도 존중해주어야 한다.

개발자 간의 황금률("남들이 자신에게 해주기 바라는 대로 남에게 행하라")과 상호존중이라는 기반을 지키는 것이 핵심이다.

코드에는 주인이 있어야 하지만 꼭 개인일 필요는 없다.