21장: 협력 구현

21장 협력 구현

내용

• 21.1 협력 개발 방법 개요
• 21.2 짝 프로그래밍
• 21.3 공식적인 정밀 검토
• 21.4 여러 가지 협력 개발 방법

관련 주제

• 소프트웨어 품질: 20장
• 개발자 테스트: 22장
• 디버깅: 23장

• 구현의 선행 조건: 3장과 4장

• 많은 개발자가 흔히 겪는 경험을 여러분도 직접 경험한 적이 있을 것이다. 가령 문제가 있을 때 동료 개발자에게 찾아가서 이렇게 말한다. “이 코드 좀 봐줄래요? 지금 이것 때문에 헤매고 있거든요.” 그러고 나서 문제를 설명하기 시작한다. “이건 이렇게 해서 이런 결과가 나올 수 없고, 그건 그래서 그런 결과가 나올 수 없잖아요. 그리고 저건 저렇게 해서… 아! 잠시만요! 저런 결과가 나올 수 있겠군요. 고마워요!” 결국 “도우미”가 입도 뻥끗하기 전에 직접 문제를 해결한다.
• 어떤 방법을 사용하든 모든 협력 구현 기법은 오류 해결을 목적으로 자신의 작업 내용을 다른 사람에게 보여주는 과정을 형식화하려는 시도다.
• 정밀 검사나 짝 프로그래밍에 대해서 들어본 적이 있다면 이 장에서 새로운 정보를 많이 얻지는 못할 것이다.

21.1 협력 개발 방법 개요

• “협력 구현”은 짝 프로그래밍, 형식적인 정밀 검토, 비형식적인 기술 검토, 문서 읽기와 더불어 개발자들이 코드 작성과 제품 개발에 관련된 다른 작업에 대한 책임을 공유하는 데 사용하는 기법을 가리킨다.
• 모든 협력 구현 기법은 서로 차이는 있지만 개발자가 자신의 작업에 있는 문제점을 일부 보지 못한다는 점과 다른 사람들은 그 부분을 볼 수 있다는 점, 다른 개발자가 자신의 작업을 봐주는 게 도움이 된다는 개념을 기초로 한다.

다른 품질 보증 기법을 보완하는 협력 구현

• 협력 구현의 일차적인 목적은 소프트웨어의 품질을 향상시키는 것이다. 20장 “소프트웨어 품질”에서 강조했듯이 소프트웨어 테스트는 단독으로 사용되면 효율성에 한계가 있다. 협력 구현의 부차적인 혜택은 개발 시간이 줄어든다는 점인데, 그로 인해 개발 비용이 줄어든다.
• 짝 프로그래밍에 대한 초기 보고서는 짝 프로그래밍이 형식적인 정밀 검토와 비슷한 수준의 코드 품질을 달성할 수 있다고 제안한다(Shull et al 2002).
• 기술적 검토는 짝 프로그래밍보다 훨씬 오랫동안 연구되어 왔고 다음의 사례에서 설명하고 있는 것처럼 그 결과가 인상적이다.
• IBM은 한 시간의 정밀 검토가 약 100시간의 관련 작업(테스트와 결함 수정)을 예방한다는 사실을 발견했다(Holland 1999).
• 레이시온(Raytheon)은 정밀 검토에 초점을 맞춘 개발을 통해서 결함 수정(재작업) 비용을 프로젝트 총 비용의 약 40%에서 20% 정도로 줄였다(Haley 1996).
• 휴렛팩커드는 정밀 검토 프로그램이 연간 2,150만 달러의 비용을 절감했다고 보고했다(Grady and Van Slack 1994).
• Imperial Chemical Industries는 약 400개의 프로그램에 대한 포트폴리오의 유지보수 비용이 정밀 검토를 하지 않은 프로그램의 유지보수 비용의 10% 수준이라는 것을 발견했다(Gilb and Graham 1993).
• 큰 프로그램에 대한 한 연구는 정밀 검토에 1시간을 투자하면 평균 33시간의 유지보수 작업을 줄일 수 있으며 테스트보다 최대 20배까지 효율적이라는 것을 발견했다(Russell 1991).
• 한 소프트웨어 유지보수 조직에서 코드 검토를 도입하기 전에는 한 줄을 유지보수할 때 변경사항의 55%가 오류였다.
• 같은 사람들로 구성된 팀이 11개의 프로그램을 개발해 모두 제품으로 출시했다.

