추가 적립 안내

좋은 리뷰는 무엇인가?
경제적인 소프트웨어 개발을 위한 리뷰 문화 개선 프로젝트!
무엇이든 기초가 튼튼해야 한다. 소프트웨어 역시 마찬가지다. 기초공사, 즉 설계문서가 문제없이 구축되어야 후반 프로세스에서 큰 문제가 발생하지 않는다. 리뷰 연구 전문가인 저자는 탄탄한 설계문서 구축을 위해 자신의 경험을 토대로 확립한 설계 리뷰 노하우를 이 책에 현실감 있게 소개한다.

리뷰 순서와 방법부터 왜 중요한 문제를 놓치는지, 상황에 따라 어떤 리뷰기법을 도입해야 하며, 리더, 리뷰어, 문서 작성자별로 할일은 무엇인지 자세하게 짚어준다. 리뷰할 시간이 없다는 둥 시간을 들이는 만큼 효과가 없다는 둥 불만을 늘어놓지만 말고 이 책의 시나리오를 따라가다 보면, 결코 설계 리뷰가 사소하지 않다는 것을 알게 될 것이다. 이 책이 IT 현장의 한계에 부딪혀 매너리즘에 빠져버린 리뷰 문화를 건설적인 리뷰로 정착시키는 데 든든한 이정표가 되었으면 한다.

1장 실패한 리뷰들, 도대체 무엇을 놓치고 있는가
1.1 왜 사소한 지적이 많은가? 리뷰의 목적부터 다시 생각하자
1.2 시간을 낭비하고 중요한 문제를 놓치는 네 가지 안티패턴
인간관계 끌어들이기
작성자 마인드
두 마리 토끼 잡기
적절치 못한 시간 분배
1.3 계획과 중재가 없는 어수선한 리뷰회의
계획성 없는 끝나지 않는 리뷰(준비 단계)
다툼, 주제 이탈의 방치(진행 단계)
갑작스러운 종료 선언(완료 단계)
1.4 보여주기식 경쟁으로 쓸데없는 지적을 하고 있지 않은가?
보여주기식 경쟁
헐뜯기
의도적인 묵인

2장 본격적인 리뷰 준비와 문제 검출
2.1 리더와 문서 작성자의 리뷰 준비: 시나리오 작성
리더의 준비
문서 작성자의 준비
2.2 리뷰어의 리뷰 준비: 시나리오 순서 정하기
2.3 리뷰의 효과를 높이는 문제 검출법

3장 설계 리뷰의 중심, 리뷰회의
3.1 순조로운 리뷰회의를 위한 준비
리더의 리뷰회의(전반)
리뷰어의 리뷰회의(전반)
문서 작성자의 리뷰회의(전반)
3.2 제 시간에 문제를 검출하는 똑똑한 리뷰회의 진행방법
리더의 리뷰회의(후반)
리뷰어의 리뷰회의(후반)
문서 작성자의 리뷰회의(후반)
3.3 유종의 미, 문제의 수정과 확인
문서의 수정과 확인
문제의 재발 방지
3.4 만능은 없다. 세 가지 리뷰기법을 상황에 따라 적용하자
워크스루: 문서 작성자가 주도하는 가벼운 회의
인스펙션: 규칙에 따라 엄격하게 체크
테크니컬 리뷰: 테크니컬 리더의 주도적인 체크

4장 리뷰 효과 끌어올리기
4.1 리뷰를 개선하는 프로젝트 다시보기
4.2 개발 방법에 따른 리뷰 적용하기
유지보수 개발 1
반복 개발 1
애자일 개발 1
패키지 클라우드 개발
대규모 개발

부록. 리뷰 관점의 축소 효과
A.1 리뷰 관점을 축소함으로써 수정 공수가 줄어드는 효과
검증1 정성적으로 리뷰 관점 줄이기 - 중요한 문제의 검출 건수가 1.4배로
검증2 정량적으로 리뷰 관점 줄이기 - 2.3배의 수정 공수 저감 효과

문서 리뷰는 요구사항을 정리하거나 설계하는 과정에서, 개발하고자 하는 시스템의 잠재적인 문제를 미리 발견하는 데 목적이 있다. 리뷰 단계에서 문제를 발견하면 실제 구현이나 테스트 과정에서 문제를 발견하는 것보다 훨씬 쉽게 문제를 해결할 수 있으며, 이는 곧 비용의 문제로 직결된다. 결국, 문제를 미리 발견하여 비용을 절감하는 것이 리뷰를 시행하는 가장 큰 목적이다.
(/p.6)

그렇다면 어떤 문제를 검출해야 비용 효과로 이어질까? 예를 들어, 어느 워터폴(Waterfall)형 개발 프로젝트의 설계문서 리뷰회의에서 애플리케이션 간 리소스 경합(Race Condition)에 관한 문제를 검출했다고 해보자. 설계문서의 수정과 확인에는 1인시의 공수가 들었다. 만약, 리뷰에서 이 문제를 놓쳐서 통합 테스트에서 발견했다면, 얼마만큼의 수정 공수가 필요하게 될까?
(/ p.8)

문제 지적은 문제 검출만큼 중요하다. 애써 문제를 발견해도 리뷰어의 지적 방법이 올바르지 않다면 문서 작성자가 적절히 수정할 수 없거나 험악한 분위기가 되기 때문이다. 문제 지적 방법은 커뮤니케이션 기술이다. 이를 습득하는 일도 리뷰 효과를 높이는 데 빼놓을 수 없다.
(/ p.11)

여럿의 리뷰어가 순서와 기준 없이 제각각 문서를 검토하는 것은 큰 효과가 없다. 성과물에 문제가 없는가를 눈으로 확인하는 작업은 리뷰의 일부에 지나지 않는다. “이번 프로젝트에서는 어떤 문제를 중점적으로 검출할 것인가?”를 생각하는 것부터 검출한 문제의 수정을 확인하는 데까지가 리뷰이다. 그러한 순서를 밟아 팀으로 공동 작업을 해야 비로소 중요한 문제를 빠짐없이 발견할 수 있다.
(/ p.41)

프로젝트가 완료되었을 때, 프로젝트 다시보기를 진행하는 현장이 늘어나고 있다. 리더와 주요 리뷰어가 리뷰 다시보기도 진행한다. 다시보기의 주요 목적은 향후 유사한 프로젝트를 위해 리뷰 방법을 개선하는 것이다. 체크할 부분과 판단방법 등의 문제 검출방법을 표시한 시나리오를 바탕으로 개선한다. 또한, 문제 발생을 방지하는 것도 목적에 포함된다.
(/ p.126)

애자일 개발에서는 일반적으로 문서 작성보다 동작하는 프로그램의 개발에 주력한다. 그렇다고 반드시 리뷰 대상이 적은 것을 의미하지는 않는다. 원래 문서에 적혀 있는 내용은 소스코드나 동작하는 프로그램, 팀 멤버 간의 의사소통으로 공유된다. 따라서 리뷰의 시나리오를 생각할 때는 문서 외에도 무엇을 확인해야 하는지 검토한다.
(/ p.140)