Code Review - cleancodeclass/cleancode_theory GitHub Wiki

Code Review란?
- 전통적 정의 : 소프트웨어를 실행하지 않고 소스코드 검토를 통해 잠재된 결함을 찾아내고 개선해나가면서 소프트웨어의 품질을 높이는 활동
- 최근의 코드리뷰
- Goal is cooperation, not only bug-hunting
- 코드를 통해 서로 소통하고 배움을 주고 받는 활동
- 개발완료 단계에 하는 것이 아니라 개발 중 일상적으로 수행 -"Code review is the discipline of discussing your code with your peers" Derek Prior, RailsConf 2015
The Ten Commandments of Egoless Programming(비자아적 프로그래밍을 의한 10개의 원칙)
- Understand and accept that you will make mistakes.
- You are not your code.
- No matter how much "karate" you know, someone else will always know more.
- Don't rewrite code without consultation.
- Treat people who know less than you with respect, deference, and patience.
- The only constant in the world is change.
- The only true authority stems from knowledge, not from position.
- Fight for what you believe, but gracefully accept defeat.
- Don't be "the guy in the room."
- Critique code instead of people – be kind to the coder, not to the code.
코드리뷰의 목표
- 개발진행 중에 일찍 결함을 발견하고 고치기 위해
- 팀 멤버로서 코드 베이스의 이해를 공유를 통해 서로 배움(후배 양성 및 기술 이전)
- 디자인과 구현에서 일관성의 레벨을 유지
- 재작업을 줄이는 것과 같은 흔한 결함을 확인하기 위해 도움을 줌
- 실행단계 기술적인 품질에 대한 이해관계자의 신뢰
- 팀멤버들간에 소스를 공유하여 다른 개발자의 역할 대행 가능(백업개념)
- 관점을 달리하여 동료의 리뷰를 통하여 문제를 발견하기 위한 계기가 됨
- 자부심, 보상, 코딩 기량의 인정으로 프로그래머 사기 진작
- 팀의 응집력. 팀 멤버들간 더 가까워질 수 있게 도움

codereview

코드리뷰에 임하는 자세

소스코드가 완벽하지 않다는 것을 인정하자.
Code Review를 통해 새로운 아이디어 및 습관을 배울 수 있다고 생각하자.
Code Review를 하는 가장 큰 이유는 더 나아지기 위한 방법이다.
대다수 프로그래밍에서 내려진 결정은 각각의 견해에 따른다는 사실을 받아들인다. 어느 쪽이 더 좋은지 장단점을 의논하고 빠르게 결정을 내린다.
질문한다. 대신 답을 강요하지 않는다. (“이 :user_id라는 네이밍에 대해 어떻게 생각하나요?”)
명확하게 해달라고 묻는다. (“제가 이해하지 못했어요. 다시 설명해줄 수 있어요?”)
코드의 소유권에 대해 특정하는 것을 피한다. (“내가 작성한”, “내 코드가 아닌”, “당신이 작성한”)
개인적인 특징은 언급하는 것으로 보일 수 있는 단어를 피한다. (“바보”, “멍청한”). 모든 사람이 매력적이고 똑똑하며 선의가 있는 것으로 여겨야 한다.
명시적으로 한다. 사람들은 온라인에서 당신의 속내를 항상 쉽게 이해할 수 있는 것은 아니란 점을 유념한다.
겸손해야 한다. (“확신하기 어렵다. 한번 살펴보겠다.”)
과장하지 않는다. (“항상”, “절대”, “끊임없이”, “아무것도”)
빈정대지 않는다.
실제처럼 행동해야 한다. 당신에게 해당하지 않는 이모지, 움짤 gif 또는 유머를 사용하더라도 그 사람들을 비꼬아서는 안된다. 만약 그들이 그런 행동을 한다면 침착하게 대응한다.
“이해할 수 없다” 또는 “대안:” 식의 코멘트를 너무 많이 사용한다면 대화가 필요하다. 오프라인에서 대화한 내용을 요약해 후속 코멘트로 남긴다.

내 코드를 리뷰받을 때

자신의 코드를 남이 설명할 때는 남이 늘 객관적으로 코멘트를 준다고 생각하자.
리뷰어의 추천에 감사해야 한다. (“리뷰 고맙다. 그렇게 변경하도록 하겠다.”)
개인적인 부분으로 받아들이지 않는다. 리뷰의 대상은 코드지 당신이 아니다.
왜 코드가 존재하는지 설명한다. (“이 부분을 이렇게 짠 이유는 이런 이유 때문이다. 내가 클래스/파일/메소드/함수명을 이렇게 바꾸면 더 명확해질 수 있을까?”)
변경점과 개선점을 꺼내 미래의 티켓/스토리로 둔다.
티켓/스토리에 코드 리뷰를 링크한다. (“리뷰를 위한 준비가 되었음:”)
초기 피드백을 받을 때는 독립적인 커밋으로 만들어 브랜치로 푸시한다. 브런치가 머지되기 전까지 커밋을 뭉쳐버리지 않는다. 리뷰어는 초기 피드백에 기반을 둬 작성한 각각의 업데이트를 읽는 것이 가능해야 한다.
리뷰어의 관점에서 이해하도록 노력한다.
모든 코멘트에 응답하도록 노력한다.
지속적인 통합(TDDium, TravisCI 등)이 브랜치에서 모든 테스트가 통과되기 전까지 브랜치로 머지하지 않고 기다린다.
코드를 머지하는 일은 프로젝트에 영향을 준다. 그러므로 자신의 코드에 확신이 있을 때 머지한다.

다른 사람의 코드를 리뷰할 때

오픈 마인드로 다른 사람의 코드를 보고, 개선 제안 시에는 이유를 잘 설명하자.
왜 이 코드가 필요한지 이해한다. (버그, 사용자 경험, 리팩토링.) 그러고 나서:
어느 아이디어가 강점이라 생각되는지, 혹은 그 반대인지 소통한다.
문제를 해결할 때까지 코드를 단순화하는 것으로 방향을 찾아라.
논의가 철학적이거나 학문적으로 흐를 때는 그 주제를 금요일 오후 기술 토의처럼 오프라인으로 가져와서 논의한다. 그 후 코드 작성자가 대안적인 구현으로 최종 결정을 내리도록 한다.
대안적인 구현을 제공할 때는 작성자가 이미 그 구현을 고려했을 것으로 가정한다. (“custom validator를 여기서 사용하는 것에 대해 어떻게 생각하나요?”)
작성자의 관점을 이해하도록 노력한다.
“머지 준비됨 Ready to merge”와 같은 코멘트와 함께 풀 리퀘스트를 수락한다.