• 캐퍼스 존스(Capers Jones)는 그가 연구한 모든 소프트웨어 프로젝트가 99% 이상의 결함 제거율을 달성했고 모든 프로젝트가 형식적인 정밀 검토를 사용했다고 보고했다. 또한 결함 제거율이 75% 이하인 프로젝트는 모두 형식적인 정밀 검토를 사용하지 않았다(Jones 2000).

• 이러한 수많은 사례가 소프트웨어에 있는 결함의 수를 줄이는 것이 개발 시간을 줄이는 것이라는 소프트웨어 품질의 일반적인 원칙을 설명하고 있다.
• 다양한 연구들이 협력 기법이 오류를 잡는 데 테스트보다 훨씬 효과적일 뿐만 아니라 테스트와는 다른 종류의 오류를 찾을 수 있음을 보여줬다(Myers 1978; Basili, Selby, and Hutchens 1986). 따라서 테스트가 효과적으로 수행되었을 때조차도 검토나 다른 종류의 협력 작업이 포괄적인 품질 보증 프로그램의 일부로 필요하다.

협력 구현은 협동 문화와 프로그래밍 경험을 제공한다

• 소프트웨어 개발 표준을 작성하고 배포할 수는 있지만, 어느 누구도 표준을 언급하지 않거나 다른 사람들에게 표준을 사용하라고 권하지 않는다면 아무도 그 표준을 따르지 않을 것이다. 코드와 표준, 코드가 표준을 준수해야 하는 이유가 검토에 관한 훌륭한 주제가 될 수 있다.
• 개발자들은 표준을 얼마나 잘 따르는지에 대한 피드백뿐만 아니라 형식 설정, 주석, 변수 이름, 지역 변수와 전역 변수의 사용, 설계 방법, 개발 관행 등 더 주관적인 측면에 대한 피드백이 필요하다. 이처럼 검토는 현재 못지않게 미래의 품질 향상을 도모하는 좋은 기회다.
• 형식적인 정밀 검토를 사용한 어떤 팀은 정밀 검토를 통해서 모든 개발자가 빠르게 최고 개발자 수준에 도달할 수 있었다고 보고했다(Tackett and Van Doren 1999).

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

• 공동 소유권을 적용하면 모든 코드를 개인이 아닌 팀이 소유하고 여러 팀원이 접근하고 수정할 수 있다. 이는 여러 가지 중요한 혜택을 제공한다.
• 여러 사람이 코드를 보고 코드를 다루면 코드의 품질이 좋아진다.
• 여러 사람이 코드에 대해서 잘 알고 있기 때문에 누군가가 프로젝트를 그만두더라도 그 충격이 덜하다.
• 모든 개발자가 동등하게 버그를 수정할 수 있기 때문에 결함 수정 주기가 전체적으로 짧아진다.
• 익스트림 프로그래밍과 같은 방법론은 공식적으로 개발자가 짝을 지어 일을 돌아가면서 하는 방법을 제안한다. 형식적이거나 비공식적인 기술적 검토, 필요한 경우에는 짝 프로그래밍, 오류 수정 작업의 교대를 통해서 시간이 지나면서 커버리지를 달성할 수 있었다.

협력을 구현 전 만큼이나 구현 후에도 적용한다

• 이 책은 구현에 대한 책이라서 상세 설계와 코드에 대한 협력을 중심으로 다룬다.

21.2 짝 프로그래밍

• 짝 프로그래밍을 할 때 한 개발자는 키보드로 코드를 입력하고 다른 개발자는 실수를 감시하고 코드가 정확하게 작성되고 있고 올바른 코드가 작성되고 있는지에 대해서 전략적으로 생각한다. 짝 프로그래밍은 원래 익스트림 프로그래밍(Beck 2000)에 의해서 알려졌지만, 이제는 더 널리 사용되고 있다(Williams and Kessler 2002).

짝 프로그래밍의 성공 요건

