Code Review - DevOn2013

Code Review : What, 2 Whys & How

다음커뮤니케이션 - 이호정

About Me

1. 다음에서는 언제부터 일했나? > 2011년 경력 입사 > 소프트웨어 품질팀 소속

2. 무슨 일을 하고 있나? > 사내 개발 플랫폼 개발 및 운영 > 관련 Practice 가이드 및 교육

3. 최근에는? > 사내 코드 리뷰 문화 전파를 위해 노력 중! > 사내 모바일 개발 환경 효율화를 위한 시스템 개발 중!

Table Of Contents

1. Overview

2. Benefits & Hurdles

3. Practices

4. in Daum

5. Conclusion

Overview

Daum communications DevOn 2013

Overview오늘의 이야기

✓코드 리뷰 왜 해야 하는 건가요?

✓코드 리뷰를 잘 수행하기 위해서는 어떻게 해야 하나요?

✓다음은 코드 리뷰 어떻게 하고 있나요?

!

Real Code Review

WHAT?


Real Code ReviewWhat is Code Review?

✓ Code Review

• 소프트웨어를 실행하지 않고 사람이 직접 검토하는 과정을 통해 잠재 된 결함을 찾아내고 개선해 나가면서전반적인 소프트웨어의 품질을 높이고자 하는 활동

✓ Real Code Review

• 코드를 통해 서로 소통하고, 서로 배움을 얻고, 배움을 주는 활동

• Goal is cooperation, not bug-hunting

• Daily work


Real Code Review

✓ Product 완성 단계에 수행하는 것이 아니다.

✓개발 단계에서 일상적으로 수행해야 한다.

✓ Like Lean! MVP, MVC

Daily work

Feature

CODING

Code

CODE REVIEW

LEARN

Comment

Minimun Viable Code


Real Code ReviewDaily Work

분석 설계 구현 테스트코드리뷰?

Sequential !

vs. !

overlapping

Daily Code Review

Benefits

1stWHY?


BenefitsTest Driven Development

✓겉에서 보기에는

• 테스트 코드를 만들고 커버리지를 높이는 것.

• 테스트로 인한 코드 변경시의 안전망 확보.

✓하지만, 속을 들여다 보면

• 코드를 작성하기 전에 무엇을 개발할 지 생각하게 하는 것.

• 코드 작성 후 리팩토링을 통한 Clean Code, Sound Design 을 유지하는 것.

• Clean Code that works


BenefitsCode Review

✓테스트와는 별개의 새로운 결함 필터

✓테스트를 통해 찾지 못하는 결함을 발견할 수 있음

✓초기(개발 단계)에 결함을 발견함으로써 미래의 결함 해결 비용을 상당히 단축 시킬 수 있음

✓테스트보다 더 효과적으로 결함을 발견(ref. Code Complete)


BenefitsReal Benefits

하지만, 코드 리뷰의 주 목적은 결함을 찾는 것이 아닙니다.

코드 리뷰는 좀 더 결함이 적은 소프트웨어를

보장합니다.


✓서로의 코드에 대해 이야기 해볼 기회를 제공함으로써 배움을 통한 성장을 촉진하는 것.

✓중요한 것은 사람 사이의 건전한 소통.

BenefitsReal Benefits

좋은 코드의 공유

개발자의 지속 성장 결함 발견은 덤

팀내 협업 강화


Benefits덤

Case Study


Case StudyGoogle

프로그래밍 실력 향상에 도움이 된 개발 문화를 하나 꼽는다면?

코드 리뷰를 통해 많이 성장했어요. 코드 리뷰 시스템이 잘 돼 있는 곳이 구글입니다. 코드를 체크인 하기 전에 다른 동료에게 승인을 받아야 해요. 구글 내에서 정말 뛰어나다고 생각하는 개발자가 내가 작성한 코드의 각 라인을 보고 코멘트를 달아주기 때문에 실력 향상에 큰 도움이 됐어요.

ref. http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=41858

http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=41858



Case StudyGoogle

코드 리뷰가 좋다는 것은 알지만 한국의 개발자들은 빠듯한 일정으로 인해 우선순위에서 밀려 하지 않는 경우가 많은데요.

코드 리뷰를 하면 당연히 시간이 많이 들죠. 하지만 시간을 투입하는 만큼의 장점이 있다고 생각합니다. 신입 개발자는 선배 개발자에게 지식을 배울 수 있는 기회고, 선배 개발자의 경우 새로운 기술과 경험을 습득하는 기회가 되죠. 또 대부분의 기술은 코드를 통해 배우므로 코드 리뷰의 중요성은 더 말할 필요가 없죠.

