21장 - 협력 구현

Edited by / 임수형 (sulogc)

어떤 방법을 사용하든 모든 협력 구현 기법은 오류 해결을 목적으로 자신의 작업 내용을 다른 사람에게 보여주는 과정을 형식화하려는 시도다.

21-1 협력 개발 방법 개요

"협력 구현"은 짝 프로그래밍, 형식적인 정밀 검토, 비형식적인 기술 검토, 문서 읽기와 더불어 개발자들이 코드 작성과 제품 개발에 관련된 다른 작업에 대한 책임을 공유하는 데 사용하는 기법을 가리킨다. 

모든 협력 구현 기법은 개발자가 자신의 작업 내 문제점을 못 본다는 점과 다른 사람들은 볼 수 있다는 점, 다른 개발자가 자신의 작업을 봐주는 게 도움이 된다는 개념을 기초로 한다.

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

협력 구현의 일차적인 목적은 소프트웨어의 품질을 향상시키는 것이다. 소프트웨어 테스트는 단독으로 사용되면 효율성에 한계가 있다. 단위, 통합, 소량 베타 테스트는 30~35% 언저리인데 비해, 설계와 코드 정밀 검토의 평균 효율성은 60%에 육박한다.

• 짝 프로그래밍, 정밀 검토 등은 테스트와는 다른 종류의 오류를 찾을 수 있고, 효율적으로 오류를 잡을 수 있다.
• 사람이 하는 검토는 불분명한 오류 메시지, 부적절한 주석, 직접 입력된 변수 값, 정리되어야 하는 코드 패턴의 반복 등을 해결할 수 있다.
• 부수적인 효과로 사람들은 자신의 작업을 누군가가 검토할 것을 알고 있을 때 더 주의 깊게 작업을 살펴본다는 점이다.

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

소프트웨어 개발 표준을 작성하고 배포할 수는 있지만, 어느 누구도 표준을 언급하지 않거나 다른 사람들에게 표준을 사용하라고 권하지 않는다면 그 표준을 따르지 않을 것이다.

개발자들은 표준을 얼마나 잘 따르는지에 대한 피드백과 형식 설정, 주석, 변수 이름, 지역 변수와 전역 변수의 사용, 설계 방법, 개발 관행 등 더 주관적인 측면에 대한 피드백이 필요하다.

검토는 경험이 많고 적은 개발자들이 기술적인 문제에 대해 대화할 수 있는 기회를 마련해준다. 검토는 현재 못지 않게 미래의 품질 향상을 도모하는 좋은 기회다.

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

공동 소유권을 적용하면 모든 코드를 개인이 아닌 팀이 소유하고 여러 팀원이 접근하고 수정할 수 있다. 이는 중요한 혜택을 제공한다.

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

익스트림 프로그래밍과 같은 방법론은 공식적으로 개발자가 짝을 지어 일을 돌아가면서 하는 방법을 제안한다. 형식적이거나 비공식적인 기술 검토, 필요한 경우에는 짝 프로그래밍, 오류 수정 작업의 교대를 통해서 커버리지 달성이 가능하다.

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

이 책은 구현에 대한 책이라 상세 설계와 코드에 대한 협력을 다루지만, 측정, 계획 수립, 요구사항, 아키텍처, 테스트, 유지보수 작업에서 협력 기법이 유용하게 작용한다.

21-2 짝 프로그래밍

짝 프로그래밍은 코드를 입력하는 개발자와 실수를 감시하는 개발자로 구성된다. 원래 익스트림 프로그래밍에 의해서 알려졌지만, 이제는 더 널리 사용되고 있다.

a. 짝 프로그래밍의 성공 요건

• 코드 작성 표준으로 짝 프로그래밍을 지원하라. 논쟁에 의한 시간 낭비를 제거하기 위해 구현 설계 단계에서 작성 방식을 표준화하여 핵심에 집중하도록 한다.
• 짝 프로그래밍이 감시가 되지 않도록 하라. 키보드 없는 사람이 적극적으로 참여해야 한다. 미리 생각하고 설계를 평가하고 테스트 방법을 계획한다.
• 짝 프로그래밍을 강요하지 마라. 매우 복잡한 코드를 작성할 때 혼자가 더 적절할 수 있다.
• 정기적으로 짝과 작업을 교대하라.
• 짝이 서로의 속도에 맞출 수 있도록 하라. 한 파트너가 너무 빨리 진행하면 다른 파트너가 얻을 수 있는 이득이 제한된다.
• 파트너 모두 모니터를 볼 수 있게 하라.
• 사리아 좋지 않은 사람을 짝으로 만들지 말라.
• 초보자끼리 짝을 짓지 않는다.
• 팀의 리더를 선정하라.

b. 짝 프로그래밍의 혜택

• 혼자 대발할 때보다 압박을 더 잘 견딘다.
• 코드의 품질을 향상시킨다.
• 일정을 단축시킨다.
• 협력 문화 보급 및 신참 개발자의 교육, 공동 소유 장려와 같은 협력 구현의 혜택을 제공한다.

21-3 형식적인 정밀 검토

정밀 검토는 결함을 발견하는 데 매우 효과적이며 테스트에 비해 상대적으로 경제적인 검토의 한 종류이다. 다음에 의해 평범한 검토와 차별화 된다.

정밀 검토는 발견에 중점을 두고, 훈련받은 중재자, 준비된 참석자가 정밀 검토 미팅을 통해 결과를 향상시킨다.

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

각 정밀 검토는 보통 60% 정도의 결함을 잡고, 설계 정밀 검토와 코드 정밀 검토를 조합하면 대개 제품 결함의 70~85% 이상을 제거한다. 더불어, 오류가 발생하기 쉬운 클래스를 초기에 규명하고, 설계자와 작성자가 정밀 검토에 참여하면 생산성이 20% 정도 높아진다. 예산의 10~15% 정도의 비용을 차지하지만 전체 프로젝트 비용을 줄일 수 있다.