• 짝 프로그래밍의 기본 개념은 간단하지만, 그래도 몇 가지 지침을 활용하면 도움이 된다.
• 코드 작성 표준으로 짝 프로그래밍을 지원하라. 짝을 이루고 있는 두 명이 코드 작성 방식에 대해서 주장하느라 시간을 낭비한다면 짝 프로그래밍의 효율이 떨어질 것이다. 5장 “구현 설계”에서 프로그래밍의 “우연적인 특성들”로 언급한 것을 표준화하여 개발자가 “핵심” 업무에 집중할 수 있도록 한다.
• 짝 프로그래밍이 감시가 되지 않도록 하라. 키보드가 없는 사람이 프로그래밍에 적극적으로 참여해야 한다. 그 사람은 코드를 분석하고 다음에 어떤 코드가 작성될 것인지 미리 생각하고 설계를 평가하고 코드를 테스트하기 위한 방법을 계획해야 한다.
• 짝 프로그래밍을 강요하지 마라. 매우 복잡한 코드를 작성할 때 짝 프로그래밍을 사용했던 한 그룹은 15분 동안 칠판에서 상세 설계를 한 다음 혼자서 프로그램을 작성하는 것이 더 적절하다는 것을 발견했다(Manzo 2002). 짝 프로그래밍을 시도했던 대부분의 조직은 결국 전체가 아닌 부분적으로 짝 프로그래밍을 사용하고 있다(Boehm and Turner 2004).
• 정기적으로 짝과 작업을 교대하라. 다른 협력 개발 훈련처럼 짝 프로그래밍에서도 서로 다른 개발자가 시스템의 서로 다른 부분을 학습함으로써 득을 본다.
• 짝이 서로의 속도에 맞출 수 있도록 하라. 한 파트너가 너무 빨리 진행하면 다른 파트너가 얻을 수 있는 이득이 제한된다. 속도가 빠른 파트너가 천천히 진행하거나 짝을 분리해서 다른 파트너와 짝을 재구성해야 한다.
• 파트너 모두 모니터를 볼 수 있게 하라. 모니터를 볼 수 있으나 지나치게 작은 글꼴을 사용하는 것 같이 겉으로 보기엔 별것 아닌 것도 문제가 될 수 있다.
• 사이가 좋지 않은 사람을 짝으로 만들지 말라. 때때로 성격 차이로 인해 효과적인 짝이 형성되지 않는 경우가 있다. 서로 사이가 안 좋은 사람들을 짝으로 만드는 것은 아무런 의미가 없으니 성격이 맞는지 잘 살펴보아야 한다(Beck 2000, Reifer 2002).
• 초보자끼리 짝을 짓지 않는다. 짝 프로그래밍은 파트너 중 적어도 한 명이 이전에 짝을 지어본 경험이 있을 때 가장 잘 진행된다(Larman 2004).
• 팀의 리더를 선정하라. 팀 전체가 짝 프로그래밍으로 모든 일을 하고 싶어 한다면 작업을 배정하고 결과를 책임지고 프로젝트의 외부에 있는 사람들과 의사소통하는 역할을 수행할 사람을 선정해야 할 것이다.

짝 프로그래밍의 혜택

• 짝 프로그래밍은 다양한 혜택을 제공한다.
• 혼자서 개발할 때보다 압박을 더 잘 견딘다. 짝은 코드를 빠르게 엉망으로 작성하게 만드는 압력이 있을 때도 코드의 품질을 높게 유지할 수 있도록 서로를 격려한다.
• 코드의 품질을 향상시킨다. 코드의 가독성과 이해 용이성이 팀에서 가장 훌륭한 개발자 수준으로 올라가는 경향이 있다.
• 일정을 단축시킨다. 짝 프로그래밍은 더 빠르면서도 오류가 적은 코드를 작성하게 해주는 경향이 있다. 프로젝트 팀이 프로젝트의 마지막에 결함을 수정하는 데 더 적은 시간을 보낸다.
• 협력 문화 보급과 신참 개발자의 교육, 공동 소유 장려와 같은 협력 구현의 다른 모든 혜택을 제공한다.

체크리스트: 효과적인 짝 프로그래밍

• 짝 개발자가 철학적인 코드 작성 방식에 대한 토론보다 프로그래밍에 집중할 수 있도록 코드 작성 표준이 있는가?
• 파트너가 모두 능동적으로 참여하고 있는가?
• 짝 프로그래밍의 모든 것을 적용하는 대신 실제로 도움이 되는 부분만 선택하였는가?
• 짝과 작업을 정기적으로 교대하고 있는가?
• 짝이 작업 속도나 성격 면에서 잘 맞는가?
• 경영진이나 프로젝트의 외부에 있는 사람과 의사소통할 팀 리더가 있는가?

21.3 공식적인 정밀 검토