ref. http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=41858




Case StudyDaum - A팀

코드 리뷰 활동 도입 후 그 효과는?

✓버그 발견, 코드 개선, 지식 공유 측면에서 모두 효과가 있다고 생각한다. !

✓정량적인 측정은 쉽지 않지만, 코드 품질 개선 효과에 대해서는 확신한다. !

✓또한, 코드 품질 개선 효과 이외에도 다른 팀원들이 지금 어떤일을 하고 있고, 어떻게 진행되어 가는지에 대해 알 수 있어 타 팀원의 업무에 대한 이해도가 증가한다고 생각한다.


Case StudyDaum - B팀


✓내 코드를 다른 사람에게 검증 받을 수 있어서 좋다. !

✓문제가 있는 코드에 대해서 의견을 개진할 수 있다는 것이 좋은 것 같다. !

✓그리고 코드를 아주 꼼꼼히 보는게 아니더라도 다른 사람이 한 번 만이라도 슬쩍 읽어보기만 해도 그 자체로 의미가 있다고 생각한다. !

✓커밋 자체가 조심스럽고 신중해졌다.


Case StudyDaum - C팀


✓지식 공유 효과가 가장 크다고 본다.팀 내에서도 누군가는 알고 있고, 누군가는 몰랐던 사실을 코드 리뷰를 통해서 공유가 되고 전파된다. !

✓리뷰 받는 입장에서 장애, 버그 발생에 대한 사전 방지책(보호막)이 되어 준다는 느낌이 들어 심적 부담이 주는것 같다. !

✓리뷰를 받는 과정속에서 리뷰어의 경험을 습득할 수 있다.


Case StudyDaum - D팀


✓새로 팀에 합류한 팀원에 대한 코딩 스타일, 컨벤션을 빠르게 습득하게 하는 효과가 있다. !

✓안좋은 습관들을 그대로 배우게 되어 퍼져나가던 것들이 코드 리뷰를 통해 공유될 수 있어 지식 공유 효과가 큰 것 같다. !

✓리뷰 진행 시에 클린 코드에 대한 이야기를 하다 보니 자연스럽게 버그를 잡게 된다. !

✓혼자 개발하지만 코드 리뷰를 통해 마치 pair 로 개발하는 것과 같은 효과가 있다.

Hurdles

2ndWHY?


Hurdles2 Hurdles

✓물리적 허들

• 일정, 리소스에 대한 오해

• 조직에 적합한 코드 리뷰 기법 도입

• 적절한 도구와 가이드

• 지속적인 관심과 개선 의지

✓심리적 허들

• Programmer’s Ego

• 공감대 형성


Hurdles심리적 Hurdle

어떻게 장애물을 넘어야 할까요?


HurdlesEgoless Programming 10계명

✓당신이 실수할 것이라는 것을 받아들여라.

✓당신이 만든 코드는 당신이 아니다.

✓당신이 얼마나 많이 알고 있다고 해도, 항상 누군가는 더 많은 것을 알고 있다.

✓권위는 지위가 아니라 지식으로부터 나온다.

✓자신보다 많이 알지 못하는 사람이라 해도 존경과 인내로 대하라.

✓사람이 아니라 코드 그 자체를 비판하라.

ref. 생각하는 프로그래밍

http://book.daum.net/detail/book.do?bookid=KOR9788995300930



Hurdles설문조사

✓코드 리뷰를 잘 수행하기 위해 필요한 것은?

!

!

!

✓코드 리뷰 활동이 쉽지 않은 이유는?

6%18%

20%27%

28%일정 확보공감대 형성인프라 구축가이드 및 지원기타

11%

15%

17%22%

35%일정 부족지적에 대한 두려움코드 리뷰 방법이 불편해서복잡하고, 많고, 가독성 떨어지는 코드잘하는 방법을 몰라서


Hurdles일정, 일정, 일정...

코드 리뷰는 꼭 많은 시간이 필요한 것 일까요?


Hurdles일정

✓단기적으로는 어느 정도 비용이 필요한 활동

• 미래의 결함 해결 비용을 개발단계에 빌려 사용하는 것

• 빌린 시간을 효율적으로 사용하기 위한 노력 필요

• 적절한 리뷰 기법 도입, 도구를 활용한 효율화

✓소프트웨어 생명 주기 전체를 감안하면 전체 비용은 오히려 감소

• 동일한 결함이라도 개발 단계와 릴리스 이후에 수정하는 비용은 많은 차이가 발생

