Overview
Code Review Workflow
1.
소프트웨어 엔지니어(SWE)가 CL(Change List)를 구현
2.
CL 오너가 동료에게 CL을 전송(코멘트를 받기 위해서)
3.
지정된 동료가 받은 CL에 대해 코멘트를 남김
4.
CL 오너가 지정된 동료가 남긴 코멘트를 기반으로 CL을 수정
(LGTM(Looks Good To Me) 피드백을 받을 때까지)
5.
모든 리뷰어가 LGTM을 말하면, CL 오너가 저장소(repository)에 CL을 제출
Possible Downsides of Code Review
•
거칠고 무례한 의견 때문에 CL 오너가 자신감을 잃거나 의욕이 꺾일 수도 있음
•
리뷰가 늦어지면 개발 기간이 늘어짐
•
코드 리뷰를 제대로 하려면 시간이 걸림
•
경험이 부족한 개발자의 잘못된 CL을 리뷰하느라 숙련된 개발자의 시간이 허비될 수 있음
•
코드 리뷰를 위해서는 어느 정도 숙련된 개발자 필요
Code Reviews Are Cultural
•
코드 리뷰 프로세스는 문화적 지지(support)가 필요
◦
동료 존중하기
◦
건설적인 피드백 남기기
◦
코드 리뷰 문화를 성장시키는 데에는 시간이 걸림
•
코드 리뷰는 건강하고 확장성 있는 코드 기반을 유지해나가는 데 도움이 됨
◦
투명성을 높임
◦
협업을 불러일으킴
◦
코딩 표준(standard)을 점진적으로 향상시킴
◦
코드 리뷰는 팀워크에 관한 것
Testing
Why is Testing So Important?
Testing Rocks! Debug Sucks!
•
디버깅은 보통 문제를 찾는 데 시간이 엄청 오래 걸림
•
테스팅은 새로 작성한 코드에서도 결함 검출 가능
•
테스팅은 테스트 코드를 필요로 하기 때문에, 유지 보수 부담을 줄임
Project Scalability
•
새로 온 개발자도 테스트 코드를 잘 작성해서 프로젝트에 기여 가능
•
동료나 외부 기여자에게도 도움을 받기에 가장 적합함
Testing Types
Unit Testing
•
프로그램의 가장 작은 단위(함수, 메서드, 클래스 등)가 의도대로 동작하는지 확인
•
대부분 함수 하나의 동작이 유효한지 확인
Integration Testing
•
두 개 이상의 모듈(서비스)이 서로 연결된 상태에서 정상 작동하는지 확인
Regression Testing
•
기존에 잘 동작하던 기능이 새로운 코드 변경 이후에도 문제없이 작동하는지 확인
End-to-End(E2E) Testing
•
실제 사용 시나리오를 처음부터 끝까지 테스트