Upload
beom-kyun-choi
View
2.641
Download
3
Embed Size (px)
DESCRIPTION
리뷰의 기술 책 내용을 소개합니다.
Citation preview
‘리뷰의 기술’ 책 신림프로그래머, 최범균, 2014-08-12
리뷰 할 줄 아니?
● 리뷰? o 꽤 많은 개발자가 리뷰를 하지 않는다! o 리뷰는 귀찮다! o 리뷰를 혼나는 걸로 생각한다! o 그 외 …
● 하지만, 리뷰는 반드시 필요한 존재 o 좋은 리뷰 한 번이 뒤에 벌어질 대형 참사를 막음
● 근데, 리뷰하는 방법을 잘 몰라요...
그래서 읽어볼 만한 책, 리뷰의 기술
리뷰를 실패하게 만드는 것들 (일부)
● 헐뜯기/잘난 척 o “니가 저번에 날 씹었겠다...”, “이런 것도 몰라?”
● 샛길로 새기 o “우리 땐 몇일 밤 새가며 하곤 했는데…”
● 계획없는 리뷰, 사소한 지적만 하기 o “아, 그건 템플릿 패턴으로, 그게 뭐냐면…” o “여기 오타, 저기 오타, 지금 보니까, 여기도 있네요.”
● 봐주기 o “A가 만든거야, 잘 봐줘.”, “대충하고 빨리 끝내자”
● 그 외 o 작성자 마인드, 두 마리 토끼, 방어적 태도
리뷰의 목적
● 수정 공수 줄이기!! o 잠재적인 문제를 미리 발견해서 뒤에 벌어질 수정
비용을 절감하는 것이 리뷰를 실행하는 가장 큰 목적
● 비용 효과가 높은 문제를 지적하는 것이 중요
● 리뷰 == 인적 비용 발생 o 이 비용을 지출한 것 이상의 결과를 얻을 수 있도록
리뷰는 효과적이어야 함
리뷰를 잘 하려면
● 계획적이어야 함 o 리뷰에도 올바른 순서가 있음 o 기본이 되는 사고 방식과 표준 순서를 익혀야 함
● 리뷰 참가자의 역할에 맞는 활동 필요 o 리더, 리뷰어, 작성자의 세 가지 역할
● 리뷰의 목적을 분명히 해야 함
리뷰의 4단계
● 리뷰의 4단계 o 준비 → 문제 검출 → 문제 지적(리뷰회의) → 수정
및 확인 o 리뷰의 시작과 끝
§ 어떤 문제를 검출할지 생각하는 것 부터 § 문제의 수정을 확인하는 데까지
● 각 단계 별로 리더, 리뷰어, 작성자는 역할에 맞는 활동 수행
리뷰 준비 리더 리뷰어 작성자
1. 검출할 문제 유형 선전 - 처리량 감소, 복잡한 UX 등 몇 가지 문제 유형을 5~10개 정도로 도출 2. 지침이 되는 시나리오 작성 - 문제 유형별로 어디를 어떻게 검출할지 구체적 기술 3. 간단한 리뷰 실시 - 문서 포맷 맞추는 등의 목적으로 간단한 리뷰를 초기 실시 4. 리뷰어 선정과 시나리오 배분 - 시나리오별로 리뷰어 선정 5. 문서 배포와 고지 - 문서 작성자로부터 문서를 받아 리뷰어에 배포, 수집 일정 공지
1. 시나리오 만들기 - 필요에 따라 리뷰어가 추가 2. 시나리오 순서 결정 - 수정 공수나 리스크가 큰 시나리오와 운선순위를 기준으로 리뷰 순서 결정 3. 시나리오 확인과 참고 문서 준비 - ERD, 기획서 등 필요한 문서를 미리 준비 4. 검출 방법과 체크 범위 검토 - 시나리오별로 체크할 범위를 압축해서 집중력 유지 5. 문제 검출 일정 잡기 - 가능한 빨리 시작해서 시간이 부족하지 않도록 함
- 제대로 된 문서를 만들기 위해 노력 - 의문이 생기면 간단 리뷰 등으로 바로 확인 - 리뷰어 배려: 문서 구조를 통일하고, 오탈자 등을 최대한 교정
리뷰어, 문제 검출
● 시나리오 순서 결정 o 누락, 애매함, 오류 순서로 진행
§ 누락: 어떤 내용이 쓰여 있어야 할지 미리 생각하고 검토 § 애매함: 여러 의미로 해석 가능하거나 부족한 부분 § 오류: 여러 번 읽을수록 발견하기 쉬우므로 마지막 진행
● 검출 방법 o 누락: 사전에 들어가야 할 내용 미리 생각 o 애매함: 문서를 읽을 대상을 고려해 검토
§ 예, 이것, 저것들, 처리하다 o 오류
§ 문서 내의 부정합: 자료 타입, 길이, 범위, 시간대 등 § 문서 외적이 요소와의 부정합: 개발 표준, 외부 연동
리뷰어, 문제 검출
● 시나리오는 한 번에 하나씩 검토 ● 문제 발견시 그 시점에 바로 기록
o 메모 정도만 하고, 리뷰 과정에 방해가 되지 않도록 자세한 기록은 1개 시나리오 검토 후에 기록
● 시나리오 다시 보기 o 1개 시나리오 검토 후, 어느 부분을 어떻게 검토했는지 메모
§ 리뷰가 진행되어 간다는 심적 안정감 얻음 o 본인의 지식이 낮다고 생각되면, 리더와 교체 논의 필요
● 문제기록표 작성 o 문제의 심각성, 수정 공수, 문제의 복잡도 등 고려해서 기록
§ 단순 오타, 부정합 등은 문서에 표기해서 작성자에 바로 전달 o 문제 기록표 항목: 문제 유형(시나리오), 위치, 내용
리뷰 회의의 목적
● 리뷰어가 문제를 지적하여 중요 문제를 빠짐없이 검출하는 것
● 문서나 시스템을 리뷰어나 작성자가 어느 정도 이해하고 있는지 서로 파악
● 불필요한 활동(교육, 정보 공유)을 하면 리뷰 회의의 목적에 소홀해지기 쉬움
리뷰 회의 준비 리더 리뷰어 작성자
1. 지적될 문제 상정 - 지적된 문제 유형을 다시 확인하고, 완료 기준을 미리 정의 2. 회의 계획 수립 - 예상 소요 시간 등을 고려해서 회의 일자, 몇 회로 할지를 결정 - 기록 담당자를 별도 지정 3. 문제기록표 수집과 확인 - 문제 기록표를 수집하고, 미리 확인 - 이해할 수 없는 문제, 설명 부족, 리뷰 부족 등에 대비 4. 회의실 준비 - 회의실 예약하고, 설비와 좌석 배치 등을 미리 고려 5. 회의 시작 선언 - 회의의 목적과 마음가짐을 상기시키면서 회의 시작
1. 검출한 문제의 우선순위 결정 - 중요한 문제를 놓치지 않도록 우선순위 결정 2. 지적할 문제에 대한 설명 준비 - 미리 설명 내용을 준비 3. 마인드의 재인식 - 불필요한 발언을 하지 않도록 자세 준비 - 작성자의 태도를 바꾸려 하지 말고, 문제 지적에 집중 리뷰 중 좋았던 점 준비: 회의에서 언급하면 분위기가 좋아짐
- 사전에 관련 문서나 보조 자료 준비 - 정신 가다듬기
뻘소리 방지용 암호 준비: 예, 고참개발자가 만담을 하면 ‘리프(leaf) 노드'라고 주의를 줘서 중요하지 않은 얘기를 그만하도록 함
리뷰 회의 리더 리뷰어 작성자
1. 지적된 문제 내용의 이해와 공유 - 우선순위에 따라 시나리오마다 문제 지적을 진행하고, 리뷰어로부터 설명을 들음 2. 유사한 중요 문제의 검출 - 문제마다 심각도를 결정하고, 유사 문제가 없는지 확인 3. 주제를 벗어났을 때 궤도 수정 - 자기과시, 만담, 교육 등이 시작되면 제지해야 함 4. 시나리오 완료 확인 - 시나리오에 따른 문제 지적을 다 했는지 재차 확인 5. 회의 종료 - 의문점이 남아 있는지 확인 - 문제에 대해 수정과 확인 담당자를 지정 - 기록담당자로 하여금 문제일람표를 바로 공유하도록 지시
1. 문제 검출 방법 설명 - 어떤 문서의 몇 쪽에서 어떤 방법으로 검출했는지 설명 2. 문제 지적 - 심각도가 높은 것 부터 지적하고, 내용을 이해할 수 있게 설명해야 함 3. 문제 지적 종료 - 기록 담당자가 정리할 수 있게 도움 4. 다른 리뷰어의 지적에 대한 이해 - 자기 차례 끝났다고 끝난 게 아님 - 다른 리뷰어의 지적에서 새로운 문제를 발겨하기도 함
- 지적된 문제에 대한 이해와 감사의 마음 필요 - 지적 받은 문제를 정확히 이해하기 위해 노력함 - 문서 수정은 회의 종료 후에 진행
수정과 확인
● 리뷰가 물거품이 되지 않도록 지적 받은 문제를 반영해야 함 o 리더, 리뷰어도 수정 작업에 협조
● 진행 순서 o 1. 문제 이해와 순서 결정
§ 기억이 선명하게 남아 있을 때 바로 진행 o 2. 수정과 자기 체크 o 3. 리뷰어의 확인
§ 리뷰어는 나라면 어떻게 수정했을지 미리 생각하고, 수정 문서를 리뷰 진행
o 4. 리더의 최종 확인 § 수정 공수가 커지는 문제 위주로 확인 § 최종 리뷰 보고서 작성 (검출수, 리뷰회의 소요 시간 등)
기타 내용
● 재발 방지 회의 o 리뷰 과정에서 지적된 문제가 왜 발생했는지 원인을
분석하고 재발 방지책 검토 ● 프로젝트 후 회고
o 리뷰에서 놓친 문제를 파악해서 예방방법 검토 o 문제 유형과 시나리오 정련 o 불필요한 시나리오는 제거
● 리뷰 기법 o 워크스루, 인스펙션, 테크니컬 리뷰
요약
● 리뷰를 잘 하려면, o 올바른 방식으로 진행해야 함
§ 준비 → 문제 검출 → 문제 지적 → 수정/확인 o 리뷰 마인드 필요 (이게 어쩌면 가장 중요)
§ 리더, 리뷰어, 작성자는 각자 역할에 따라, 리뷰가 실패하지 않도록 리뷰에 임해야 함
● 책에 대한 소감 o 약간은 지루한 점도 있지만, o 개발 리더라면 읽어봐야 할 책이라 생각됨