1. 협력 개발 방법 개요
•
협력 구현은 페어 프로그래밍, 형식적인 정밀 검토, 비형식적인 기술 검토, 문서 읽기와 더불어 개발자들이 코드 작성과 제품 개발에 관련된 작업의 책임을 공유하는 데 사용하는 기법을 일컫는다.
•
모든 협력 구현 방법들의 중요한 부분은 개발자가 자신의 작업의 문제점을 일부 보지 못한다는 점과 다른 사람들은 볼 수 있다는 점, 그리고 다른 개발자가 자신의 작업을 봐주는게 도움이 된다는 것이다.
다른 품질 보증 기법을 보완하는 협력 구현
•
다양한 연구들이 협력 기법이 오류를 잡는데 테스트보다 더 효과적일 뿐만 아니라 테스트와는 다른 종류의 오류(설계 등)을 찾을 수 있음을 보여줬다.
•
테스트만으로 발견할 수 없는 오류(부적절한 주석, 하드코딩된 값) 등을 찾아낸다.
협력 구현은 협동 문화와 프로그래밍 경험을 제공한다
•
컨벤션을 작성하고 팀에 배포할 수는 있지만 구성원들이 컨벤션을 꾸준히 언급하고 주의에 두지 않는다면 지키지 않을 것이다.
•
리뷰는 개발자들에게 코드에 대한 피드백을 제공하는 중요한 메커니즘이다. 코드와 표준, 코드가 표준을 준수해야 하는 이유가 리뷰에 대한 가장 훌륭한 주제가 된다.
공동 소유권을 협력 구현의 모든 형태에 적용한다.
•
이런식의 공동 소유권 개념을 적용하게 되면 모든 코드를 개인이 아닌 팀이 소유하고 접근, 수정할 수 있게 된다. 이는 다음과 같은 혜택들을 제공한다.
◦
여러 사람이 코드를 보고 다루면 코드의 품질이 좋아진다.
◦
여러 사람이 코드에 대해서 잘 알고 있기 대문에 누군가가 프로젝트를 나가더라도 문제가 덜하다.
◦
모든 개발자가 동등하게 버그를 수정할 수 있기 때문에 결함 수정 주기가 짧아진다.
•
저자는 개인적으로 페어 프로그래밍과 같이 좋은 코드 품질을 위해서 형식적으로 짝을 지을 필요 없이 형식적이거나 비형식적인 기술 검토로도 충분하다고 했다.
협력을 구현 전 만큼이나 구현 후에도 적용한다.
•
검토를 코드 리뷰에 국한시키지 않고 측정, 계획 수립, 요구사항, 아키텍처 설계, 테스트, 유지보수 전 작업에 적용시킬 수 있다는 취지다.
2. 페어 프로그래밍
페어 프로그래밍의 성공 요건
•
코드 작성 표준으로 페어 프로그래밍을 지원하라.
•
페어 프로그래밍이 감시가 되지 않도록 하라.
◦
키보드가 없는 사람이 프로그래밍에 적극적으로 참여해야 한다. 그 사람은 코드를 분석하고 다음에 어떤 코드가 작성될 것인지 미리 생각하여 설게를 평가하고 코드를 테스트하기 위한 방법을 계획해야 한다.
•
페어 프로그래밍을 강요하지 마라.
◦
무조건 옳은 것은 세상에 없다. 복잡한 문제의 경우, 페어 프로그래밍을 하는 것보다 단독으로 수행하는 것이 더 나을 수 있다.
•
정기적으로 페어와 작업을 교대하라.
•
서로의 속도에 맞출 수 있도록 하라.
•
파트너 모두 모니터의 내용을 확인할 수 있게 하라.
•
사이가 좋지 않은 사람을 페어로 두지 말라.
•
초보자끼리 페어를 짓지 않는다.
•
팀의 리더를 선정하라.
페어 프로그래밍의 혜택
•
혼자서 개발할 때보다 압박들 더 잘 견딘다. 페어는 품질을 유지하기 힘든 상황에서도 품질을 유지할 수 있게 서로를 격려한다.
•
코드의 품질을 향상시킨다. 코드의 가독성과 이해 용이성이 향상된다.
•
일정을 단축시킨다. 페어 프로그래밍은 더 빠르면서도 오류가 적은 코드를 작성하게 해주는 경향이 있다.
•
협력 문화 보급과 개발자의 교육, 공동 소유 장려와 같은 협력 구현의 다른 모든 혜택을 제공한다.
3. 형식적인 정밀 검토
•
정밀 검토는 결함을 발견하는 데 매우 효과적이며 테스트에 비해서 상대적으로 경제적인 것으로 알려진 검토의 한 종류다.
•
다음과 같은 여러 가지 핵심적인 방법에서 평범한 검토와 차별화된다.
◦
체크리스트를 이용해 과거에 문제가 있었던 영역에 정밀 검토자가 주의를 기울이게 해준다.
◦
정밀 검토는 결함 수정이 아닌 발견에 중점을 둔다.
◦
정밀 검토자는 미리 정밀 검토 회의를 준비하고 그들이 발견한 문제점 목록을 미리 준비하여 참석한다.
◦
모든 참석자에게 명료한 역할을 할당한다.
◦
정밀 검토의 중재자는 정밀 검토 중인 제품의 작성자가 아니다.
◦
중재자는 정밀 검토의 중개를 위한 특정한 훈련을 받은 사람이다.
◦
정밀 검토 미팅은 모든 참석자가 적합하게 준비한 경우에만 주최한다.
◦
데이터를 정밀 검토마다 모으고 다음 번 정밀 검토에 제공해 결과를 향상시킨다.
◦
프로젝트 일정이나 경영자 관련 사항을 정밀 검토하지 않는다면 굳이 일반 경영자를 참여시키지 않는다. 반면에 기술 전문가는 참여할 수 있다.
정밀 검토의 효과
•
설계 정밀 검토와 코드 정밀 검토를 조합하면 대개 제품 결함의 70% ~ 85%를 제거할 수 있다.
•
정밀 검토는 오류가 발생하기 쉬운 클래스를 초기에 찾아낸다.
•
정밀 검토를 진행 상태를 평가함에 있어서도 사용할 수 있지만 기술적인 작업이 진행되고 있는가? 그 작업을 잘 처리하고 있는 가에 대한 의견을 확인할 수 있다.
정밀 검토에서의 역할
•
중재자
◦
중재자는 정밀 검토의 진행 속도를 유지하여 생산성을 유지하게끔 한다.
◦
기술적으로 유능해야 하며 검토 관련 세부 사항을 이해하고 있어야 한다.
•
작성자
◦
설계나 코드를 작성한 사람은 정밀 검토에서의 역할이 비교적 적다.
◦
피드백을 바탕으로 정밀 검토의 결과를 반영하는 역할을 수행한다.
◦
분명하지 않은 설계나 코드 부분을 설명하고 오류로 보이는 것이 실제로는 타당한 이유에 대해서 설명할 수 있어야 한다.
•
검토자
◦
설계나 코드에 관심이 있지만 작성자는 아닌 사람으로 결함을 찾는 것이 그의 역할이다.
•
서기
◦
서기는 발견된 오류와 정밀 검토 회의 중에 있었던 조치 항목을 기록한다.
•
적어도 세 명 이상이 참여해야 하며 역할이 겹쳐서는 안 된다.
정밀 검토의 일반적인 절차
•
계획 → 개요 → 준비 → 정밀 검토 회의 → 정밀 검토 보고 → 재작업 → 후속 조치 → 추가 회의
4. 여러 가지 협력 개발 방법
•
워크스루, 코드 읽기, 데모, 등이 존재한다.
요점 정리
•
협력 개발 방법은 테스트보다 결함을 발견하는 비율이 높고 좀 더 효율적으로 결함을 찾을 수 있다.
•
협력 개발 방법은 테스트보다 더 많은 종류의 오류를 찾을 수 있으며 소프트웨어의 품질을 보장하기 위해서 검토와 테스트를 모두 사용해야 함을 의미한다.
•
형식적인 정밀 검토는 체크리스트, 사전 준비, 잘 정의된 역할, 지속적인 프로세스 향상을 사용해 오류 탐지 효율성을 극대화한다. 정밀 검토는 워크스루보다 더 많은 오류를 찾는다.
•
페어 프로그래밍은 전형적으로 정밀 검토와 비슷한 비용이 들고 유사한 품질의 코드를 생산한다. 페어 프로그래밍은 일정을 줄여야할 때 특히 더 유용하다.
•
형식적인 정밀 검토는 코드 작성뿐만 아니라 요구사항, 설계, 테스트 케이스같은 것에도 사용할 수 있따.
•
워크스루와 코드 읽기는 정밀 검토의 대안이다. 코드 읽기는 개인의 시간을 효과적으로 사용할 수 있다는 장점이 존재한다.