• 정밀 검토는 결함을 발견하는 데 매우 효과적이며 테스트에 비해서 상대적으로 경제적인 것으로 알려진 검토의 한 종류다. 비록 모든 검토에 설계와 코드 읽기가 수반되지만, 정밀 검토는 다음과 같은 여러 가지 핵심적인 방법에서 평범한 검토와 차별화된다.
• 체크리스트는 과거에 문제가 있었던 영역에 정밀 검토자가 주의를 기울이게 해준다.
• 정밀 검토는 결함의 수치가 아니라 발견에 중점을 둔다.
• 정밀 검토자는 미리 정밀 검토 회의를 준비하고 그들이 발견한 문제점 목록을 준비하여 참석한다.
• 모든 참석자에게 명확한 역할을 할당한다.
• 정밀 검토의 중재자는 정밀 검토 중인 제품의 작성자가 아니다.
• 중재자는 정밀 검토의 중개를 위한 특정한 훈련을 받은 사람이다.
• 정밀 검토 미팅은 모든 참석자가 적합하게 준비한 경우에만 개최한다.
• 데이터를 정밀 검토마다 모으고 다음 번 정밀 검토에 제공해 결과를 향상시킨다.
• 프로젝트 일정이나 경영자 관련 사항을 정밀 검토하지 않는다면 일반 경영자는 정밀 검토 미팅에 참석하지 않는다. 기술 전문가는 참석할 수 있다.

정밀 검토로부터 어떤 결과를 기대할 수 있는가?

• 각 정밀 검토는 보통 60% 정도의 결함을 잡는다. 이러한 결과는 Harris BCSD, National Software Quality Experiment, 소프트웨어공학연구소, 휴렛팩커드 등을 비롯한 여러 조직에서 수없이 입증되었다(Shull et al 2002).
• 설계 정밀 검토와 코드 정밀 검토를 조합하면 대개 제품 결함의 70%에서 85% 이상을 제거한다(Jones 1996).
• 정밀 검토를 진행 상태를 평가하는 데도 사용할 수 있지만, 이는 기술적인 과정을 평가하는 것이다. 이 두 질문에 대한 대답은 공식적인 정밀 검토의 부산물이다.

정밀 검토에서의 역할

• 정밀 검토의 한 가지 주요한 특징은 참여한 사람마다 뚜렷한 역할을 맡는다는 점이다. 다음은 그 역할이다.
• 중재자 중재자는 정밀 검토의 진행 속도를 생산적일 만큼 빠르고 가장 많은 오류를 찾을 수 있는 수준으로 느리게 유지하는 역할을 담당한다.
• 작성자 설계나 코드를 작성한 사람은 정밀 검토에서는 비교적 역할이 적다. 정밀 검토의 목표 중 일부는 설계나 코드가 분명한지 확인하는 것이다.
• 검토자 검토자는 설계나 코드에 대해 직접적 관심이 있지만 작성자는 아닌 사람이다. 테스터나 고수준 설계자도 포함될 것이다. 검토자의 역할은 결함을 찾는 것이다.
• 서기 서기는 발견된 오류와 정밀 검토 회의 중에 있었던 조치 항목을 기록한다. 작성자나 중재자는 서기가 될 수 없다.
• 관리자 정밀 검토에 관리자가 참여하는 것은 일반적으로 좋은 생각이 아니다. 사람들은 검토를 하는 대신 평가를 받고 있다고 느낀다.
• 마찬가지로 어떠한 환경에서도 정밀 검토의 결과가 성능을 평가하기 위한 수단으로 사용되어서는 안 된다. 황금알을 낳는 거위를 죽여서는 안 된다.
• 전체적으로 정밀 검토에는 적어도 세 명 이상의 참여자가 있어야 한다. 이보다 더 많으면 관리하기가 어렵기 때문이다. 경험을 토대로 그에 맞게 방법을 조절하라.

정밀 검토의 일반적인 절차

