Recommended
More Related Content
What's hot
What's hot (20)
Similar to 2019 11-code review
Similar to 2019 11-code review (20)
Recently uploaded
Recently uploaded (8)
2019 11-code review
- 2. 본인 소개 • LG-CNS: M/W 지원 • 2번의 스타트업 • Daum: 아고라(대운하, 소고기, 촛불), • SK-Platnet / 11st –아키텍처 개션 §MSA §EDA / 비동기 결제 –개발 문화 개선 §개발 환경 개선 §개발 역량 강화
- 3. 목차 • 왜 코드리뷰를 해야 하나 ? • 코드리뷰란 ? • 왜 코드리뷰가 어려운가 ? • 기법들 • References • Q&A
- 4. 왜 코드리뷰를 해야 하나 ? • 시장과 비즈니스의 요구사항 • 개발 리소스 증가 추이 • 동일 기간별 개발 생산성 • 릴리즈가 증가함에 따른 개발 비용 • Release별 생산성 • 아키텍처의 중요성 • Architecture란 • SW의 속성 • Software Craftmanship
- 5. 시장과 비즈니스의 요구사항 Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Microservices
- 6. 개발 리소스 증가 추이 Clean Architecture
- 7. 동일 기간별 개발 생산성 Clean Architecture
- 8. 릴리즈가 증가함에 따른 개발 비용 Clean Architecture
- 10. 아키텍처의 중요성 • 엉망진창의 징후(signature of mess) –기능이 동작만 하면 아키텍처 개선 없이 다음 기능 구현. Burndown Chart –기능 변경: 복붙 + 일부 수정 → 향후 수정시 문제 –공유 부족으로 소수의 개발 인력에 대한 의존도 높아짐 • 클린 코드, 좋은 설계, 아키텍처에 주의를 기울여야 Clean Architecture
- 11. Big Ball of Mud • 뚜렷한 아키텍처없이 구현된 시스템
- 12. SW 개발의 단순한 진리 • “The only way to go fast, is to go well” –생산성 저하와 비용 증가를 뒤집을 수 있는 유일한 방법 –SW 아키텍처의 품질에 대해서 신중해져야 Clean Architecture
- 13. Architecture란 ? • The Two Values of SW –Secondary value of SW is it's behavior §현재의 SW가 현재 사용자의 현재 요구사항을 만족 –Primary Value of SW(80%) §지속적으로 변화하는 요구사항 수용(tolerate, faciliate) • 극단적 가정 –동작하지만 고칠 수 없는 SW –고칠 수 있지만 동작하지 않는 SW https://cleancoders.com/
- 14. Architecture란 ? • 요구되는 시스템을 구축하고 유지보수하는데 요구되 는 인적 리소스를 최소화하는 것 • 기능 요구 사항과 무관 –어떤 아키텍쳐로도 SW 구축 가능 –Big Ball of Mud • 비기능 요구사항에 대한 것 = 품질 속성(“-ilities”) –maintainability, extensibility, testability, scalability https://cleancoders.com/
- 15. SW의 속성 • 설계의 산출물(Reproducible) –100층 건물(BDUF): 요구사항 변경 수용 ? –SW(Agile) 1994년 발스탠디시 그룹
- 16. Software Craftmanship • 환경의 변화: 시장 / 비즈니스 / 개발 • Software Craftsmanship(개발 문화) –Agile(더 좋은 SW 개발, 단순 절차 변경?, 개발 역량?) –장인 §후배들에게 지식과 경험을 공유(커뮤니티) §지식과 경험의 공유만이 전문성 갖춘 개발자 육성 –Code Review §개발자가 지금부터 행할 수 있는 공유 §Code SNS 댓글 놀이 https://cleancoders.com/
- 17. 코드리뷰란 ? • Code review 목적 –주목적: 품질 문제 검수(버그, 장애) –추가적인 목적 §Better code quality: 아키텍쳐 속성 개선을 위한 코드 개선 §Learning/Knowledge transfer: 코드, 해결책 등과 관련된 지 식 공유에 기여 §Increase sense of mutual responsibility: 집단 코드 오너십 및 결속 증대
- 18. 코드리뷰란 ? • 저자(Author) –코드 작성 / 리뷰 요청 • 리뷰어(Reviewer) –코드를 읽고 –머지 가능한지 결정 • Changelist(Pull Request) –리뷰 시작 전에 작성 –저자가 머지(Merge)를 원하 는 소스 코드에 대한 일련의 변경(잘 한 것, 아쉬운 것, 눈 여겨 볼 것)에 대해 기술 1. change list 2. written feedback 3. approval 4. merge
- 19. 왜 코드리뷰가 어려운가 ? • 저자 –본인 생각에 멋지다고 생각하는 PR을 보냄 • 리뷰어 –왜 멋지지 않은지에 대한 장황한 이유를 작성 • “In aviation, for example, people who greatly overestimate their level of skills are all dead” • 코드에 대한 비판을 자신에 대한 비판으로 이해 –게다가 상대가 직책자이면...
- 20. 왜 코드리뷰가 어려운가 ? • 코드리뷰는 –지식 / 공학적 결정을 공유 하는 기회 –공유(잘 한 것, 아쉬운 것)를 통해 서로의 지식/경험을 나누 며 상호 학습을 통한 역량 증대 수단 –코드 토의를 개인적 공격으로 받아들이면 물거품 • 생각을 글로 전달하는 것에 대한 어려움 –오해의 위험이 큼(음성 톤, 표정의 부재) • 피드백을 조심스럽게 표현하는 것이 더 중요 –“You forgot to close the file handle” → –“I can’t believe you forgot to close the file handle ! You’re such an idiot” 로 받아들임
- 21. 기법들 1. 지루한 작업은 컴퓨터로 처리 2. 스타일 가이드를 통해 스타일 논쟁을 해소 3. 리뷰는 즉시 시작 4. 고수준으로 시작, 저수준으로 내려가라 5. 예제 코드 제공에 관대해라 6. 절대 “너”라고 하지 마라(왜, 맨날 …) 7. 피드백은 명령이 아니라 요청으로 표현해라 8. 의견이 아니라 원칙에 기반하여 피드백하라
- 22. 1. 지루한 작업은 컴퓨터로 처리 • 코드를 읽는 것은 인지적으로 부담되는 고수준의 집중 이 요구되는 작업 –컴퓨터가 할 수 있는 일에 이런 노력을 낭비하지 말라 §심지어 기계가 더 잘 할 수 있는 일에 • Formatting Tool –공백, 들여쓰기 오류 등 –별도의 커밋/PR로 분리. 리뷰 불필요를 기술해서 리뷰를 생략할 수 있도록
- 23. 2. 스타일 가이드를 통해 스타일 논쟁을 해소 • 스타일에 대한 논쟁은 리뷰에서 시간 낭비 –Option1: Adopt an existing style guide –Option2: Create your own style guide incrementally –Option3: The Hybrid approach
- 24. 3. 리뷰는 즉시 시작 • 코드리뷰를 높은 우선순위로 다뤄라 –저자는 리뷰 종료될 때까지 대기(Blocked)함 • 리뷰를 바로 시작하면 선순환됨 –PR의 Size와 Complexity가 중요 §작고, 범위가 좋은 PR —> §쉽고 상쾌하기 리뷰하기 좋음 —> §빠르게 리뷰 수행 • 리뷰 라운드의 최대 시간은 하루 –우선순위 높은 업무로 1일 내 불가하면 다른 리뷰어 지정 –월 1회 이상 재지정을 해야한다면 속도를 줄여서 건강한 개발 Practices를 유지할 수 있어야함
- 25. 4. 고수준으로 시작, 저수준으로 내려가라 • 리뷰 라운드에서 더 많은 의견을 남길 수록, 저자가 당 황할 위험 커짐 –하나의 라운드에 20~50개 정도의 의견은 위험의 시작 –초기 라운드에서는 고수준 피드백으로 제한 §인터페이스 클래스의 재설계, 복합한 함수의 분리 등 –고수준의 피드백이 처리된 후에 저수준 이슈를 처리 §변수명 변경, 주석을 명확하게 하는 것 등
- 26. 5. 예제 코드 제공에 관대해라 • 저자를 기분 좋게 하기 위한 방법 –리뷰 중에 선물 주기(코드 예제) –“list comprehension으로 간단히 할 수 있지 않을까요 ?” §list comprehension을 모른다면 20분을 헤매야 • 너무 긴 예제는 관대한 것이 아니라 억업적으로 보임 • 라운드당 2~3개의 코드 예제로 제한 – 모든 PR(Pull Requst)에 예제를 제공하면 저자가 코드를 작성할 수 없다고 생각한다는 신호
- 27. 6. 절대 “너”라고 하지 마라(왜, 맨날 …) • 저자의 방어 유발을 최소화하는 방법으로 피드백 –비판의 대상은 코드. 저자가 아님 –“너”: 저자의 주의를 코드에서 자신으로 바꿈 • “너”만 빼라(저자에 대한 판단 → 단순한 정정) –“You misspelled ‘successfully’” → –“sucessfully → successfully” • 주어만 빼라 • - ~하는 것을 제안합니다. ~하는게 어떨까요.
- 28. 7. 피드백은 명령이 아니라 요청으로 표현해라 • 일상에서 동료에게 명령하지 않음 –ex. 스테이플러 좀 줘. 그리고 음료수 좀 가져다 줘 • 하지만 리뷰에서는 강압적인 명령을 종종 발견됨 –ex. 이 클래스를 별도의 파일로 분리하라 • ex. –Foo 클래스의 별도의 파일로 분리하라 → –Foo 클래스를 별도의 파일로 분리할 수 있을까요 ?
- 29. 8. 의견이 아니라 원칙에 기반하여 피드백하라 • 저자에게 의견을 줄 때는 –“제안하는 변경”과 “변경의 이유”를 모두 설명하라 –ex. 이 클래스를 2개로 분리해야 해요 → 지금 이 클래스 는 파일 다운로드와 파싱의 2가지 책임을 가지고 있어요. 다운로더와 파서 2개의 클래스로 분리하여 SRP를 준수해 야 해요 • SW는 과학인 동시에 예술 ??? –항상 원칙에 기반하여 정확히 뭐가 잘 못 되었는지 언급할 수 있는 것은 아니다 §단지 그냥 보기 싫거나 직관적이지 않을 수 있다 §무엇을 할 수 있을지 객관적으로 설명하라 §ex. This is confusing —> I found this hard to understand
- 30. 기법들 • 9. 한두 등급만 코드 레벨을 올리는 것을 목표로 • 10. 반복적인 패턴에 대해서 피드백을 제한하라 • 11. 리뷰의 범위를 존중하라 • 12. 큰 리뷰를 잘게 나눌 기회를 찾아라 • 13. 진정한 칭찬을 해라 • 14. 사소한 이슈만 남았다면 승인해라 • 15. 교착상태를 적극적으로 처리해라
- 31. 9. 한두 등급만 코드레벨을 올리는 것을 목표 • D 등급의 PR을 받으면 저자가 C나 B 등급을 받도록 도와라 –Letter Grade –make it work, make it right, make it fast • 완전하지는 않아도 충분히 좋은 코드가 되도록 • F –기능적으로 틀렸거나 –너무 복잡해서 정합성에 확신이 없는 상태 • 승인을 보류하는 유일한 이유 –수 차례의 리뷰 라운드 후에도 코드가 F 상태인 경우
- 32. 10. 반복적인 패턴에 대해서 피드백 제한하라 • 저자의 실수가 동일한 패턴임을 식별 했다면 모든 경 우를 언급하지 말라 • 동일 패턴에 대해서 2~3개 정도의 예를 언급하라 –그 이상은 저자에게 개별 사례가 아니라 패턴에 대해서 수정을 요구하라
- 33. 11. 리뷰의 범위를 존중하라 • 자주 보이는 Anti-Pattern –PR 근처의 코드를 보고 저자에게 수정을 요청 • Rule of thumb –PR에 포함되지 않은 라인은 리뷰 범위가 아님 • 예외: PR이 둘러싼 코드에 영향을 미칠 때
- 34. 12. 큰 리뷰를 잘게 나눌 기회를 찾아라 • 400 LOC 이상의 리뷰는 작게 분리하도록 제안 • 저자가 PR을 분리하는 번거로운 일에 불평할 수 있음 –분리를 위한 논리적 경계를 식별해서 짐을 덜어줘라 –예 §여러 파일에 걸쳐 변경했다면 파일별로 리뷰를 나눠라 §추상화 수준이 낮은 함수/클래스를 찾아 별도 리뷰로 분리 제안 –코드 품질이 낮을 때 리뷰 분리를 강조 §품질이 낮은 코드의 리뷰는 LOC가 늘면 기하급수적으로 어려 워짐
- 35. 13. 진정한 칭찬을 해라 • 대부분의 리뷰어가 코드의 잘못된 부분에만 집중 – 하지만 리뷰는 긍정적 행위 강화를 위한 값진 기회이기도 함 • PR에서 좋은 변경이 있을 때마다 –“오 이런 API가 있나요. 정말 유용해요” –“정말 좋은 해결책이네요. 생각도 못 했네요” –“함수를 분리한 것은 좋은 생각이에요.훨씬 단순해졌어요” • 저자가 쥬니어 혹은 신규 입사자라면 리뷰에 매우 민 감하고 방어적일 수 있음 • 진심어린 칭찬은 리뷰어가 잔인한 감시자가 아니라 도 와주려는 팀동료라는 것을 보여서 이런 긴장감을 낮춤
- 36. 14. 사소한 이슈만 남았다면 승인해라 • 모든 커멘트가 수정되는 것을 확인하고 나서야 승인하 려는 오해 존재 –불필요한 코드 리뷰 라운드를 추가. 저자/리뷰어 모두 시 간 낭비 • 아래 조건 중 하나라도 만족되면 승인 –더 이상 커멘트가 없을 때 –남겨진 커멘트가 사소한 이슈(변수명 변경, 오타 등) –남겨진 커멘트가 선택적 제안(Optional Suggestion) §ex. 높은 수준의 Refactoring/Design Pattern 적용 등
- 37. 15. 교착상태를 적극적으로 처리해라 • 코드 리뷰의 최악의 결과는 교착상태(Stalemate) –커멘트를 반영하지 않으니 승인 거부 –저자는 커멘트 반영을 거부 • 만나서 얘기하라 –화상 혹은 만나서 논의 –텍스트 기반 의사소통은 상대가 인간이라는 것을 잊게 함 • 인정하거나 Escalate하라 –교착상태가 길어지면 관계가 나빠짐 –그냥 승인하는 비용 - Agree to disagree §저수준 코드를 무심코 승인하면 품질 좋은 SW를 만들 수 없음 §또한 동료와 너무 다퉈서 함께 일하지 않는다면 고수준의 품질 을 얻을 수 없음
- 38. 15. 교착상태를 적극적으로 처리해라 • 인정이 불가한 경우 –저자에게 논의를 팀장이나 테크 리더에게 Escalation 권유 –다른 리뷰어에게 할당을 권유 • 교착상태로 부터 회복 –상황을 관리자와 논의하라 –휴식을 가져라. 가능하다면 안정될 때까지 CR을 서로 보내 지 마라 –갈등 해결책을 학습하라
- 39. Reference • How to Do Code Reviews Like a Human (Part One) –https://mtlynch.io/human-code-reviews-1 • How to Do Code Reviews Like a Human (Part Two) –https://mtlynch.io/human-code-reviews-2 • https://www.youtube.com/codetemplate • https://brunch.co.kr/@cleancode • https://github.com/msbaek/memo • https://brunch.co.kr/@cleancode/39
- 40. Q&A • CR Tip / 좋은 리뷰어가 되기 위한 노력/방법 • 안하는 사람들을 어떻게 하게 할지 • CR 문화 정착의 어려움 / 극복방법 • PR 효과
- 41. CR Tip / 좋은 리뷰어가 되기 위한 노력/방법 • 학습 & 연습, 많이 해 보는 것 • 사례 공유 • Letter Grade –Make it work / right / fast • PR Template(chrome plugin) –description: PR의 배경, 구현 내용에 대한 간단한 설 명, 주의 깊게 봐 줬으면 하는 부분 –how to test: check out / build / test 명령어 –note: 기타 주의 사항
- 42. 안하는 사람들을 어떻게 하게 할지 • 자신에게 이득이 되어야 • 멋져 보여야 –하고 싶어짐. 그게 뭐든 –tool(IDE) • Refactoring Tip –lift & shift → refactoring, 나눠서 –Feature flag –Sprout class, method –미리 뭘 하지 말고 할 필요가 있게 만들어야
- 43. CR 문화 정착의 어려움 / 극복방법 • on / offline의 차이 –꾸중 vs 토론 • Author의 노력 –n명의 reviewer의 시간을 절약 –효과적인 리뷰 가능 • Leader의 관심과 의지 –환영식 / 가끔 그러나 매우 자세히 • 코드 비난에 대한 두려움
- 44. PR 효과 • 예상하지 못한 Bug를 타 프로젝트에서 발견하기도 • 시간이 지나니 선플도 달리기 시작 –“코드가 깔끔하네요.” –“이렇게 구현하는 수도 있군요. 좋네요” • 많은 사람이 코드를 보고 있다는 생각에 PR 올리기 전 한 번 더 코드를 다듬게 됨 • 좋은 설계, 아키텍처, 클린코드, TDD 등에 대한 공감 대 형성
- 45. Appendix • 참조한 블로그의 사례
- 46. 최악의 코드리뷰 사례 • S가 내게 보낸 첫번째 PR. 너무 대충. 파이썬 처음 해 본... • 의무감을 가지고 모든 이슈를 기록(60군데). 너무 많 은 실수를 찾아낸 나는 훌륭한 리뷰어 ??? • 몇 일 후 S는 Updated PR을 보냄 –커멘트에 대한 응답. 간단한 수정(변수명 변경, 오타 수정 등) 포함 –하지만 고수준 문제에 대한 언급 거부(정의되지 않은 행위, 잘못된 형식을 갖는 입력, 6단계까지 중첩되는 복잡한 제 어문 등)
- 47. 최악의 코드리뷰 사례 • 화가 나서 새로운 커멘트를 보냄(전문가 다운 어투로) • 1주가 지난 지금도 동일 리뷰에 대해서 설왕설래 중 • 이젠 더 이상 S와 같은 사무실에 있기 싫다 ㅠㅠ –이러다 이직 ???. 구글 사례. Agree to disagree –검색개발 리뷰 사건 • 3주가 지났는데 코드가 거의 변하지 않았다
- 48. 중재(Intervention) • Bob(최고 시니어 개발자)이 우리가 전에 시도하지 않 았던 2개의 작은 라이브러리를 분리하는 것(각각 30~50 LOC)에 대한 PR 작성을 S에게 요구하면 리뷰 를 시작 • S가 해당 업무를 수행하면 Bob은 즉각 승인 • 그런 다음 Bob은 메인 PR(200 LOC를 정리하는)에 도달 –몇개의 작은 제안을 하고, –PR을 승인 • Bob의 전체 리뷰은 이틀만에 완료
- 49. My worst code review: revisited • 잘못한 점 –S의 첫번째 리뷰 –평가 받는다고 느끼거나 방어적일 수 있다 –고수준 커멘트만으로 시작했으면 좋았다 §많은 수의 커멘트로 공격 당하는 느낌을 받지 않도록 –리뷰어의 역할은 방해가 아니라 개선을 돕는 것임을 보였 어야 §코드 예제 제시, 변경 분에 대한 긍정적 언급 등 –교착상태가 길어지도록 방치 §만나서 깊은 갈등에 대해서 언급 or 관리자에게 Escalate했어야
- 50. My worst code review: revisited • Bob이 잘한 점 –처음에 리뷰를 분리한 것. 2개의 코드 블럭을 머지하면서 관계가 좋아짐 –여전히 문제가 있었지만 문제는 작어졌고, PR을 관리하기 쉬워졌음 –리뷰를 완전하도록 억압하지 않았다