지속가능한 SW 개발을 위한 코드리뷰에 관련된 세미나를 보고 개인적으로 정리해보았습니다.
코드리뷰 : 지속가능한 SW 개발
왜 코드 리뷰를 해야하나?
- VUCA란?
- 우리가 살고 있는 시대는 변동성이 많은 시대기 때문에 혼자만이 알고 있는 방법으로 해결하기 보단 빠르게 변하는 문제들을 모두와 함께 해결해야한다.
- 개발 조직의 성능(생산성)이 중요해지고 있다.
- 클린코드의 중요성
- SW의 진정한 비용 ~= 유지보수 비용- 작성보다 이해에 10배 이상의 노력 소요
- "The only way to go fast, is to go well" - Robert C. Martin
- 코드리뷰 목적
- 품질 문제 검수 (버그, 장애)
- 더 나은 코드 품질 -> 향후 변경 비용 개선
- 학습 및 지식 전달, 동기 부여
- 상호 책임감 증대
- 설계 개선 제안
- 개발 문화 개선
왜 코드리뷰가 어려운가?
코드에 대한 비판을 자신에 대한 비판으로 이해하기 때문
기법들
효율적인 PR 방법
기계가 더 잘할 수 있는 일은 기계에게 넘기자.
Formatting 은 별도의 커밋/PR로 분리하자.
스타일에 대한 논쟁은 리뷰에서 시간 낭비다. -> 합의를 하고 그것을 지키자.
PR을 올릴 때 Author가 먼저 주석을 달자
빨리 리뷰를 하라. -> 우선순위 높은 업무로 1일 내 리뷰
PR에 포함된 변경이 적도록 노력하라.
하나의 라운드에 20~50개 정도의 의견은 위험의 시작
초기 라운드에서는 고수준 피드백으로 제한 -> 그 이후에 저수준 이슈 처리
예제 코드 제공에 관대하라
리뷰의 범위를 존중하라
PR에 포함된 리뷰만 진행하라.
1~2등급만 코드레벨을 올리는 것을 목표로
F등급인 경우만 승인을 보류하는 유일한 이유여야 한다.
완전하지 않아도 충분히 기분 좋은 코드가 되도록만.
~하는 것을 제안합니다. ~하는 게 어떨까요? 추천
진정한 칭찬을 해라. 좋은 코멘트를 남겨라.
교착상태를 적극적으로 처리해라
ㅋㅋㅋㅋㅋㅋㅋ텍스트 기반 의사소통은 상대가 인간이라는 것을 잊게 함
필요한 기술들
TDD, 리팩터링, 레거시 코드 다루기, Clean Code
FAQ
개발생산성 vs 개발 품질의 트레이드 오프
버그 수정 비용은 개발 라이프 싸이클에서 후반으로 갈 수록 기하급수적으로 커짐
품질이 좋으면 후반으로 갈 수록 시간이 절약됨
Front-end developer