Google의 개발문화와 프로세스(2) - Feedback & Code Review

Transcript

1. Saryong Kang
   Senior Developer Relations Engineer @ Google Japan
   Google의 개발문화와 프로세스(2)
   

   View Slide

2. Disclaimer
   ● 기본적으로 공개된 내용에 기초하고 있지만, 해석은 어디까지나 개인 의견입니다.
   ● 아무리 성공 사례라고 해도 도입의 이유는,
   ○ "구글이 한다니까" ‍♂
   ○ "나 or 우리 조직에 필요하고 AND 적합하니까" ‍♂
   

   View Slide

3. Disclaimer 2
   ● Google은 Culture 문서에서 feedback의 중요성을 명시적으로 언급하고 언급하고
   있지는 않음
   ● Feedback 문화 자체에 대해서는 Netflix, McKinsey와 같은 조직을 참고하는 것을 추천
   ○ eg. "규칙 없음” by 리드 헤이스팅스, 에린 마이어
   https://ridibooks.com/books/510001020
   

   View Slide

4. I. 서론:
   Google 면접에서 떨어진 후,
   더 가고 싶어진 이야기
   

   View Slide

5. 성장에 대한 고민
   ● 개발을 손 떼면서 반대로 보이게 된 것
   ○ 주니어→시니어로의 성장은 저절로 되지 않는다
   ○ When the Advanced Beginner doesn’t care enough to interact with the broader
   community and for whatever reason doesn’t have much interaction with peers, ...
   

   View Slide

6. Expert Beginner
   ● 성장 vs 자존감에서 후자에 더 무게중심
   ○ 부정적 feedback에 지나치게 거부 반응
   ○ Low hanging fruit에 집착
   ○ “난 이미 알 건 다 알아”
   ● 참고:
   ○ [번역]더 이상 배우려 하지 않는 개발자 : Expert Beginner의 등장
   ○ [번역]소프트웨어 집단의 부패:Expert Beginner의 유산
   

   View Slide

7. Google 인터뷰를 받으면서 배운 점
   ● 나보다 훨씬 훌륭한 엔지니어들도 합격이 잘 안 되는 이유:
   ○ 단순히 개발만 잘 하는 사람을 원하지 않는다. 대신..
   

   View Slide

8. II. Google의 feedback 문화
   

   View Slide

9. Google의 피드백 문화 - lead by example
   ● Google에서는 “업무 지시”, 혹은 “필수 교육”이라고 하는 개념이 거의 없음.
   ● 리더는 “나의 충고는..." 같은 어법을 절대로 쓰지 않음
   ○ 대신 리더는 항상 피드백에 열려있음
   

   View Slide

10. Google tgif (and more!)
    ● 매주 목요일 CEO가 사원들의 질문에 대답
    ○ 예의를 차리지 않고 하는 예리한 질문이 많으나, 고맙게 받아들이고 성의있게
    답변
    ● 모든 부문/부서별로 매달 혹은 매분기 당 같은 이벤트가 있음
    → 모든 리더들은 부서원들의 어떤 질문과 피드백에도 마음이 열려있음
    ● Googlegeist - 전 직원의 기탄 없는 의견을 수집, 전략에 반영
    

    View Slide

11. 그로 인한 낙수 효과
    ● 자연스럽게 서로 솔직한 피드백을 주고 받는 문화가 있음
    ● 인사평가도 360도 실명 평가
    

    View Slide

12. 문화적인 차이
    ● High-context vs low-context → Generous high를 지향: 솔직한 존중
    

    View Slide

