'플리토 모바일팀의 코드리뷰 & IDE로 Intelligent 리팩토링' 사내세미나 발표자료입니다.

1. CODE
REVIEW

2. 눈치 보는 나, 오해하는 당신

3. Yongjun Kim
TeamA(pp)
kevin@flitto.com

4. 켄트백 구현패턴 中

5. HOW

6. +

7. feature/<new_feature_name>
bugfix/<new_issue_name>
bugfix/<JIRA issue number>

8. masterdevelopbugfix branchesfeature branches
tag/v2.4.1
tag/v2.4.0
tag/v2.5.0

9. 작업 마무리 되면 <develop> 으로 Pull Request

10. Who is Reviewer?

11. Android Developer 도 iOS 리뷰하자
iOS Developer 도 Android 리뷰하자

12. 작업 로그를 잘 남겨두자단,
Dev.Log

13. Code convention
Commit Msg format
Dev.Log
Not Only for Code Review, just for Team

14. 한번씩은 해보자.
주별로 Review Master

15. 라인 단위 @리뷰

16. 만약 리뷰(댓글)가 있을 경우,
리뷰에 대한 피드백을 한다

17. 리뷰가 끝나면
최종 확인 메시지를 남긴다

18. はやく한 작업이 아니라면
리뷰요청 진행작업

19. 그 날 받은 PR은 그 날 리뷰하자
Do Not
귀찮아

20. Release
Pull Request
Merge
<master>
<develop>
TAG
QA

22. 이 아닌….

24. 오타
예외 처리 (exception, null point)
라이브러리 추천
코드 제안 (로직 제안)
Q&A
컨벤션(네이밍, 괄호, 들여쓰기, 주석)

25. 컨벤션(네이밍, 괄호, 들여쓰기, 주석)
발생빈도는 초기에는 높으나
초기 한달 정도는 좋음. PR 과정을 여러번 하다보면 저절로 없어짐, 컨벤션 확인을
자동화필요
컨벤션, 오타 찾기는 부가적
중요도는 낮아야 함

26. !앗

27. 비난하기 위한 리뷰가 아닌
코드 품질을 위한 리뷰를 하자

28. git stash
git stash list
git stash pop
작업중 발생한 다른 이슈는
같은 브랜치에 포함하지 않음

29. conflict으로 인한 auto-
merging이 되지 않는 경우

30. 아직까지는 Push를 막지 않음
긴급 배포 git blame(비난) 받지 않을
만큼 테스트 후 바로 Push하거나 주위의
동료에게 코드리뷰를 요청

31. 만약 2명이상 작업을 하거나 작업이 큰 경우
?
developfeature branches
feature/A
feature/A1feature/A2
PR

32. developfeature branches
feature/b2b
feature/b2b_dev
Pull
Pull Request
Yesterday

33. developfeature branches
feature/b2b
feature/b2b_dev
Pull Request
Pull
Yesterday

34. !아~

35. 장점

36. 코드를 읽게 되고 그를 통해 배움
로직, 예외 처리에 대한 리뷰와 논의로 프로젝트가 안정화
소수 인원의 온라인 리뷰로 인한 시간 절약
나보다 뛰어난 엔지니어의 리뷰로 인한 실력의 향상
코드리뷰를 통한 코드 품질 향상
변경이 용이한, 테스트 코드가 잘 동작하도록 미리 설계

37. 단점

38. 자주 하나의 PR에 많은 양의 코드 리뷰
가끔 iOS 로직을 모른다라는 핑계로 리뷰 집중력 저하
잦은 Pull Request로 리뷰 시간이 많이 소모됨
온라인 리뷰의 한계를 지님 (가끔 오프라인 리뷰도 필요)
시니어는 배움에 대한 한계

39. 어떤 자세가 필요한가?

40. Reviewee
commit 하기 전에 리팩토링이나 재확인
commit 단위를 잘 나누어 Pull Request
리뷰가 필요한지 안한지 잘 판단하는 것이 중요
리뷰에 대한 본인의 의도를 리뷰어에게 잘 설명함

41. Reviewer
꼼꼼하게 되도록 라인단위의 리뷰
피드백이 마음에 들지 않는다면 추후에 직접 수정
서로간에 분쟁이 생길경우 리뷰이가 판단하도록 믿김
코드 품질보다 팀워크가 중요

42. Flittoolcon

43. commit 하기 전
IDE로 리팩토링 쉽게하기

44. TDD Add
TestCase
Test Fail
Write
Code
Run
Test
Refactor
REPEAT

45. TDD
Pair Programming
+
= Good

47. Intelligent 한 Tool을 쓰니까
Intelligent 를 느껴봐야죠

48. 자주 쓰는 간단한 shortcuts

49. 어르신에게 친절하게 greet()
하지만 누군가는 move()
간단하게 믿고 따라하는 예제 hometown.js

50. Github Refactoring Sample
https://github.com/kimkevin/refactoring_sample

51. 시연

52. Cmd + F6 : Rename
Cmd + Opt + N : Inline
Cmd + Opt + M : Extract Method
Cmd + Opt + V : Extract Variable
[추가]

53. Cmd + F6 : Rename
[추가]

54. Cmd + Opt + N : Inline… (Function & Variable)
[추가]

55. Cmd + Opt + M : Extract Method
[추가]

56. Cmd + Opt + V : Extract Variable
[추가]

57. Q&A

58. 감사합니다
Thank you
ありがとうございます
Se lo agradezco
Terima kasih