다음은 "4월 우아한테크세미나 - 지속가능한 SW 개발을 위한 코드리뷰" 내용을 정리한 글입니다
세미나 - https://www.youtube.com/watch?v=ssDMIcPBqUE
1. 왜 코드리뷰를 해야 하나?
1) 우리가 살고 있는 시대
Software is eating the world
- 소프트웨어에 의해 운영되는 제품과 서비스들의 영역이 늘고 있다
- VUCA : 불확실하고, 복잡하고, 모호하며 변화가 많은 세상이 될 것
- 변동성 -> 협업을 통해 문제 해결이 필요 => 코드 리뷰의 중요성이 증가할 것
- Non-Tech의 영역에서 개발자 수 증가 속도가 Tech 영역에서보다 가파름 -> 인구대비 개발자가 부족
- 비즈니스 성공을 위한 개발의 역할 -> DRFR, 개발 조직의 성능(생산성)이 중요해짐
2) 개발 생산성
- 출시가 진행될 수록 개발자는 늘고, 생산성은 감소하고, 라인 수는 증가한다(기술 부채가 생겨난다)
- 좋은 설계를 한다면 처음에는 생산성이 낮아보일 수 있으나 일정 시간이 지난 이후에는 계속적으로 높은 생산성을 가질 수 있다
3) SW 공학의 특성
- 공학 = 설계 + 빌드
- 다른 공학은 비용 측면에서 설계 < 빌드(건축의 경우 90%)
- 유지보수 비용은 상대적으로 낮음
- SW 공학은 설계 = 소스코드, 빌드 = 컴파일
- SW 공학의 경우 설계 > 빌드
- 좋은 설계는 곧 클린코드이고, 설계를 잘 하는 사람이 즉, 코드를 잘 작성하는 사람이다!
- SW의 진정한 비용 -> 유지보수 비용
- 한번 작성한 코드는 10번 이상 읽히고, 이해에는 10배 이상의 노력이 필요하다
- 90% 이상의 시간을 코드를 이해하는데 사용하기도 한다
The only way to go fast, is to go well(빨리 가는 유일한 방법은 잘 하는 것이다)
- 좋은 설계가 결국은 생산성 저하와 비용 증가를 막을 수 있다
- SW의 비용과 품질의 관계 -> 비정상적, 비직관적
- 좋은 설계를 한다면 변경 비용이 낮춰짐
- 높은 품질의 제품은 비싸다는 관점을 역전 시킬 수 있다
- 이러한 좋은 설계의 중요성을 전문가 정신뿐만 아니라 비즈니스 측면에서도 좋음을 어필한다면 설득하기 좋다
4) 장인정신
- 애자일
- VUCA 시대에 더 좋은 SW 개발 방법론
- 단순 적용으로는 성공하기 어렵다. 개발 역량도 어느정도 필요
- 장인정신
- 지식과 경험의 공유 -> 전문성을 갖춘 개발자를 육성가능
- 애자일의 확장된 개념으로 장인정신의 중요성 강조
- 코드리뷰
- 개발자가 지금부터 당장 행할 수 있는 공유 활동
- 코드로 SNS 댓글 놀이 하기
- 배움을 주고 받으며 지속가능한 SW 개발자가 될 수 있는 실천법이다!코드리뷰의 정의
- Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.
코드 리뷰는 소스 코드의 일부를 주로 보고 읽음으로써 프로그램을 확인하는 소프트웨어 품질 보증 활동이다.
5) 코드리뷰의 목적
- 주 목적 : 품질 문제 검수(버그, 장애)
- 아키텍처 속성 개선을 위한 코드 개선(을 통한 변경 비용 개선)
- 학습 및 지식 전달 : 코드, 해결책 등과 관련된 지식 공유에 기여
- 공유를 통한 역량 증대 및 성장
- 리뷰어도 리뷰 과정에서 지식을 얻을 수 있다
- 주니어 - 주니어 리뷰에서는 지식을 얻을 수 있다면, 주니어 - 시니어 리뷰에서는 시니어가 소통하는 스킬을 얻을 수 있다(하드스킬, 소프트스킬)
- 잘 하는 사람을 보며 동기 부여가 될 수 있다
- 상호 책임감 증대
- 집단간의 오너십, 결속 증대
- 누군가가 나의 일에 관심을 가져준다
- 팀원간의 일을 공유하면서 팀워크 증대
- 설계 개선 제안
- 이러한 과정을 통해 개발 문화가 개선 되는 것은 당연!
2. 코드리뷰의 절차
- 코드 작성 -> 리뷰 요청 -> 승인 -> 머지
- 저자
- 코드 작성 및 리뷰 요청(PR)
- 리뷰어
- 코드를 읽고
- 머지 가능한지 결정
- 좋은 PR은 저자가 내용을 상세하게 작성해서 리뷰어의 시간을 아껴주는 것
3. 왜 코드리뷰가 어려운가
- 코드에 대한 비판을 자신에 대한 비판으로 받아들이기 때문
- 나와 코드를 분리해서 생각해야 한다
- 생각을 글로 전달하는 것이 어렵다
- 음성이 아니고, 표정이 없기 때문에 오해의 여지가 크다
- 피드백을 조심스럽게 표현하는 것이 중요하다
4. 기법들
1) 효율적인 PR 방법
지루한 작업은 컴퓨터로 처리하자
- 코드를 읽는 것은 고수준의 집중이 요구되는 작업
- formatting, build, test, merge complict 등은 컴퓨터에게
스타일의 경우 스타일 가이드를 통해 논쟁을 해소
- 잘 만들어진 스타일 가이드를 적용하거나(구글, 우형 등)
- 자신들 만의 스타일 가이드를 점진적으로 만들어 적용하거나
- 위의 둘을 잘 조합해서 적용하거나!
- 내 마음에 안들더라도 팀에서 사용하기로 한 가이드를 따르는 것이 중요
PR에 주석을 달면 리뷰어도 보기 편하다
- 저자가 먼저 읽어 보고 리뷰어를 위한 설명을 커멘트로 남기자 -> 리뷰어들의 시간을 절약할 수 있게 하자
- 피드백 받고 싶은 내용이 있다면 적극적으로 작성하자
모두를 포함하자
- 많은 사람이 볼 수록 버그를 찾을 확률이 높다
- 대게 더 잘하려는 경향이 있다
의미 있는 단위로 커밋하자
- 혼자하는 코드 리뷰부터 해보자 -> 의미 있는 단위로 커밋하기 위한 연습
2) 효율적인 리뷰 방법
리뷰는 즉시 시작
- 코드리뷰를 높은 우선순위로 정하자
- 리뷰와 개선이 동시에 진행되는 것은 비효율적이다
- 한 가지 일에만 집중 할 수 있도록 하자
- 리뷰를 빨리 끝내준다면 선 순환이 될 수 있다
- 피드백은 시간이 걸리더라도 시작은 바로 해라
- 리뷰의 최대 기간은 하루로
- 1일 내 불가시 다른 리뷰어를 지정하자
- 재지정 횟수가 많아진다면 개선이 필요하다
- 매일 아침 30분, 점심 식사 후 30분을 리뷰를 위해 확보해보자
- PR에 포함된 변경이 적도록 하자
- 최대 4시간 안에 리뷰가 완료될 정도의 분량을 작성하자
- 근본적인 문제는 리뷰할 시간이 없다고 느낀다는 것
- 개인의 성과로만 평가를 받는다면, 팀을 위해 쓰는 시간이 시간 낭비처럼 보일 수 있다
- 조직의 측면에서 평가와 보상이 있도록 개선이 필요
- PR vs Pair
- 팀의 성향에 따라
- 우리팀이 내향적이고 비동기적인 상호작용을 선호하는 성향인지 아니면 외향적이고 개인적 상호 작용을 더 선호하는지
고수준으로 시작, 저수준으로 내려가라
- 너무 많은 의견은 저자가 당황할 수 있다
- 초기에는 고수준 피드백으로 제한
- 버그, 장애, 성능, 보안 등
- 복잡한 메서드 등
- 고수준의 피드백이 처리 된 후 저수준 이슈를 처리
- 설계 개선, 변수명 변경, 주석 등
예제 코드 제공에 관대해라
- 저자를 기분 좋게 하기 위한 방법
- 코드 예제를 선물로 주자
- 너무 긴 예제는 선물이라기 보단 억압적으로 보일 수 있다
- 너무 많은 예제도 좋지 않음(1~3개 정도)
리뷰의 범위를 존중하라
- 수정된 내용에서의 리뷰를 진행
- 예외 : 수정된 내용을 둘러싸고 있던 코드에 영향이 있을 때
태그를 활용해라
- [Nit] : 고치면 좋지만 아니어도 그만
- 더 개선할 수 있는 의견을 자유롭게 남기자
- ex) nit: null대신 Optional은 어떨까요?
한두 등급만 코드 레벨을 올리는 것을 목표로 해라
- D등급의 PR을 받으면 C나 B 등급을 받도록 돕자(Letter grade)
- 완전하지는 않아도 충분히 좋은 코드가 되도록 하자
- 승인을 보류하는 유일한 이유
- 수 차례 리뷰 후에도 코드가 F인 경우
3) 피드백 방법
절대 "너"라고 하지 마라
- 리뷰의 핵심은 "무엇이 코드를 나아지게 하는가" 이다. 잘못을 찾는 것이 아니다.
- 비판의 대상은 코드이지 저자가 아니다
- I message
- "~하는게 어떨까요?" 오픈 커뮤니케이션
건설적인 피드백을 하라
- 동료들 간의 코드 리뷰 -> 경쟁을 유발 하는 것이 아님. 생산성 향상이 목적!
- 코드리뷰를 학습의 과정으로 인지하면 전체적인 프로젝트의 성공에 기여할 수 있다
- 건설적인 피드백 -> 개발자들의 실력 향상에 동기 부여 가능
- 건설적인 피드백을 못하겠다면 차라리 하지말자
진정한 칭찬을 해라
- 대부분 리뷰어가 잘못된 부분에만 집중
- 주니어나 신규 입사자는 리뷰에 민감하고 방어적일 수 있다
- 리뷰어가 감시자가 아닌 도움을 주려는 팀 동료라는 인식을 주자
피드백은 명령이 아니라 요청으로 표현해라
- 리뷰에서 강압적인 명령이 종종 발견된다
- ex) 이 클래스를 별도의 파일로 분리하세요(X)
- ex) 이 클래스는 너무 커지는 것 같은데 괜찮을까요?(O, 나의 걱정)
의견이 아니라 원칙에 기반하여 피드백하라
- "제안하는 변경"과 "변경의 이유"를 모두 설명하라
- ex) 이 클래스는 2개로 분리해야 합니다(X)
- ex) 이 클래스는 파일 다운로드와 파싱이라는 2가지 책임을 가지고 있어요. 다운로더와 파서 2개의 클래스로 분리하여 SRP를 준수하는 것이 어떨까요?
- 단지 보기 싫거나 직관적이지 않을 수 있다. 객관적으로 설명하자
- ex) 이 코드는 혼란스럽네요(X)
- ex) 나는 이 코드를 이해하기 어렵네요(O, I message)
반복적인 패턴에 대해 피드백을 제한하라
- 저자의 실수가 동일한 패턴이라 해서 다 언급하지는 말자
- 2~3개 정도의 예를 언급하고 해당 패턴에 대해 수정을 요구하자
4) 교착상태 시
교착상태를 적극적으로 처리해라
- 교착상태가 되어간다는 증거
- 토론의 톤이 팽팽해지고 공격적으로 된다
- 라운드당 커멘트가 줄어들지 않는다
- 많은 커멘트에 저항이 보인다
- 코드리뷰의 최악의 결과 = 교착상태
- 리뷰어는 승인하지 않고
- 저자는 커멘트를 반영하지 않음
- 만나서 얘기하라
- 텍스트 기반 소통은 때때로 상대가 인간인 것을 잊게 한다
- 인정하거나 escalate하라
- 교착상태가 길어지면 동료와의 관계가 나빠진다(퇴사까지도?!)
- SW 품질이 낮아질 수 있다
- 교착상태의 회복
- 관리자와 논의하자
- 적당한 휴식도 해결 방법
- 해결책을 학습하는 것도 방법
- 설계 리뷰를 고려하자
- 설계에서 논의되어야 할 사항인지? 리뷰는 했는지?
- 교착상태가 심각하지 않다면 그냥 인정하고 동료와의 협업을 진행하는 것도 방법(Agree to disagree)
5) 코드리뷰를 하는 아주 재밌는 방법
- PR을 작성한 사람과 페어 프로그래밍 -> Revert -> 저자가 다시 스스로 개선
- 어쨌든 결정은 저자가
- "완벽한 설계"가 목적이 아님! "당신이 할 수 있는 최고의 설계"를 추구
- 팀 정신을 유지하기 위해 불완전한 해결책도 받아들여야 한다
- 모든 설계 결함이 항상 문제가 되는것은 아니다
- 코드 리뷰의 목적은 비난이 아닌 배움임을 잊지 말자
- 리뷰하는 코드가 정말 나쁠 때가 있음
- 사유가 있을 수도 있다. 좀 더 안내하는 가르침으로 전환하자
5. 코드리뷰 문화 정착의 어려움 / 극복방법
- 저자의 노력
- 리뷰어의 시간을 절약할 수 있고 효과적인 리뷰가 가능해진다
- 리더의 관심과 의지
- 지나친 관심은 부담이겠지만 자세하게 관심을 가져야 한다
- 코드 비난에 대한 두려움 극복필요
- 다른 팀에서도 따라하고 싶어지는 코드리뷰 문화가 필요
- 고통의 계곡
- 처음 도입시에는 성과가 떨어질 수 있지만 꾸준히 하다보면 결실이 있다
6. 코드리뷰의 효과
- 예상하지 못한 버그를 발견할 수 있다
- 시간이 지나면서 선플이 달리기 시작
- 많은 사람이 나의 코드를 본다는 생각 -> PR 전 코드를 다듬게 됨
- 좋은 설계, 아키텍처, 클린코드, TDD 등에 대한 공감대/열정 형성
7. 코드리뷰를 잘 하기 위해 필요한 기술들 - 책
- refactoring
- TDD와 연결된 리팩터링
- 매일 리팩터링하자
- working effectively with legacy code(레거시 코드 활용 전략)
- 의존성 관리, 테스트 추가, 레거시 분석 등
- TDD - Unit Testing(단위 테스트)
- Clean Code
8. FAQ
- 코드리뷰 자체가 중요할까? -> 공유와 코드에 대한 논의를 할 수 있는 문화가 중요!
- 개발 생산성 vs 개발 품질
- 버그 수정 비용은 후반으로 갈수록 기하급수적으로 커진다
- 높은 품질은 향후 추가 비용을 감소시킨다
반응형