13. 피드백의 기술
    Start by stating the purpose of the feedback session
    “I want to have a discussion about…” ; “I wanted to share some thoughts on…” ; “I wanted us to together evaluate…”
    Give feedback on strengths
    FACTS
    State the facts: “I have observed that…” ; “The report that you prepared was…” ; “The initiative that you
    undertook...”; “You did a great job at…” +Illustrate why it was good
    IMPACT
    State what effect it had, e.g., you felt inspired, motivated, clients were happy, stakeholders were appreciative:
    “It made me feel…” ; “This resulted in…”: “The feedback we got on this was…”
    RECOMMENDATION
    Reinforce the positive behavior: “I recommend you to continue doing… / do more of this… / build on this
    strength...” ; “Could you coach me/the team on…”
    Give feedback on development areas
    FACTS
    State the facts: “On the other hand, there are a few areas that I feel you could consider working on. I have
    observed that…” ; “During the meeting I noticed that…” ; “However, while working together I observed that”
    IMPACT
    State what effect it had, e.g., you felt intimidated, confused, clients were unhappy, stakeholders were
    dissatisfied: “It made me feel…” ; “This resulted in…”: “The feedback we got on this was…”
    RECOMMENDATION
    Make a recommendation going forward: “My recommendation to you is…” ; “In order to address this I suggest
    you…” ; “You might find it helpful to try doing…” ; “In future you might want to avoid...”
    Pause; Listener to acknowledge and ask any clarifying questions if any
    Thank the person (applies to both)
    

    View Slide

14. 개인적인 경험
    ● 새로운 시도, but..
    ○ My manager of manager wasn’t happy about that and didn’t bless me.
    ● 평생 경험한 적 없는 일 - 1주일 뒤, 10분간, 놀라울 정도로 구체적으로 사과 받다!
    

    View Slide

15. 열렬한(?) 칭찬 문화
    ● Remarkable한 성과를 보면 반드시 칭찬함
    ○ 하지만 sandwich를 위한 의례적 칭찬은 지양 - 상대가 잘한 점, 고칠 점을 정확히
    알 수 있도록
    ● Peer bonus
    ○ 받으면 월급에 추가됨, 그리고..
    

    View Slide

16. III. Google의 Code Review
    (문제 해결 위주로)
    

    View Slide

17. 용어 설명
    ● 개발자
    ● 리뷰어: 주로 해당 코드의 Owner(코드의 원작자, 혹은 같은 팀 담당자) 중 하나가 담당
    ● 코드베이스 == 코드 리포지토리
    ● 변경/추가된 새로운 코드들 == PR == MR == CL
    

    View Slide

18. Problem: 심리적인 저항
    ● 리뷰어가 남이 자기가 짠 부분을 바꾸는 것에 지나치게 민감
    ● 코드 리뷰의 Standard 1:
    ○ 개발자는 반드시 코드를 발전시켜야 한다.
    ○ 코드베이스에 아무 개선사항을 올리지 않는다면 코드베이스도 나아지지
    않는다.
    ○ 리뷰어가 기존 코드에 대한 변경에 너무 까다롭게 대하면, 개발자가 향후 코드를
    개선해갈 의지를 잃는다.
    

    View Slide

19. Google의 Owner 개념
    ● 구글은 Owner 개념이 다름
    ○ 무엇보다 작성자는 Googley 해야함: 초기 구현 시의 높은 책임! (특히 테스트)
    ○ 대신, 한 번 짜고 나면, Owner는 자기가 짠 코드에 대한 Review 책임만을 가짐.
    (예외: beyonce rule, 긴급 사태)
    ○ 기능 변경, 버그 수정이 요구될 경우, Owner 대신 해당 수정이 필요한 사람이
    수정하는 것을 적극 권장
    

    View Slide

20. P: 일정에 밀려 낮은 품질 코드를 승인하고자 하는 유혹을
    받음
    ● 코드 리뷰의 Standard 2
    ○ 리뷰어는 전체적인 코드 품질이 낮아지지 않도록 할 책임이 있다
    ● 코드 리뷰의 Standard 3
    ○ 리뷰어는 자기가 리뷰한 코드에 대해 ownership과 책임을 가진다
    ○ 그러므로 코드베이스의 품질이 충분한 지 꼼꼼히 봐야한다
    

    View Slide

