14. 코드 작성은…
한 번에 하나의 작업만 커밋
큰 이슈는 원자 단위(atomic)로 나눈다
4h ~ 16h 동안 해결 가능한 크기가 일반적
커밋 로그에는 이슈 번호 기록
첫 번째 리뷰어는 바로 자신
코딩 표준 준수
경고 제거
15. 리뷰 요청은…
리뷰는 작게 자주
코드가 작으면 리뷰하기도 쉽다
원할 때 마다
완료하지 않았어도 원할 때마다 요청
http://hamster.school/ko/tutorial/scratch/line_tracer_one_sensor.jsp
From Puss in boots by Dreamworks
16. 리뷰는 언제…
리뷰를 먼저
정말 급한 일이 아니라면 리뷰 먼저
그날 받은 리뷰는 그날 처리
오후에 받은 거라면 다음날 오전까지
늦어도 24시간 이내에
늦어진다면 언제 할 수 있을지 요청자에게 알리고 의사를 묻자
평소에 도저히 리뷰할 시간이 안 나면?
리뷰하는 날을 정하자.
17. 리뷰할 때는…
누구나 실수한다, 물론 자신도
코드 ≠ 자신
부드러운 어조, 칭찬하자!
작성자의 결정 존중
리뷰 내용 외 다른 내용은 언급 금지
추후 문제가 생겨도 비난하지 말고 빨리 해결책 찾자
글만으로 이해할 수 없으면 만나서
http://nownews.seoul.co.kr/news/newsView.php?id=20140102601008
http://www.dailymail.co.uk/embed/video/1153556.html
18. 리뷰는 무엇을…
코딩 표준?
불필요한 내용은?
전체적인 디자인은?
테스트하기 쉬운 구조?
더 나은 로직은?
재사용성과 확장성?
상황에 맞게 적절히
21. 기본 흐름
Main Main’
Local
1. Fork
2. Clone
3. Fix
(branch)
4. Push (branch)
8. Push
5. Pull request
7. Fetch
6. Merge
22. Pull Request 만들기
변경 내용을 (개인/작업) 저장소에 올림
Stash에서 (개인/작업) 저장소 접속 후 Create pull request 선택
또는 Source, Commits, Branches 페이지 액션 메뉴에서 Compare 선택
23. Pull Request 만들기
출발지와 목적지 브랜치 선택
출발지: 코드를 변경한 브랜치
목적지: 변경한 코드를 병합할 브랜치
24. Pull Request 만들기
Diff, Commits 탭에서 변경 내용 먼저 확인
Create pull request 선택
제목은 한 줄 요약
설명을 자세히
멘션(mention) 기능
@ + 사용자 표시 이름, 계정, 이메일 등
리뷰어 추가
28. Pull Request 논의
Commits
병합할 모든 커밋 목록
Pull request를 생성한 브랜치 코드 변경 pull request 내용에 자동 반영
Fetch 후 Local에서 확인
git fetch origin pull-requests/2/from:pullrequest
git checkout pullrequest
29. Pull Request 논의
Pull request tasks
논의 내용에 추가한 작업 목록
Overview 또는 Shift+T로 목록 확인 가능
회의실 확보, 시간 공유, 함께 모여야 하고 리뷰어는 코드를 미리 읽어 온 후 회의실에서 코드 리뷰 해야…
하지만! 대부분 미리 읽지도 않고 짧은 시간에 제대로 살펴 보기도 어려우며 모여도 그냥 앉아 있는 일이 다반사…
Crucible, Collaborator, Review Board – 별개 시스템 구성 필요
각자 편할 때 리뷰할 수 있음
우회로가 존재 – 할 수도 있고 아님 말고
코드와 함께 숨쉬는 코드 리뷰 – 코드로 커뮤니케이션, 즉 의사소통
코드 리뷰에서 장애물
이슈가 너무 크면 검토하기 어렵다
영화 소스 코드: 8분 전의 세계로 여행하며 열차 테러범을 찾는 영화. 실패할 때마다 재시도 이전의 자신은 지금의 자신과 다름. 서로 다른 세계에 존재. 평행 우주 얘기.
이처럼 코드 ≠ 자신
코드 스타일, 전반적인 디자인, 확장성과 유연함, 테스트는 쉬운지 등은 당연히 검토!