Gerrit code review guideline @ squarelab
- 1. Code Review S01 Jaewon.Baek @ SquareLab
- 2. 시작전에.. 이 세미나를 듣는다고 당장 이해가 되지는 않을것 같음 대부분 사람들이 리뷰 통해 체득하는 것들을 글로 정리해보려고 노력함 모든 팀이 다 같을 순 없지만 앞으로 서로 같이 일하게 될 것을 감안하여 많은 질문을 하고 이해하고 마침내 같은 생각을 가지길 바랍니다 lol
- 3. Code Review? 1. Git-Flow: branch, pull request and merge (저는 이거 안해봄 ^^;) a. Issue or Feature based b. Feature 단위로 진행할 경우 리뷰에 큰 부담 -> 무의미한 리뷰 혹은 리뷰를 주고 받는데 대한 부담 2. Gerrit a. 턴방식의 pair programming 같은 느낌..? b. Review (CL) / Reviewer, CC c. Comment, Done / PatchSet d. +1 / +2 LGTM e. Commit 단위로 리뷰 하는 장점 i. 리뷰에 따라 해야할 삽질의 시간이 짧은 편 f. CL 을 잘 나눠야 하는 이유 i. 리뷰의 편의성 => 좋은 리뷰
- 4. Goals 1. 코딩을 잘 하는 한 사람이 짠 것 같은 코드. 프로젝트. 프로덕트. 팀. 회사. 2. Naming: 이해하기 쉬울 것 3. Pattern: 같은 상황에서 항상 같은 패턴으로 짜여진 코드 a. 아름다운 코드는 있어야 할 것 같은게 있어야할것 같은 위치에 있는 코드 b. e.g. CRUD, RESTful, Platform (iOS, Android)
- 5. Advantage 1. 가독성 a. 한 패턴에 적응하면 대부분의 코드를 쉽고 빠르게 이해할 수 있음 2. 빠른 기술 전파 3. 리뷰이의 성장 ~ 리뷰어의 성장 a. 코드 리뷰를 통해 리뷰 받는 팀원은 빠르게 성장하게 됩니다 b. 그리고 그 팀원은 리뷰어의 코드나 다른 사람의 리뷰어가 되어 리뷰어의 책임을 덜어주고 4. 한 코드에 대해 여러명이 ownership을 가짐으로써 개인의 책임을 줄어듬
- 6. Disadvantage 1. 개발 기간.. 개발 기간… 개발 기간…. 2. 스트레스………….. 3. 포기: 내가 어떻게 코드를 짜던 리뷰어가 알아서 다 해주겠지.. 4. 개발완료 != 리뷰완료 a. 리뷰이는 처음에 버그 없이 돌아가는 코드를 작성했으나 리뷰 기간이.. b. 리뷰어는 당신의 개발 일정을 책임져주지 않음 5. 리뷰를 통과했다고 버그 없는코드라는 착각 a. 리뷰어는 당신만큼 당신의 이슈를 잘 알지 못함 b. 리뷰어는 테스터가 아님 (보통 실제로 안돌려봄) c. 리뷰어는 내가 아님. 당신의 마음이나 의도를 모름. d. 리뷰어는 신이 아님. 다 알지는 못함. e. 결론은 내가 잘 짜야함.
- 7. DO 1. 리뷰하기 좋은 사이즈의 CL a. 리뷰어는 diff 기준으로 리뷰를 진행함 b. delta 200 i. 제외 1. UI code (XML, xib) 2. Test code 제외 3. other resources 2. Commit message (commit message guideline) a. CL이 하고자 하는 일의 의도를 명확히 알려줄 것 b. 이슈번호 혹은 제플린 화면 등의 링크가 들어가도 좋음 (*제플린 링크는 자주 사라짐) 3. Topic a. git review 할때 local branch name으로 topic이 생성됨 b. 한 이슈 혹은 한 피쳐에 대한 커밋을 모아보기 좋음
- 8. DO~ 1. 친절할 것.. a. 코드리뷰 과정은 스트레스가 심하므로 말투로 자극하지는 말것. 사실과 기술적인 내용을 중심으로 대화 2. 질문할 것 a. 다만 질문 전에 리뷰어의 의도를 이해하려고 노력하거나 검색해보거나 하는 정도는 필요함
- 9. DO~~ 1. CL은 그 자체로 완벽하게 a. 해당 CL이 merge 되어도 당장 출시에 문제가 없도록. b. branch 를 사용하지 않는 gerrit 특성 탓도 있음 c. 개발중인 기능은 debug flag guarding 같은걸로 숨김 d. 이 CL이 들어가면 어떤 기능에 문제가 생겨요. X e. 질문 받습니다~ 2. review 올리기 전에 smoke에 준하는 테스트 필요 a. lint, unit test 3. review 올리고 리뷰어 지정전에 self review a. 아주 중요. 자신의 코드를 다시 읽고 문제가 있는지 파악하는 능력 4. 어쩔수 없이 코드 자체로 이해가 힘든 부분은 Note 추가 a. e.g. 외부 라이브러리의 문제나 비즈니스 로직의 문제로 만족스럽지 못한 코드를 작성할때.. b. 나중에 본 사람이 왜 이 사람은 이렇게 짰을까? 하고 수정해서 다시 문제가 생기지 않도록..
- 10. Client 개발자의 CL 나누기 1. Skeleton code a. UI code (XML, XIB 등) b. Empty class, empty functions, and variables c. 여기서 naming 으로 의도를 짐작하고 앞으로 진행될것에 대해 리뷰함 (설계에 대한 리뷰?) 2. Implement data flows without UI a. Unit test b. 의미단위로 나누기 쉬움 c. 사이즈가 커지면 몇개의 CL로 나눠서 3. UI Implement a. Unit test b. 의미단위로 나누기 쉬움 c. 사이즈가 커지면 몇개의 CL로 나눠서 4. TODO를 활용하여 CL 사이즈는 줄이면서 리뷰어에게 의도는 전달하는 방법 추천
- 11. DO NOT 1. Big Size… a. 리뷰에 대한 부담이 커짐으로 리뷰의 질이 떨어짐 b. 리뷰어의 comment 하나에 CL을 다 갈아엎는 상황이 발생할 수 있음 2. Refactoring, rename, new feature, bug fix 등을 한 CL에서 하지 말것 a. 리뷰어가 diff base로 리뷰를 하는지라 한 CL에 여러가지 목적이 섞여있으면 리뷰 난이도가 올라가고 이는 곧 버그 발생 가능성이 높아짐을 의미. b. 보통 한 이슈에서 위 상황이 동시에 발생 하면 아래와 같은 순서로 CL을 나눠서 진행 (그때그때 다름) i. rename: rename과 다른게 동시에 들어가면 delete-new file로 인식될때가 있으므로 먼저 진행 1. 히스토리가 끊어짐을 방지 ii. bug fix: 보통 간단한 delta로 해결될 가능성이 높으므로.. iii. new feature VS refactoring 1. 리팩토링 없이 기능추가가 가능하면 먼저 진행 2. 그게 안되면 리팩토링을 먼저 진행하며 기능 추가 할 곳에 TODO
- 12. DO NOT~ 1. 코드의 위치를 이동하지 말것 a. diff로 보면 쉬울 리뷰가 어려워짐. b. 히스토리 쫓아가기 힘듬!! c. 아주 간절히 필요할때만 리뷰가 끝난 뒤 서밋 전 마지막에 이동 2. Refactoring을 위한 refactoring을 하지 말것 a. 혼자하는게 아니라 리뷰어의 리소스까지 소모하는것을 기억 b. 보통 우리 프로세스에서는 리팩토링은 해당 부분을 수정할 일이 있을때 리뷰어와 사전에 협의하여 진행 3. 주석처리된 코드를 넣지 말것
- 13. Tips - 업무 시간에 자신의 개발은 6 리뷰는 4 정도로 조정 - 자신에게 할당된 리뷰는 24시간 내에 리뷰하고 merge 까지 48시간내에 하는걸 추천함 - 이게 되나요..? - Reviewer가 여러명인 경우 assignee 지정을 활용하여 +2 줄 사람을 지목하는 방법 - Reviewer가 여러명인 경우 먼저 리뷰하는 사람은 +1을 주고 마지막에 리뷰하는 사람이 +2 를 주는 방법 - CC도 리뷰해도 됨
- 15. Code Review S02 in SquareLab
- 16. 다른 팀원의 코드를 리뷰하기 !! 하루 업무 시작과 종료시 Assigned Reviews와 Incoming Reviews의 순서로 처리 Assigned Reviews Incoming Reviews Outgoing Reviews CCed On
- 17. to be continue..