• Real Benefits로 인한 Clean Code, Sound Design 의 증가는 높은 품질, 높은 생산성으로 연결됨


HurdlesFagan Inspection Graph

ref. Advances in Software Inspections. MICHAEL E. FAGAN

Costs

Time

With Code Review

Without Code Review

Release

http://www.mfagan.com/pdfs/aisi1986.pdf



Hurdles무슨 시간 일까요?

15분/1 review

칼 가는 시간 아깝다고, 안드는 칼 가지고 고생하지 말자!

What? Why?

w?Practices


Practices

✓ Adoption, Overall, Workflow

Practices

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료

Overall

Adoption


PracticesAdoption

✓팀 설득 시키기

• 코드 리뷰는 혼자 하는 활동이 아니다.

• 충분한 공감대가 없다면 도입해도 실패할 가능성이 높다.

• 협업 강화, 코드&개발자의 지속 성장, 코드 품질 향상 등 설득 시킬 명분은 분명하다.

• 리더를 공략하라.

• 공감대 형성이 쉽지 않을 경우 약간은 강제적인 것이 빠른 정착에 효과적일 수 있다.(리더에 의한 top-down) (Not 오늘 부터 무조건 코드 리뷰 해.)


PracticesOverall

✓가볍게 시작하라

• 처음부터 복잡한 프로세스와 규칙을 정하는 것은 빠른 실패로 가는 지름길!

• 더 이상 뺄 수 없을 만큼 간소화 할 것!

• 필요할 때 마다 프로세스를 재정의 하고, 규칙을 생성!

✓강요하지 마라!

• 코드 리뷰는 숙제 검사가 아니다.

• 이 역시 빠른 실패로 가는 지름길

• 코드 리뷰의 이점을 스스로 느끼고 따라올 수 있도록 격려


PracticesOverall

✓ asynchronous review

• 모든 팀원이 같은 시간, 같은 장소에 모일 필요는 없다.

• 시간과 공간의 제약이 없는 온라인 리뷰가 효율적이다.

• 감정에 치우치지 않는 리뷰!

✓공유하라!

• 리뷰를 통해 발견한 흥미로운 코드, 좋은 설계 등을 활발하게 공유하라.

• 코드 리뷰의 목적은 knowledge sharing 이다.


PracticesOverall

✓코드 리뷰는 개발과 별개의 작업이 아니다.

• iteration 종료 or 모든 개발이 완료될 때 까지 기다리지 마라.

• 분석, 설계, 개발, 테스트 이후의 단계가 아니다.

• 늦은 리뷰는 리뷰를 하지 않는 것 보다 좋지 않을 수 있다.

• To-Do 와 Done 사이의 새로운 단계로 생각하자!

• Daily work!

✓ Egoless Programming


PracticesOverall

✓크게 덜하기 보다 작게 자주 하라

• 일반적으로 코드가 적을 수록 리뷰 하기 쉬워진다.

• 큰 작업은 작은 atomic 한 작업으로 분리하라.

• 리뷰 대상이 적을수록 결함 발견율은 높아진다.

ref. best-kept-secrets-of-peer-code-review

http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf



Practices코드 작성

✓한번에 하나의 작업만 수행

• Task Level Commit

✓ commit message 에 반드시 jira 이슈 번호를 기록

• 작업과 소스간의 추적 가능

• 작업 별 리뷰 생성이 쉬워진다.

✓첫 번째 reviewer 는 자신이다.

• 표준이 있다면 반드시 지키도록 한다.

• 별거 아닌데 다음에 고쳐야지! == 장애 나면 고쳐야지!

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 대상 코드 선정

✓리뷰 대상 코드 선정은?

• jira 이슈 단위가 무조건 편하다.

✓이슈가 크다면?

• 분리할 수 없을 때까지 분리하라!

• 일반적으로 4h~16h 동안 해결 가능한 크기가 적절한 이슈의 크기

✓작게 쪼갰는데도 코드가 많다면?

• 이슈가 완료될 때 까지 기다리지 마라.

• 개발 중간이라도 리뷰를 생성하라.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 대상 코드 선정

✓모든 이슈에 대해 리뷰를 생성해야하나?

• 팀의 공감대 형성 수준, 코드 리뷰 수행 의지에 따라 달라질 수 있다.

• 의미 없이 변경 되는 소스는 없으며, 변경된 소스는 릴리스 되므로 가능한 리뷰를 진행하도록 한다.

• 공감대나 의지가 낮은 경우, 자율에 맡기고 점차 범위를 넓혀 나가는 방식을 택해야 한다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰어 선정