• 정밀 검토는 여러 단계로 구성된다.
• 계획 작성자는 설계나 코드를 중재자에게 전달한다. 내용물은 회의 진행 시 오류를 빠르게 찾을 수 있도록 줄 번호와 함께 출력해야 한다.
• 개요 검토자가 프로젝트에 익숙하지 않을 때는 작성자가 설계나 코드가 작성된 기술적 환경을 1시간 정도 설명할 수 있다. 설계나 코드는 그 자체만으로 설명이 되어야지 개요가 그것을 설명해서는 안 된다.
• 준비 각 검토자는 설계나 코드에 오류가 있는지를 정밀하게 조사하기 위하여 혼자 일한다. 검토자는 검토 대상을 상기하고 파악하기 위해서 체크리스트를 사용한다.
• 고급 언어로 작성된 응용 프로그램을 검토하는 경우, 검토자는 시간당 500줄 정도의 코드를 준비할 수 있다. 가장 효과적인 검토 비율은 매우 다양하기 때문에 환경에 따른 가장 효과적인 비율을 결정하기 위해서 자신이 일하는 조직에서의 준비비율을 기록한다.
• 어떤 조직에서는 검토자마다 특정한 관점이 주어졌을 때 정밀 검토 결과가 더 효과적이라는 사실을 발견했다. 관점 기반의 검토에 대한 연구가 포괄적으로 진행되지는 않았지만, 관점 기반의 검토가 일반적인 검토보다 더 많은 오류를 발견할 수도 있음을 제시한다.
• 정밀 검토 준비의 또 다른 형태는 각 검토자에게 하나 이상의 시나리오를 정밀 검토하도록 하는 것이다. 검토자가 자료를 앞에서 뒤로, 뒤에서 앞으로, 또는 안에서부터 밖으로 읽게 할 수도 있다.
• 정밀 검토 회의 중재자는 설계를 설명하거나 코드를 읽기 위해서 작성자 이외의 누군가를 선택한다(Wiegers 2003). 논의에 집중하지 않는다면 중재자가 참석자의 주의를 끈 다음 논의를 계속 진행한다.
• 설계나 코드를 검토하는 속도가 너무 빨라서도 너무 느려서도 안 된다. 우선 시간당 평균 150에서 200줄 정도의 소스 명령문을 기준을 삼는 것이 좋다(Wiegers 2002).
• 회의 중에 해결책을 논의하지 않는다. 그들은 누군가가 결함이라고 생각할 만큼 혼란스럽다면 설계나 코드, 문서가 명료하게 수정되어야 할 필요가 있다고 가정한다.
• 일반적으로 회의는 2시간 넘게 지속되지 않아야 한다. 2시간이 되었을 때 모든 사람을 내보내야 한다는 의미는 아니지만, IBM과 다른 회사에서의 경험으로 볼 때 검토자는 2시간 정도가 지나면 더 이상 집중을 할 수가 없다. 같은 이유로 같은 날에 한 번 이상 정밀 검토를 하는 것은 현명하지 않다.
• 정밀 검토 보고 정밀 검토 회의를 진행한 당일에 중재자는 결함의 유형과 정도를 포함한 결함 목록을 정리한 정밀 검토 보고서를 작성해야 한다.
• 재작업 중재자는 결함을 수정하기 위해서 누군가(일반적으로 작성자)에게 할당한다. 결함을 할당받은 사람은 목록에 있는 결함을 해결한다.
• 후속 조치 중재자는 정밀 검토가 진행되는 중에 할당된 모든 수정 작업을 지켜볼 책임이 있다. 발견된 오류와 정도에 따라서 검토자에게 전체 제품을 다시 정밀 검토하게 하거나 수정된 부분만 다시 정밀 검토하게 하거나 작성자에게 별도의 후속 조치 없이 오류를 완료하게 하는 조치를 취해야 할 것이다.
• 추가 회의 정밀 검토 진행 중에 참여자가 제기된 문제에 대한 해결책을 논의하는 것을 허용하지 않아도 누군가는 그렇게 하고 싶어 할 것이다. 공식적인 정밀 검토가 끝나고 난 후 관심 있는 사람들이 해결책을 논의할 수 있도록 비공식적인 추가 회의를 열 수 있다.

정밀 검토의 정밀 조정

• “책을 통해” 정밀 검토를 수행하는 방법을 익혔다면 그것을 향상시킬 다양한 방법을 찾을 수 있다. 그렇다고 마구잡이 식으로 변경해서는 안 된다.
• 회사들은 정밀 검토 단계를 없애거나 조합할 때 비용이 더 많이 든다는 것을 발견했다(Fagan 1986).
• 정밀 검토를 할 때 특정한 종류의 오류가 다른 종류보다 더 빈번하게 발생한다는 것을 알게 될 것이다. 더 길어지면 정밀 검토에 필요한 수준에서 사용하기가 어렵다.

정밀 검토에서의 자존심

