코드 리뷰어 활동 후기

발표자: 뷰어팀 김광래

Transcript

1. 코드 리뷰어 활동 후기 뷰어팀 김광래, 17.2.10
2. 저에 대하여
3. 근래에 코드 리뷰어 역할을 자주 맡게 되면서 제가 했던 / 하고 있는 고민들을 공유하고자 합니다!
4. 코드 리뷰 : 개발 결과에 대한 의견을 교환하는 과정
5. 코드 리뷰에서 확인해야할 것 - 잘 동작하는가? - ‘좋은 코드’인가? - 스타일의 일관성 - 간결 + 이해하기 쉬움 - 적절히 분리 + 유연한 구조 - 테스트하기 쉬움
6. 고민 1 : 좋은 도구? GitLab - Upsource - GitHub
7. Upsource -빠름 -특정 commit 제외 가능 -Comment 완료 처리 가능 https://d3nmt5vlzunoa1.cloudfront.net/wp-content/uploads/2013/09/image_thumb2.png
8. GitHub -Issue / review의 관리 및 연계가 쉬움 -Commit 선택에 제약↑ -다소 느림
9. GitLab -GitHub과 유사 -매우 느림 -Comment가 많으면 오류 발생 https://i.ytimg.com/vi/aWFMxYT7n6Y/maxresdefault.jpg
10. 고민 2 : 좋은 Process? 좋은 결과 + 빠른 진행 속도
11. Remind : 코드 리뷰에서 확인해야할 것 - 잘 동작하는가? - ‘좋은 코드’인가? - 스타일의 일관성 - 간결 + 이해하기 쉬움 - 적절히 분리 + 유연한 구조 - 테스트하기 쉬움
12. 무엇을 하는 코드인지 파악하기 https://www.entropywins.wtf/blog/wp-content/uploads/2014/04/cr.png
13. 잘 동작하는지 확인하기 – 좋았던 점 - 리뷰 전 Task 파악에 유용 - 오류 Double check 가능 - “버그로 인한 코드 변경  리뷰 시간 증가” 예방
14. 잘 동작하는지 확인하기 – 시행착오 오류를 발견했을 때 … - 공유 시점 - 공유 대상 - 공유 수단 : 구두 / Slack / Asana
15. 잘 동작하는지 확인하기 – 문제점 - 코드 리뷰에 속하는 부분인지? - Test 자동화로 생략 가능한 부분이 아닌지? - 디자인 확인 시에 체크해야 할 부분이 아닌지?
16. 좋은 코드인지 확인하기 큰 변화를 가져올 수 있는 부분부터 - 전체적인 구조  디테일한 부분 - 리뷰의 부담을 줄이기 위해 http://m.memegen.com/ud0t0y.jpg
17. 좋은 코드인지 확인하기 - 아직 다뤄보지 못한 부분을 리뷰할 때 - 더 좋은 구조 / 구현에 대한 고민이 있을 때  더 많은 질문 + 의견 교환
18. 최대한 자동화하기 정량적인 체크 자동화  리뷰 부담 감소 - Lint : 코드 스타일 확인, 잠재적 오류 검사 - CI : 빌드 성공 / Test, Lint 통과 여부 확인
19. 리뷰 중 코드 변경에 대처하기 This page was outdated… click here to refresh…  리뷰 범위 기억하기
20. - 해당 feature와는 연관성이 적지만 중요한 문제 - 리뷰 시 발견한 문제가 다른 부분에도 있는 경우  별도 Issue / Task 분리 리뷰 범위 밖의 문제를 발견한 경우
21. 여전히 고민 중인 부분
22. 리뷰 분량 문제 - 양이 많은 경우 너무 오랜 시간이 걸림 - 프로젝트를 작게 분리  디자인 확인 + 리뷰 반복 - 디자인 확인 일정도 같이 변경되어야  !
23. 어디까지 Comment를 남겨야 하는지 - 작성자의 의도 : ? - 작성자의 취향 : ? - 관련 History : ?  궁금하면 물어보기 https://i.stack.imgur.com/dLTF8.png
24. 좋은 의사 표현 방식은 무엇인지 - 상대가 쉽게 이해할 수 있는 표현 - 글 vs 말 - 스크린샷 첨부 기능 등 이용 - 상대의 감정을 상하지 않게 하는 표현
25. 감사합니다!