✓리뷰어는 많을 수록 좋을까?

• 많다고 무조건 효과가 높아지지 않는다.

• 10명 x 1건/day = 하루 종일 리뷰

✓그러면 몇 명 이어야 해?

• 보통 2~4명을 권장 한다.

✓전문적인 리뷰어가 필요할까?

• 팀외부에서 리뷰만 해주는 사람

• 있으면 좋다. 단 전문 리뷰어만 지정되어서는 안된다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰에 대한 설명 남기기

✓ Author는 리뷰 및 코드에 대한상세한 설명을 기록해야 한다.

• 다시 강조하지만 첫 번째 리뷰어는 본인 자신이다. 내가 읽게 된다고 생각하고 리뷰를 만들자.

• jira 연동시 간단하게 설명을 남길 수 있다.

• 리뷰어가 빠르고 쉽게 리뷰할 수 있도록 노력해야 한다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료

ref. best-kept-secrets-of-peer-code-review

http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf



Practices리뷰 진행 - 리뷰어

✓리뷰 대상 코드만 리뷰 하라.

• 리뷰 대상 코드 이외의 코드에 대한 문제점은이번 리뷰에서 언급하지 마라.

• 새롭게 리뷰를 만들거나, 크리티컬한 내용이라면 다른 방법으로 팀내에 이슈화 하라.

✓한 번의 리뷰에 너무 많은 시간을 소비하지 마라.

• 30분 내외가 적당하다.

• 아무리 길더라도 60분을 넘지 않도록 한다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 진행

✓어떤 수준까지 리뷰를 해야 하나?

• Business logic

• Naming & Style

• Design & Architecture

• Test Code 작성 여부

• 재사용성, 확장성, 성능, 보안 등

• 적절한 라이브러리 사용

✓체크 리스트는 Author, Reviewer 모두에게 도움이 된다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료

상황에 따라 다르다!


Practices리뷰 진행

✓바로 옆자리에 리뷰어가 있네?

• 간단한 ad-hoc 성격의 리뷰는 오프라인에서 의견을 물을 수 있다.

• 가이드는 가이드일뿐 편한방법은 취하자.

✓코멘트로 이야기 해서 언제 결론 내지?

• 내용이 복잡하거나 길어질 경우 Comment로만 주고 받는것이 효율적이지 않을 수 있다.

• 이럴 경우 오프라인에서 협의를 도출하고, 그 결과를 리뷰에 정리하도록 한다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 진행 - 코멘트 남기기

✓ Comment 는 최대한 친철하게

• 왜? 는 사용하지 마라.

• 같은 내용이더라도 더 부드러운 표현을 사용하라.

• 칭찬을 많이 하라. 오글거릴 정도로!

✓ Comment를 남길 때 반드시 그 이유도 함께 설명하라.

• 소스의 잘못된 점을 지적할 때 Author가 납득할 수 있도록 이유를 반드시 설명한다.

• Author 가 충분히 알만한 내용은 생략해도 된다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 진행 - 소스 수정

✓리뷰 중 소스 수정 발생 시

• 1) 현재 수행 중인 리뷰에 Changeset 추가

• 2) 새로운 리뷰 생성

• 3) 별도 이슈로 추출

• 일반적인 경우 1번, 소스 변경이 크리티컬 할 경우 3번 2번은 권장하지 않음.

✓리뷰어는 반드시 소스 수정이 올바르게 되었는지 재확인 하도록 한다.

• ‘변경할게요’ 라는 comment만 있고, 소스 변경은 하지 않는 경우도 있다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 완료 - 리뷰어

✓최대한 빨리 리뷰 해 줄 수 있도록한다.

• 자신의 일이 아주 급하지 않다면, 리뷰를 먼저 해주는것이 좋다.

• 늦어도 24시간 이내에는 리뷰 할 수 있도록 한다.

• 오전 업무 시작 전 or 오후 업무 마무리 전에 리뷰하는 시간을 정하는 것도 방법이다.

• Author 의 입장에서는 피드백을 빨리 받을수록 업무 효율성이 좋아진다.

• 바쁜데 리뷰 해 달라고 해서 미안한 것이 아닌 리뷰 늦게 해줘서 미안하게 되는 문화가 되어야 한다.

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices리뷰 종료 - Author

✓리뷰가 종료되는 기준은?

• 1) 모든 리뷰어가 리뷰를 완료하지 않더라도Author의 판단에 따라 리뷰를 종료 할 수 있다.