• 정밀 검토 자체의 핵심은 설계나 코드에 있는 결함을 발견하는 것이다. 다른 대안을 찾거나 누가 옳고 누가 그른지에 대해서 논쟁하는 것이 아니다. 설계나 코드를 작성한 사람을 비판해서는 안 된다.
• 설계나 코드가 비평의 대상이 되고 있고 자신이 개발한 코드나 설계에 작성자가 애착을 갖기 때문에 작성자는 당연히 코드에 대해 압박감을 느끼게 된다.
• 검토자는 결함에 대해서 무엇을 할지에 대한 최종 결정권이 작성자에게 있음을 기억해야 한다. 결함을 찾는 것을 즐기는 것까지는 좋지만(그리고 단순한 검토를 넘어서 해결책을 제안하는 것까지), 각 검토자는 오류를 어떻게 해결할 것인지에 대한 작성자의 최종 결정권을 존중해야 한다.

정밀 검토와 《Code Complete》

• 《Code Complete》 2판에 대해 개인적으로 정밀 검토를 한 경험이 있다. 이 책은 10년 이상 출판되었고 그동안 독자들이 200개 정도의 오류를 보내주었다.
• 그렇게 많은 검토 작업을 거쳤으니 이 책에는 오류가 많지 않을 것이라고 생각할지도 모른다. 서너 명으로 이루어진 팀이 이 책에서 설명한 지침에 따라 준비했다.

• 공식적인 정밀 검토가 얼마나 중요한지 《Code Complete》 2판을 작성하면서 확실하게 알게 되었다.

• 정밀 검토 체크리스트를 사용하면 무언가에 초점을 맞춰서 집중적으로 진행할 수 있다. 규격화된 체크리스트와 규칙 덕분에 정밀 검토 진행 과정이 체계화된다.
• 소프트웨어 공학 연구소는 조직의 소프트웨어 개발 프로세스의 효율성을 측정하는 역량 성숙도 모델(Capability Maturity Model, CMM)을 정의했다(SEI 1995). 정밀 검토 프로세스는 이 모델의 최상위 수준이 어떤지 보여준다.

체크리스트: 효과적인 정밀 검토

• 검토자가 과거에 문제가 있었던 부분에 집중하게 하는 체크리스트가 있는가?
• 정밀 검토를 수정보다는 결함의 발견에 초점을 맞추었는가?
• 검토자가 준비 작업에 초점을 맞출 수 있도록 예상 목록이나 시나리오를 정해주는 것을 고려했는가?
• 정밀 검토 회의가 있기 전에 검토자에게 충분히 준비할 시간을 줬는가? 그리고 모든 검토자가 준비되었는가?
• 각 참석자가 명확한 역할(중재자, 검토자, 서기 등)을 갖는가?
• 회의가 생산적인가?
• 회의 시간이 2시간으로 제한되어 있는가?
• 정밀 검토의 모든 참석자가 정밀 검토를 수행하기 위해 특정한 교육을 받았는가? 그리고 중재자는 중재 역할을 하기 위한 특별 교육을 받았는가?
• 조직에서 사용하는 체크리스트를 조절하기 위해서 오류의 타입에 대한 데이터가 정밀 검토에서 수집되었는가?
• 다음 번 정밀 검토를 효율적으로 진행할 수 있도록 미팅에 대한 데이터를 수집했는가?
• 중재자가 직접 또는 다음번 정밀 검토를 통해서 정밀 검토에서 할당된 활동 항목에 대한 후속 조치가 이루어졌는가?
• 관리자가 정밀 검토에 참여해서는 안 되는 이유를 이해하고 있는가?
• 정확하게 수정되었는지 검증하기 위한 후속 계획이 있는가?

21.4 여러 가지 협력 개발 방법

• 다른 종류의 협력 작업은 정밀 검토나 짝 프로그래밍처럼 많이 사용되지 않아서 여기서는 깊이 있게 다루지 않았다. 이 절에서 다루고 있는 협력 작업은 워크스루(walk-throughs), 코드 읽기, 데모(dog-and-pony shows)가 있다.

워크스루

• 워크스루는 인기 있는 검토 방법이다. 이 용어는 느슨하게 정의되어 있어 그 인기의 일부는 사실 사람들이 어떤 종류의 검토든 “워크스루”라고 부를 수 있다는 사실 덕분이다.
• 용어가 애매하게 정의되어 있기 때문에 워크스루가 정확히 무엇이라고 말하기는 어렵다. 어떤 의미에서 “두세 명이 모여 있는 곳”에는 워크스루가 있다고 말할 수 있다.
• 워크스루는 일반적으로 검토 중인 코드나 설계의 작성자에 의해서 진행되고 조절된다.
• 워크스루는 기술적인 문제에 초점을 맞춘다. 즉, 워크스루는 업무 회의다.
• 모든 참석자는 설계나 코드를 읽고 오류를 찾음으로써 워크스루를 준비한다.
• 워크스루는 수석 개발자가 신입 개발자에게 자신의 경험과 협력 문화를 전달할 수 있는 기회다. 또한 신입 개발자에게는 새로운 방법론을 제시하고 진부하고 더 이상 사용할 수 없는 가정에 이의를 제기할 수 있는 기회이기도 하다.
• 워크스루는 일반적으로 30분에서 60분 동안 진행된다.
• 오류에 대한 수정이 아니라 발견을 중시한다.
• 경영진은 참여하지 않는다.