b. 정밀 검토에서의 역할

정밀 검토에 참여한 사람은 뚜렷한 역할을 맡는다.

중재자

중재자는 정밀 검토의 진행 속도를 생산적임과 동시에 많은 오류를 발견하도록 속도를 제어해야한다. 검토될 설계나 코드의 분배, 정밀 검토 항목의 분배, 회의실 준비, 정밀 검토 결과 보고 등을 관리한다.

작성자

설계나 코드가 분명하지 않으면 바로잡기 위한 일이 할당된다. 혹은 오류 처럼 보이는 것이 실제로 타당한 이유에 대해 설명해야 한다.

검토자

검토자의 역할은 결함을 찾는 것이다. 보통 준비 단계에서 결함을 발견하고 정밀 검토 회의에서 설계나 코드를 논의할 때 훨씬 많은 결함을 발견한다.

정밀 검토는 순수한 기술적 검토로 성능을 평가하기 위한 수단으로 사용되어서는 안된다.

c. 정밀 검토의 일반적인 절차

계획

작성자는 설계나 코드를 중재자에게 전달한다. 중재자는 누가 검토할지와, 언제, 어디서 정밀 검토 회의를 할 지 결정한다. 후에 정밀 검토의 대상이 되는 체크리스트를 분배한다.

개요

설계나 코드가 작성된 기술적 환경에 대한 설명을 한다.

준비

각 검토자는 설계나 코드에 오류가 있는지를 정밀하게 조사하기 위해 혼자 일한다. 검토자는 체크리스트를 사용한다. 관점 기반의 검토를 하거나 시나리오를 제시하여 특정 설계 항목을 만족하는 지 확인하는 방법 등이 효율적이다.

정밀 검토 회의

중재자가 선택한 작성자 이외의 사람이 코드의 논리 구조를 설명한다. 시간 당 코드량은 준비 정도나 기술 수준에 따라 다르다. 150~200 줄 정도가 권장된다. 회의 중에 해결책을 논의하지 않고, 결함을 식별하는 데 초점을 두어야 한다.

정밀 검토 보고

중재자는 회의를 통해 도출된 결함의 유형과 정도를 목록으로 정리하여 정밀 검토 보고서를 작성한다.

재작업

중재자는 결함 수정을 위해 작성자에게 할당한다.

후속 조치

중재자는 할당된 수정 작업들을 지켜볼 책임이 있다. 검토자에게 수정된 결함을 검토하게 하거나 오류를 완료하게 하는 조치를 취해야 한다.

추가 회의

정밀 검토 중 제기된 문제에 대한 해결책을 논의하는 것을 허용하지 않아도 누군가는 그렇게 하고 싶어 할 것이다. 비공식적인 추가 회의를 열 수 있도록 한다.

d. 정밀 검토에서의 자존심

정밀 검토 자체의 핵심은 설계나 코드에 있는 결함을 발견하는 것이다. 다른 대안을 찾거나 누가 옳고 누가 그른지에 대해 논쟁해서는 안되며, 설계나 코드를 작성한 사람을 비판해서는 안 된다. 작성자에게 프로그램 개선에 대한 확신과 참여자에게는 무언가를 배울 수 있는 경험이 되는 긍정적인 효과를 불러와야한다.

설계나 코드가 비평의 대상이 되고 있고 자신이 개발한 코드나 설계에 작성자가 애착을 갖기 때문에 작성자는 당연히 코드에 대해 압박감을 느끼게 된다. 
작성자는 실제로는 결함이 아닌 결함과 논란의 여지가 있는 결함에 대한 비평을 들을 거라고 예상할 것이다. 그렇기는 해도 작성자는 언급된 모든 결함을 인정하고 계속해서 진행해야 한다.
비평을 인정한다고 해서 작성자가 비평의 내용에 동의한다는 것을 의미하지는 않는다. 작성자는 검토 중에 자신이 한 작어에 대해서 방어하려고 해서는 안 된다. 
검토가 끝나고 나서 작성자는 각 결점에 대해서 생각하고 그것이 타당한지를 결정할 수 있다. 

검토자는 결함에 대해 무엇을 할지에 대한 최종 결정권이 작성자에게 있음을 알고, 검토자는 작성자의 최종 결정권을 존중해야 한다.

21-4 여러가지 협력 개발 방법

짝 프로그래밍, 정밀 검토 이외의 협력 작업으로 워크스루, 코드 읽기, 데모 등이 있으나 많이 사용되지 않아서 깊게 다루지 않았다.

a. 워크 스루

느슨하게 정의되에 있지만 분명한 점은 두 명 이상이 코드에 대해서 논의하는 데 참여한다는 것이다. 즉석 자유 토론, 부서 단위 프레젠테이션 등 형태는 다양하며 현명하게 진행되지 않는다면 효과가 많이 떨어질 수 있다.

b. 코드 읽기

코드 읽기는 소스코드를 읽고 오류를 찾거나 설계나 방식, 가독성, 유지보수 편의성, 효율성과 같이 코드의 질적인 측면에 대해서 의견을 제시한다. 워크 스루보다는 개별적인 검토 활동이고 호의로 보내는 시간이 줄어든다.

c. 데모

데모는 소프트웨어 제품을 고객에게 보여주는 검토다. 데모의 목적이 고객에게 프로젝트가 잘 진행되고 있다는 것을 보여주기 위한 것이라서 기술적인 검토라기보다는 경영적인 검토다.

d. 협력 구현 기법 비교