• 2) 모든 리뷰어가 리뷰를 완료한 뒤 종료할 수 있다.

• 일반적으로 1번을 권장

리뷰 진행

리뷰 생성

리뷰 완료

코드 작성

리뷰 종료


Practices관찰

코드 리뷰가 잘 되고 있는지 어떻게 알 수 있을까?

아주 중요함!


Practices좋은 현상

✓ Comment 남기는 것이 자연스러워 짐

✓코드 작성 시 더 신경을 쓰게 됨

✓리뷰 생성/수행 시간이 길어짐

• 코드가 엄청 많으면 오히려 짧아짐

✓피드백 받는 시간이 점차 짧아짐

✓리뷰 진행에 대한 불편한 점이 자주 리포팅 됨


Practices좋지 않은 현상

✓설명 없이 코드만 올림

✓ Comment 에 대한 답변이 없음

✓피드백을 받는 시간이 점차 길어짐

✓리뷰를 모아서 한꺼번에 요청함

원인을 파악하고 해결하기 위한

시도가 반드시 필요!


Practices측정

코드 리뷰의 효과를 입증할 수 있나?


✓코드 리뷰의 효과를 정량적으로 측정하는 것은 쉽지 않다.

• 신뢰할 수 있고, 의미 있는 수치를 측정하는 것이 불가능 할 수 있다.

• 리뷰 건수, 진행 시간 등 측정 가능한 Metric은 리뷰 도입 시 참조 용도로 활용될 수 있다.

✓측정할 수 없는 이점들

• Real Benefits

• 개발자 스스로 느낄수 있다.

Practices측정


Hurdles이것만은 제발 측정 하지 말자!

결함 발생 횟수/개발자

결함 발견 건수/리뷰어

in Daum


in Daum2가지 접근

✓프로세스

• 전사 프로세스에 코드 리뷰/체크 단계가 있다.

• 프로젝트 중요도 별로 강도는 다르다.

✓개발 문화

• 하나의 개발 문화로 바라보고 접근하고 있다.

• 개발자 스스로 리뷰 활동을 통해 배움을 얻고, 배움을 주는 것에 재미를 느낄 수 있도록 전파하고 있다.

• 앞에서 말했던 여러 practice 들을 기준으로 하되, 각 팀만의 규칙을 정하고 발전시켜 나가고 있다.


in Daum도입

✓현황 파악

• 전사 개발자 대상 설문 조사

• 코드 리뷰 활동을 활발하게 진행하고 있는 팀 대상 인터뷰

✓눈높이 맞추기

• 설문 조사와 인터뷰를 진행한 결과 팀마다, 사람마다 코드 리뷰에 대한 생각이 다름.

• 코드 리뷰에 대해 오해하지 않고, 이해할 수 있도록 가이드

• 팀 단위 교육, 세미나, 팀 리더 대상 세미나 등.


in Daum도입

✓적절한 기법 선정

• 우리 조직에 적합한 코드 리뷰 기법을 선정

• 선택은 도구를 활용한 Async Peer Review

• 기법에 맞는 적절한 Practice

✓도구 선택

• 여러 오픈 소스 Tool, 상용 Tool 을 검토

• 선택은 Atlassian Crucible!

• Git&SVN 지원, 사용성, Jira 연동, pre-commit 리뷰 기능은 조금 아쉬움.


in Daum더 중요한 것들!

SCM

JIRA (scrum,kanban)

Code Review

✓ 프로젝트 작업 관리 ✓ 개발자는 개발할 작업들을 지라 이슈 단위

로 관리한다. ✓ 작업을 작게 쪼개는 연습이 필요.

✓ Task Level Commit ✓ Commit message 에는 반드시 지라 이슈

번호를 기록 ✓ 적절한 코드 라인 관리 전략

✓ 지라 이슈 단위로 리뷰 수행 ✓ Just 3 Clicks - 리뷰 생성

Traceability

Visibility

Conclusion

Practice나 Tool 은 쉬운 도입을 위한 가이드 라인일 뿐입니다.

제일 중요한 것은 조직 내 공감대 형성입니다.

그리고, 지속적인 관심과 더 나아지려고 하는 의지가 있을 때 코드 리뷰는 하나의 개발 문화로 안착 될 수 있습니다.

관찰

적응 시도

점진적이고 지속적인 변화

코드 리뷰는 문화다!단기간X, 강제X

하루 30분나를 위해 나의 동료를 위해 우리 조직을 위해

Let’s try!

감사합니다[email protected]

mailto:[email protected]

Technology

Code Review - DevOn2013