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

Transcript

1. Saryong Kang Senior Developer Relations Engineer @ Google Japan Google의

   개발문화와 프로세스(2)

2. Disclaimer • 기본적으로 공개된 내용에 기초하고 있지만, 해석은 어디까지나 개인

   의견입니다. • 아무리 성공 사례라고 해도 도입의 이유는, ◦ "구글이 한다니까" ‍♂ ◦ "나 or 우리 조직에 필요하고 AND 적합하니까" ‍♂

3. Disclaimer 2 • Google은 Culture 문서에서 feedback의 중요성을 명시적으로 언급하고

   언급하고 있지는 않음 • Feedback 문화 자체에 대해서는 Netflix, McKinsey와 같은 조직을 참고하는 것을 추천 ◦ eg. "규칙 없음” by 리드 헤이스팅스, 에린 마이어 https://ridibooks.com/books/510001020

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

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, ...

6. Expert Beginner • 성장 vs 자존감에서 후자에 더 무게중심 ◦

   부정적 feedback에 지나치게 거부 반응 ◦ Low hanging fruit에 집착 ◦ “난 이미 알 건 다 알아” • 참고: ◦ [번역]더 이상 배우려 하지 않는 개발자 : Expert Beginner의 등장 ◦ [번역]소프트웨어 집단의 부패:Expert Beginner의 유산

7. Google 인터뷰를 받으면서 배운 점 • 나보다 훨씬 훌륭한 엔지니어들도

   합격이 잘 안 되는 이유: ◦ 단순히 개발만 잘 하는 사람을 원하지 않는다. 대신..

8. II. Google의 feedback 문화

9. Google의 피드백 문화 - lead by example • Google에서는 “업무

   지시”, 혹은 “필수 교육”이라고 하는 개념이 거의 없음. • 리더는 “나의 충고는..." 같은 어법을 절대로 쓰지 않음 ◦ 대신 리더는 항상 피드백에 열려있음

10. Google tgif (and more!) • 매주 목요일 CEO가 사원들의 질문에

    대답 ◦ 예의를 차리지 않고 하는 예리한 질문이 많으나, 고맙게 받아들이고 성의있게 답변 • 모든 부문/부서별로 매달 혹은 매분기 당 같은 이벤트가 있음 → 모든 리더들은 부서원들의 어떤 질문과 피드백에도 마음이 열려있음 • Googlegeist - 전 직원의 기탄 없는 의견을 수집, 전략에 반영

11. 그로 인한 낙수 효과 • 자연스럽게 서로 솔직한 피드백을 주고

    받는 문화가 있음 • 인사평가도 360도 실명 평가

12. 문화적인 차이 • High-context vs low-context → Generous high를 지향:

    솔직한 존중

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)

14. 개인적인 경험 • 새로운 시도, but.. ◦ My manager of

    manager wasn’t happy about that and didn’t bless me. • 평생 경험한 적 없는 일 - 1주일 뒤, 10분간, 놀라울 정도로 구체적으로 사과 받다!

15. 열렬한(?) 칭찬 문화 • Remarkable한 성과를 보면 반드시 칭찬함 ◦

    하지만 sandwich를 위한 의례적 칭찬은 지양 - 상대가 잘한 점, 고칠 점을 정확히 알 수 있도록 • Peer bonus ◦ 받으면 월급에 추가됨, 그리고..

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

17. 용어 설명 • 개발자 • 리뷰어: 주로 해당 코드의 Owner(코드의

    원작자, 혹은 같은 팀 담당자) 중 하나가 담당 • 코드베이스 == 코드 리포지토리 • 변경/추가된 새로운 코드들 == PR == MR == CL

18. Problem: 심리적인 저항 • 리뷰어가 남이 자기가 짠 부분을 바꾸는

    것에 지나치게 민감 • 코드 리뷰의 Standard 1: ◦ 개발자는 반드시 코드를 발전시켜야 한다. ◦ 코드베이스에 아무 개선사항을 올리지 않는다면 코드베이스도 나아지지 않는다. ◦ 리뷰어가 기존 코드에 대한 변경에 너무 까다롭게 대하면, 개발자가 향후 코드를 개선해갈 의지를 잃는다.

19. Google의 Owner 개념 • 구글은 Owner 개념이 다름 ◦ 무엇보다

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

20. P: 일정에 밀려 낮은 품질 코드를 승인하고자 하는 유혹을 받음

    • 코드 리뷰의 Standard 2 ◦ 리뷰어는 전체적인 코드 품질이 낮아지지 않도록 할 책임이 있다 • 코드 리뷰의 Standard 3 ◦ 리뷰어는 자기가 리뷰한 코드에 대해 ownership과 책임을 가진다 ◦ 그러므로 코드베이스의 품질이 충분한 지 꼼꼼히 봐야한다

21. 일반적으로, 리뷰어는 코드가 완벽하지 않더라도, 전체적인 코드 품질을 증가시키는 상태까지

    도달했다면, 이를 승인해주는 방향으로 생각해야 한다.

22. Google 코드 리뷰의 Standard • Key Point: 세상에 완벽한(perfect) 코드는

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

23. P: 지적을 주고 받는 가운데 감정적이 되는 경우가 종종 있음

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

24. P: 코드 리뷰 적체 현상 • Speed vs Interruption ◦

    리뷰어는, 몰입 상태가 아니라면 즉시 리뷰한다. ◦ 최악의 사태에도 업무일 기준 하루는 넘기지 않는다. ◦ 신청 → 승인까지 걸리는 시간이 짧은 것보다, 리뷰 메시지가 빨리 오가는 것이 중요

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

26. Best Practices • Be polite and Professional ◦ 사람이 나쁜

    게 아니라 코드가 나쁜 것

27. Best Practices • Write Small Changes ◦ 하나의 PR에는 하나의

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

28. Best Practices • Write Good Change Descriptions ◦ 좋은 설명문은

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

29. Best Practices • Keep Reviewers to a Minimum

30. Best Practices • Automate Where Possible ◦ lint를 적극 활용!

    ◦ 사소한 스타일에 대한 것들은 custom lint rule로 정의

31. 여기까지 모든 코드리뷰 관련 내용은 여기에서.. • Code Review Developer

    Guide ◦ https://google.github.io/eng-practices/review/ ◦ 한글 번역 by 노수진 님: https://soojin.ro/blog/google-code-review-guide

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