것 ◦ 주니어→시니어로의 성장은 저절로 되지 않는다 ◦ 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, ...
부정적 feedback에 지나치게 거부 반응 ◦ Low hanging fruit에 집착 ◦ “난 이미 알 건 다 알아” • 참고: ◦ [번역]더 이상 배우려 하지 않는 개발자 : Expert Beginner의 등장 ◦ [번역]소프트웨어 집단의 부패:Expert Beginner의 유산
대답 ◦ 예의를 차리지 않고 하는 예리한 질문이 많으나, 고맙게 받아들이고 성의있게 답변 • 모든 부문/부서별로 매달 혹은 매분기 당 같은 이벤트가 있음 → 모든 리더들은 부서원들의 어떤 질문과 피드백에도 마음이 열려있음 • Googlegeist - 전 직원의 기탄 없는 의견을 수집, 전략에 반영
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)
것에 지나치게 민감 • 코드 리뷰의 Standard 1: ◦ 개발자는 반드시 코드를 발전시켜야 한다. ◦ 코드베이스에 아무 개선사항을 올리지 않는다면 코드베이스도 나아지지 않는다. ◦ 리뷰어가 기존 코드에 대한 변경에 너무 까다롭게 대하면, 개발자가 향후 코드를 개선해갈 의지를 잃는다.
작성자는 Googley 해야함: 초기 구현 시의 높은 책임! (특히 테스트) ◦ 대신, 한 번 짜고 나면, Owner는 자기가 짠 코드에 대한 Review 책임만을 가짐. (예외: beyonce rule, 긴급 사태) ◦ 기능 변경, 버그 수정이 요구될 경우, Owner 대신 해당 수정이 필요한 사람이 수정하는 것을 적극 권장
없다. 더 나은(better) 코드가 있을 뿐 • 리뷰어는 승인의 전제로 개발자가 코드의 아주 세부사항까지 깔끔하게 만들 것을 요구하면 안 된다. • 중요한 것은 지속적인 개선을 목표로 하는 것 • 대체로 시스템의 유지보수성, 가독성을 높이고 있다면, "완벽하지 않다”는 이유로 승인을 몇 일 이상 끌어선 안 됨
• 상호 존중 / 논리적인 이유 설명 / 대안 제시 ◦ ♂ 병행(concurrency)으로 수행해도 큰 이점이 없는데 왜 쓰레드를 쓰셨어요? ◦ ♂ 여기에서는 병렬 구조로 인한 복잡성 대비 성능상 이점이 보이지 않네요. 성능에 크게 차이가 없으니 해당 코드는 단일 쓰레드에서 실행하는게 최선인 것 같습니다. • 충돌이 생길 경우, 만나서 대화를 통해 해결하는 것을 강력 추천
독립적인 변화만 있어야 한다! ◦ 왜? ▪ 리뷰가 빠르다. 더 빈틈없는 리뷰를 받을 수 있다. 버그가 발생할 가능성이 적다. 거절됐을 때 낭비되는 시간이 적다. 코드를 머지하기 쉽다. 제대로 설계하기 용이하다. 리뷰에 의존하지 않고 다른 작업을 하고 있을 수 있다. 문제가 생겼을 때 되돌리기 쉽다. ◦ 대략 100 line 정도가 좋음. 1,000 line은 너무 큼 (Java / C++ 기준)