억지로일을처리하지아니함

협력 구현은 짝 프로그래밍, 형식적인 정밀 검사, 비형식적인 기술적 검토, 문서 읽기뿐만 아니라 개발자들이 코드 작성과 제품 개발에 관련된 다른 작업에 대한 책임감을 공유하기 위한 다른 긱법들을 가르킨다.

협력 구현의 목표는 명확하다. SW의 품질을 향상시키는 것이다.

협력 구현은 협동 문화와 프로그래밍 경험을 제공한다. - 프로그래머들간의 피드백은 우리의 행동양식과 실력 향상에 도움을 주고 검토의 장을 만들어 SW의 현재와 미래의 품질향상을 가져온다.

공동소유권을 협력적인 구현의 모든 형태에 적용한다.

• 여러 사람이 코드를 보고 코드를 다루면 코드의 품질이 좋아진다
• 누군가가 프로젝트를 그만두더라도 여러 사람들이 코드에 대해서 잘 알고 있기때문에 그 충격이 줄어든다
• 모든 프로그래머가 동등하게 버그를 수정할수 있기때문에 결함 수정 주기가 전체적으로 짧아진다.

짝 프로그래밍(Pair Programming) - 한 프로그래머는 키보드로 코드를 입력하고 다른 프로그래머는 실수를 감시하면서, 코드가 정확하게 작성되고 있는지 그리고 올바른 코드가 작성되고 있는지 전략적으로 생각한다

성공요건

• 코드 작성 표준으로 짝 프로그래밍을 지원하라
• 짝 프로그래밍이 감시가 되지 않도록 한다 - 두 사람 모두 적극적으로 참여해야 한다
• 짝 프로그래밍을 강요하지 마라 - 모든 경우에 짝 프로그래밍이 좋은 것은 아니다
• 정기적으로 짝을 교대하라 - 하루에 한번이 제일 좋다고 전문가들은 말한다
• 짝이 서로의 속도에 맞출수 있도록 하라
• 파트너 모두 모니터를 볼수 있는지 확인하라
• 서로 좋아하지 않는 사람을 짝으로 만들지 마라
• 초보자들끼리 짝을 만들지 않는다
• 팀의 리러를 선정하라

혜택

• 혼자 개발할때 보다 동기부여가 잘 된다
• 코드의 품질을 향상시킨다
• 일정을 단축시킨다
• 협력문화 보급, 신입 프로그래머의 교육, 공동 소유 장려와 같은 협력적인 구현의 모든 혜택을 제공한다.

형식적인 정밀 검사

• 체크 리스트는 과거에 문제가 있었던 영역에 대해 검사자가 관심을 갖도록 한다
• 정밀검사는 결함의 수정이 아니라 발전에 중점을 둔다
• 검사자는 사전에 정밀 검사 미팅을 준비하고 그들이 발견한 문제점 목록을 준비하여 참석한다
• 명료한 역할이 모든 참석자에게 할당된다
• 정밀 검사의 중개자는 정밀 검사중인 제품의 작성자가 아니다.
• 중개자는 정밀 검사의 중개를 위한 특정한 훈련을 받은 사람이다.
• 정밀검사 미팅은 모든 참석자가 적당하게 준비한 경우에만 개최된다데이터는 정밀 검사에 모아지며 결과를 향상시키기 위해서 다음 번 정밀 검사에 제공된다.
• 프로젝트 일정이나 경영자 관련 사항들을 정밀 검사하지 않는다면, 일반 경영자는 정밀 검사 미팅에 참석하지 않는다. 기술 전문가는 참석한다.

다른 종류의 협력적인 개발 방법

• 워크 쓰루(work-throughs) - 개괄적인 검토. 두명 이상의 사람이 참석해서 코드에 대한 논의를 자유롭게 하는것
• 코드 읽기 - 정밀 검사와 워크쓰루의 대안으로서 코드 읽기에서는 소스 코드를 읽고 오류를 찾는다.
• 프리젠테이션 - dog-and-pony shows프리젠테이션은 소프트웨어 제품을 고객에게 보여주는 검토이다.

이 글은 스프링노트에서 작성되었습니다.

테스트는 가장 유명한 품질 향상 활동이다.

• 단위 테스트는 한명의 프로그래머나 팀에 의해서 작성되고 보다 완벽한 시스템으로부터 고립되어 테스트된 완벽한 클래스나 루틴, 또는 작은 프로그램을 실행시키는 것이다
• 컴포넌트 테스트는 여러 프로그래머 또는 프로그래밍 팀의 작업에 필요하고, 보다 완벽한 시스템으로부터 고립되어 테스트된 클래스, 패키지, 작은 프로그래머 또는 다른 프로그램의 요소들을 실행시키는 것이다.
• 통합테스트는 여러프로그래머 또는 프로그래밍 팀에 의해서 작성된 두개 이상의 클래스, 패키지, 컴포넌트 또는 서브 시스템의 결합을 실행시키는 것이다.
• 회귀테스트는 이전에 통과했던 테스트 집합을 가지고 소프트웨어에 있는 결함을 찾기 위해서 이전에 실행했던 테스트 케이스를 반복하는 것이다.
• 시스템 테스트는 다른 소프트웨어와 하드웨어 시스템과의 통합을 포함한 최종 환경에서 소프트웨어를 실행시키는 것이다. 이 테스트는 보안, 성능, 자원 손실, 시간문제, 그리고 저수준 통합에서는 테스트될수 없는 다른 문제들을 테스트한다.