• 워크스루 개념은 유연하며 그것을 사용하는 조직의 요구에 맞게 수정될 수 있다.

• 워크스루로부터 어떤 결과를 기대할 수 있는가?
• 공식적인 절차에 따라 현명하게 진행한다면 워크스루는 정밀 검토와 유사한 결과를 가져올 수 있다. 하지만 일반적으로 워크스루는 정밀 검토보다 효과가 많이 떨어진다고 알려져 있다(Jones 1996).
• 제대로 진행하지 않으면 워크스루는 득보다 실이 많을 수 있다. 가장 낮은 효율인 20%는 큰 도움이 되지 않으며, 보잉 컴퓨터 서비스에서는 동료가 코드를 검토하면 “지나치게 많은 비용”이 든다는 것을 발견했다.
• 지난 10년 동안 우리 회사의 컨설팅 사업을 보면서 워크스루에 대해 훨씬 더 비판적인 의견을 갖게 되었다.
• 정밀 검토는 오류를 제거하는 데 워크스루보다 효과적인 것처럼 보인다. 그렇다면 누가 워크스루를 사용하는 걸까?
• 대규모의 검토 그룹을 갖고 있다면 검토 항목에 대해서 다양한 관점을 가질 수 있기 때문에 워크스루가 좋은 방법이다. 워크스루에 참여한 모든 사람이 해결책이 옳다고 확신할 수 있다면 아마도 큰 문제는 없을 것이다.
• 다른 조직에 있는 검토자가 참여하는 경우에도 워크스루가 좋을 수 있다. 그들이 기여하기를 원한다면 워크스루가 최상의 선택일 것이다.
• 정밀 검토는 워크스루보다 좀 더 집중적이며 일반적으로 더 많은 것을 돌려준다. 결과적으로 조직을 위한 검토 표준을 선택하고 있다면 정밀 검토를 하지 않을 타당한 이유가 없을 때는 정밀 검토를 가장 먼저 선택하는 것이 좋다.

코드 읽기

• 코드 읽기는 정밀 검토와 워크스루의 대안이다. 코드 읽기에서는 소스코드를 읽고 오류를 찾는다. 또한 설계나 방식, 가독성, 유지보수 편의성, 효율성과 같이 코드의 질적인 측면에 대해서 의견을 제시한다.
• NASA의 소프트웨어공학연구소의 연구에서 코드 읽기가 시간당 약 3.3개의 결함을 찾는다는 것을 발견했다.
• 워크스루의 기본 개념처럼 코드 읽기의 개념도 느슨하게 정의되어 있다. 다음은 코드 읽기를 진행하는 방법이다.
• 회의를 준비할 때 코드 작성자는 소스코드를 검토자에게 전달한다. 코드는 1,000줄에서 1만 줄 사이로, 보통 4,000줄이다.
• 두 명 이상의 사람이 코드를 읽는다. 검토자끼리 경쟁을 유발하기 위해서 최소 두 명이 필요하다. 두 명 이상의 사람을 쓴다면 나머지 사람들이 얼마나 기여했는지 알 수 있도록 모든 사람의 기여도를 측정한다.
• 검토자는 코드를 개별적으로 읽는다. 하루에 약 1,000줄 정도 평가한다.
• 검토자가 코드 읽기를 마쳤을 때 작성자에 의해 코드 읽기 회의가 주최된다. 회의가 반드시 필요한 것도 아니다.
• 코드의 작성자는 검토자가 규명한 문제를 수정한다.
• 코드 읽기 쪽과 정밀 검토와 워크스루 쪽의 차이점은 코드 읽기가 회의보다는 개별적인 검토에 중점을 둔다는 점이다.
• AT&T에서 진행된 13번의 검토에 대한 연구에서 검토 회의 자체의 중요성이 지나치게 높다는 것이 발견됐다. 결함의 90%는 검토 회의를 준비하면서 발견되었고 10%만이 검토를 진행하는 중에 발견됐다(Votta 1991, Glass 1999).

