codereview mindset why we have codereview , 코드 리뷰 마음가짐 왜 우리는 코드리뷰를 해야하고 어떻게 해야할까 어떤걸 조심해야 할까? 코드리뷰를 감정적으로 접근하지 않아야 하며 좀더 단단한 코드를 위한 밀도있는 행위로 보아야함

1. Smell
like sin spirits
한셀팀 l 2016.08.11

2. 1) 코드리뷰 하자
2) 왜?
3) 어떻게?
4) 그래 하자!
1.코드리뷰의목적과방법1차
2.코드리뷰이제이렇게하자!(발전한다면?)
3.지나고보니...

3. 3
1.코드리뷰 하자
실제 테스트가 아닌
코드만을 보고 생길 수 있는 결함이나
더 좋은 방향의 코드를 제시한다던지
코드속에 언젠가 들어가게될 실수를 찾거나
QA 나 실제 Filed 에서 앞으로 발생할 문제를 미연에 방지
여러 사람들의 코드를 보고 배워 나가는 과정
실제 작업은 함께 하지 않더라도 작업 이후 짝코딩이 갖던 이점을 나눠 갖을 수 있음
일상적인 해오던 업무 이외로 추가 로 주어지는 Job 이 아닌 나중에 해야될 일을 미리 하는것 뿐

4. 4
2. 왜?
코드의 냄새를 찾고 제거 하거나 발전하자
타인은 내가 생각하지 못한걸 생각할 수있다
내가 생각하지 못한걸 타인의 코드를 보고 배울 수 있다
책임감 과는 별개의 문제
-내 코드는 똥이다
자신의 코드를 믿지 말자
타인의 코드도 믿지 말자
똥이라고 생각하면 편하다

5. -일하기도 바쁜데?
어차피 해야될일 미리 하는것 뿐
코드 검증이나 수정을 직접 하진 않는다
review 는 되도록 아주 짧게 commit 당 5-10분
5
2-1.어떻게?
논에서 피뽑는 버그잡기가 아닌
다함께 땅을 다지는 작업

6. 6
2-2.어떻게?
-시니어가 주니어의 코드를 돌봐준다?
하향식 코드리뷰 는 모두에게 도움되진 않는다
일방적인 시니어의 성향을 강요 / 시니어->주니어 로의 일방적인 benefit
! 시니어도 주니어에게 코드 코칭을 받을 수 있다
누구나 실수하고 새로운것은 시니어보다 주니어로부터 나올 수 있다
*시니어 주니어 구분없이 코드를 리뷰
-코드리뷰는 그렇게 하는게 아니던데?
commit 을 merge 하거나 시스템에서 컨벤션을 맞춰 줄 수도 있으며
github 의 commit 에 reply 를 달수도 있고
여러 utility 를 통해 review 된 코드만 실제 branch 에 merge 되도록 하여 해당 branch 의 내용을
qa qc 가 확인 하도록 하는 방법 등 이 보편적

7. 7
3. 그래하자!
-그래서 지금 당장?
1인이 같은 업무를 하는 고정 멤버를 포함한 2-3인의 코드를 보도록 단위 그룹을 구성
Weekly/Momthly 간격을 두어서 그룹을 랜덤 리매칭 (고정 멤버를 제외한 rotation)
그룹별로 문제발견시 서로 간단한 이야기를 전달 가급적 online 을 지향
필요시 미팅은 매우 짧은 시간 간단하게
그룹별 주 단위 팀원 모두가 공유할만한 내용은 팀원모두에게 Broadcasting On/Offline
-변화는 원래 쉽지 않다
당장 1달 안에 멈추게 되더라도 시도
리뷰는 과제가 아니라 문화라니 차차 점진적으로 차차 당연하게 받아들이도록
인간은 불편 하면 도구를 사용한다 불편한 부분은 차차 이용하도록 하자
하루이틀 해보고 아니다 싶어 그만둘 만한 문제는 아님
-그래도 난 하기싫어

8. Q/A