테스트는 내부를 볼수 있는 whitebox와 내부를 볼수 없는 blackbox로 분류된다. 테스트는 오류를 발견하기 위한 방법이고 디버깅은 이미 발견된 오류의 원인을 진단하고 수정하는 방법이다. 테스트의 결과는 품질의 지표이고

이것을 해결하려고 해야 한다.

개발자 테스트에 대한 바람직한 접근 방법

• 각각의 연관된 요구사항들이 구현되었는지를 보장하기 위해서 테스트를 하라.
• 각각의 연관된 설계 사항들이 구현되었는지를 보장하기 위해서 테스트를 하라.
• 요구사항과 설계의 테스트에 상세 테스트 케이스를 추가하기 위해서 '기초 테스트'를 사용하라
• 지금까지 또는 이전 프로젝트에서 발견한 오류의 목록에 대한 체크리스트를 사용하라

테스트 케이스를 먼저 작성하고 개발해야 하는 이유

• 코드를 작성하기 전에 테스트 케이스를 작성하면 코드를 작성한 후에 테스트 케이스를 작성하는 것보다 더 적은 노력이 든다
• 테스트 케이스를 먼저 작성하면 결함을 미리 발견할수 있으며, 보다 쉽게 수정할수 있다
• 테스트 케이스를 먼저 작성하면 코드를 작성하기 전에 최소한 요구사항과 설계에 대해서 좀 더 생각하게 되며, 이는 더 좋은 코드를 만든다.
• 테스트 케이스를 먼저 작성하면 코드가 작성되기 전에 요구사항에 있는 문제를 조기에 노출시킨다. 왜냐하면 요구사항이 잘못되어 있으면 테스트 케이스를 작성하기가 어렵기 때문이다
• 만약 수행해야 하는 테스트 케이스을 저장해 놓는다면, 처음뿐만 아니라 나중에도 테스트 할수 있다

개발자 테스트의 한계

• 개발자 테스트는 "깨끗한 테스트"가 되기 쉽다.
• 개발자 테스트는 테스트 커버리지를 낙관적으로 바라 보는 경향이 있다
• 개발자 테스트는 보다 정교한 테스트 커버리지를 하지 않는다.

테스트 하는데 나쁜 데이터

•  너무 적은 혹은 전혀 없는 데이터
• 너무 많은 데이터
• 틀린 종류의 데이터 - 타당하지 않은 것-
• 잘못된 크기의 데이터
• 초기화되지 않은 데이터

좋은 데이터 -  프로그램에 있는 오류를 찾으려고 할때, 정상적인 경우가 오류를 포함할수 있다는 사실을 간과하기 쉽다. 그래서

• 예정된 케이스, 일반적이고 예상된 값
• 최소한의 정상적인 구성
• 최대한 정상적인 구성
• 이전 데이터와의 호환

전형적인 오류 분류

• 대두분의 오류가 발생하는 범위는 상당히 제한되어 있다
• 많은 오루들이 구현의 도메인 밖에 있다
• 대부분의 구현 오류들이 프로그램의 잘못이다.
• 오타오류(typo)는 굉장히 많이 발생하는 문제이다.
• 설계를 잘못 이해하는 것은 프로그램의 오류에 대한 연구에서 계속 나타나는 주제이다.
• 대부분의 오류들은 수정하기 쉽다
• 자신이 속한 조직의 오류에 대한 경험을 측정하는 것은 좋은 생각이다.

이 글은 스프링노트에서 작성되었습니다.

디버깅은 오류의 근본적인 원인을 규명하여 수정하는 과정으로 초기에 오류를 감지하는 과정인 테스트와는 반대되는 개념이다.

디버깅의 이점

• 여러분이 작업중인 프로그램에 대해서 배울수 있다
• 자신이 저지른 실수의 종류에 대해서 배울수 있다
• 자신의 코드를 읽어야만 하는 사람의 관점에서 자신이 작성한 코드의 품질에 대해서 배울수 있다
• 자신이 문제를 해결하는 방법을 배울수 있다.
• 스스로 결함을 수정하는 방법을 배울수 있다

비효율적인 접근 방법

• 추측으로써 결함을 찾는다.
• 문제를 이해하려고 애쓰느라 시간을 낭비하지 않는다
• 가장 명백한 수정으로 오류를 수정한다 - 오류가 나는 부분과 상관없는 곳을 분석하는데 신경을 쓰지 않는다

결함을 찾는데 도움이 되는 팁

• 가설을 세우기 위해서 사용할수 있는 모든 데이터를 사용하라
• 오류를 만드는 테스트 케이스를 개선하라
• 단위 테스트에서 코드를 다루어라
• 도구를 사용하라 - 디버깅 툴.
• 여러가지 다양한 방법으로 오류를 재생산하라
• 보다 많은 가설들을 세우기 위해서 보다 많은 데이터를 만들어라
• 부정적인 테스트의 결과를 사용하라
• 가능한 가설에 대한 브레인 스토밍을 해라
• 연습장을 준비해서 시도해볼 목록을 만들어라
• 의심스러운 코드 영역을 좁혀라
• 이전에 결함이 있었던 클래스와 루틴을 의심해라
• 최근에 변경한 코드를 검사하라
• 의심스로운 코드 영역을 확장하라
• 점진적으로 통합하라
• 일반적인 결함을 검사한다
• 프로그램에 대해서 다른사람과 이야기를 나누어라
• 문제로부터 떨어져 휴식을 취하라

이 글은 스프링노트에서 작성되었습니다.