데모

• 데모(Dog-and-pony show)는 소프트웨어 제품을 고객에게 보여주는 검토다. 데모의 목적이 고객에게 프로젝트가 잘 진행되고 있다는 것을 보여주기 위한 것이라서 기술적인 검토라기보다는 경영적인 검토다.
• 제품의 기술적인 품질을 개선하기 위해서 데모에 의존하지 않는다. 기술적인 품질 개선을 위해서는 정밀 검토나 워크스루, 코드 읽기에 의존한다.

협력 구현 기법 비교

• 이렇게 다양한 협력 구현 기법이 어떻게 다른 것일까? 표 21-1은 각 기법의 주요 특징을 요약한 것이다.

• 짝 프로그래밍은 형식적인 정밀 검토처럼 그 효율성을 증명하는 데이터가 그렇게 많지 않다. 하지만 초기 데이터는 이 기법이 대충 정밀 검토와 비슷한 결과를 가져온다는 것을 보여주며 우연한 관찰에 따른 보고서들도 긍정적이다.
• 짝 프로그래밍과 형식적인 정밀 검토가 품질, 비용, 일정에 있어서 유사한 결과를 만든다면 어느 것을 선택하는지는 기술적인 본질보다는 개인적인 성향에 따라서 좌우된다.

참고 자료

• 다음은 협력 구현에 관한 자료다.

짝 프로그래밍

• 로리 윌리엄스(Laurie Williams)와 로버트 케슬러(Robert Kessler) 《Pair Programming Illuminated》(Addison-Wesley, 2002). 이 책은 짝 프로그래밍의 모든 것을 설명한다.
• 켄트 벡 《익스트림 프로그래밍》(인사이트, 2006) 이 책은 짝 프로그래밍에 대해서 간략하게 소개하고 코드 작성 표준, 빈번한 통합, 회귀 테스트와 같은 다른 기법과 함께 짝 프로그래밍이 어떻게 사용될 수 있는지를 보여준다.
• 도널드 라이퍼(Donald Reifer) “How to Get the Most Out of Extreme Programming/Agile Methods,” 185-196쪽 (XP/애자일 유니버스, 스프링거, 2002) 이 논문은 익스트림 프로그래밍과 애자일 방법론을 사용한 실무 경험을 요약해서 설명하고 성공적인 짝 프로그래밍을 위한 핵심적인 내용을 소개한다.

정밀 검토

• 칼 위거스 《Peer Reviews in Software: A Practical Guide》(Addison-Wesley, 2002).
• 톰 길브와 도로시 그레이엄 《Software Inspection》(Addison-Wesley, 1993).
• 마이클 페이건 “Design and Code Inspections to Reduce Errors in Program Development,” 182-211쪽 (IBM 시스템 저널, 1976)
• 마이클 페이건 “Advances in Software Inspections”, 744-751쪽(IEEE Transactions on Software Engineering, 1986년 7월호). 이 두 글은 정밀 검토를 만든 사람이 작성한 것이다.

관련 표준

• IEEE Std 1028-1997, Standard for Software Reviews
• IEEE Std 730-2002, Standard for Software Quality Assurance Plans

요점 정리

• 협력 개발 방법은 테스트보다 결함을 발견하는 비율이 높고 좀 더 효율적으로 결함을 찾을 수 있다.
• 협력 개발 방법은 테스트보다 더 많은 종류의 오류를 찾을 수 있으며 이는 소프트웨어의 품질을 보장하기 위해서 검토와 테스트를 모두 사용할 필요가 있음을 의미한다.
• 형식적인 정밀 검토는 체크리스트, 사전 준비, 잘 정의된 역할, 지속적인 프로세스 향상을 사용해 오류 탐지의 효율성을 극대화한다. 정밀 검토는 워크스루보다 더 많은 결함을 찾는다.
• 짝 프로그래밍은 전형적으로 정밀 검토와 거의 비슷한 비용이 들고 유사한 품질의 코드를 생산한다. 짝 프로그래밍은 일정을 줄여야 할 때 특히 유용하다.
• 형식적인 정밀 검토는 코드 작성뿐만 아니라 요구사항, 설계, 테스트 케이스 같은 것에도 사용할 수 있다.
• 워크스루와 코드 읽기는 정밀 검토의 대안이다. 코드 읽기는 개인의 시간을 효과적으로 사용할 수 있다는 장점이 있다.