21. 일반적으로,
    리뷰어는 코드가 완벽하지 않더라도,
    전체적인 코드 품질을 증가시키는
    상태까지 도달했다면,
    이를 승인해주는 방향으로 생각해야
    한다.
    

    View Slide

22. Google 코드 리뷰의 Standard
    ● Key Point: 세상에 완벽한(perfect) 코드는 없다. 더 나은(better) 코드가 있을 뿐
    ● 리뷰어는 승인의 전제로 개발자가 코드의 아주 세부사항까지 깔끔하게 만들 것을
    요구하면 안 된다.
    ● 중요한 것은 지속적인 개선을 목표로 하는 것
    ● 대체로 시스템의 유지보수성, 가독성을 높이고 있다면, "완벽하지 않다”는 이유로
    승인을 몇 일 이상 끌어선 안 됨
    

    View Slide

23. P: 지적을 주고 받는 가운데 감정적이 되는 경우가 종종
    있음
    ● 상호 존중 / 논리적인 이유 설명 / 대안 제시
    ○ ‍♂ 병행(concurrency)으로 수행해도 큰 이점이 없는데 왜 쓰레드를 쓰셨어요?
    ○ ‍♂ 여기에서는 병렬 구조로 인한 복잡성 대비 성능상 이점이 보이지 않네요.
    성능에 크게 차이가 없으니 해당 코드는 단일 쓰레드에서 실행하는게 최선인 것
    같습니다.
    ● 충돌이 생길 경우, 만나서 대화를 통해 해결하는 것을 강력 추천
    

    View Slide

24. P: 코드 리뷰 적체 현상
    ● Speed vs Interruption
    ○ 리뷰어는, 몰입 상태가 아니라면 즉시 리뷰한다.
    ○ 최악의 사태에도 업무일 기준 하루는 넘기지 않는다.
    ○ 신청 → 승인까지 걸리는 시간이 짧은 것보다, 리뷰 메시지가 빨리 오가는 것이
    중요
    

    View Slide

25. IV. Google의 코드 리뷰 Best
    Practice
    

    View Slide

26. Best Practices
    ● Be polite and Professional
    ○ 사람이 나쁜 게 아니라 코드가 나쁜 것
    

    View Slide

27. Best Practices
    ● Write Small Changes
    ○ 하나의 PR에는 하나의 독립적인 변화만 있어야 한다!
    ○ 왜?
    ■ 리뷰가 빠르다. 더 빈틈없는 리뷰를 받을 수 있다. 버그가 발생할 가능성이
    적다. 거절됐을 때 낭비되는 시간이 적다. 코드를 머지하기 쉽다. 제대로
    설계하기 용이하다. 리뷰에 의존하지 않고 다른 작업을 하고 있을 수 있다.
    문제가 생겼을 때 되돌리기 쉽다.
    ○ 대략 100 line 정도가 좋음. 1,000 line은 너무 큼 (Java / C++ 기준)
    

    View Slide

28. Best Practices
    ● Write Good Change Descriptions
    ○ 좋은 설명문은 PR이 무얼 하고 있는지 첫 줄에 설명한다.
    ○ 본문에는 어떤 문제를 해결하는지, 왜 이렇게 해결했는지, 그리고 코드에 대한
    설명도 있고 해당 PR에 대한 배경 설명과 추후 발전 방향이 포함될 수도 있다.
    

    View Slide

29. Best Practices
    ● Keep Reviewers to a Minimum
    

    View Slide

30. Best Practices
    ● Automate Where Possible
    ○ lint를 적극 활용!
    ○ 사소한 스타일에 대한 것들은 custom lint rule로 정의
    

    View Slide

31. 여기까지 모든 코드리뷰 관련 내용은 여기에서..
    ● Code Review Developer Guide
    ○ https://google.github.io/eng-practices/review/
    ○ 한글 번역 by 노수진 님: https://soojin.ro/blog/google-code-review-guide
    

    View Slide

32. Thank You
    https://speakerdeck.com/saryong
    

    View Slide