[include(틀:소프트웨어)] [목차] == 개요 == 타인이 작성한 [[코드]]를 리뷰하는 것을 말한다. [[소프트웨어]] 개발 프로젝트의 규모가 커지는 경우 한 사람의 [[프로그래머]]가 모든 코드를 [[프로그래밍]]할 수는 없다. 즉 팀웍을 하게 된다. 이러한 경우 다른 사람이 작성한 코드가 [[버그]]가 있거나 하는 경우 전체 소프트웨어의 결함으로 이어질 수 있다. 코드 리뷰는 이를 예방하는 여러 수단 중 하나로서, 코드 리뷰를 하여 버그를 조기에 발견하고 해결한다. 책 쓰는 것에 비유하자면, 저자가 자기가 쓴 책을 다시 한번 읽어보면서 내용이 매끄럽지 못하거나 오탈자가 있으면 이를 고치는 퇴고와 유사하다. 전 세계의 많은 IT 기업에서 코드 리뷰를 기본 룰로서 채택하고 있다. 구글은 작성된 모든 코드가 리뷰를 거치도록 하고 있으며, 마이크로소프트 역시 개발자들에게 실제 코드를 작성하는 시간 50%, 코드를 리뷰하는 시간 50%를 할당하도록 하고 있다. [[네카라쿠배]]로 대표되는 한국의 많은 IT기업 역시 코드리뷰를 활발히 진행하고 있다. 다만 한국 SW시장의 다수를 차지하는 [[시스템 통합|SI]] 업계에서는 여러 가지 사정으로 인해 코드 리뷰를 하지 않는 경우가 많다. 가장 단순하게는 시간 문제가 크다. 상기하였듯, 코드 리뷰 시간을 코드 작성 시간에 맞먹게 잡을 수 있을정도로 코드 리뷰에는 많은 시간과 정성이 필요하다. 물론 가독성과 성능이 떨어지는 코드가 리뷰 없이 배포되어 [[기술 부채|추후에 유지보수하는데에 더 많은 코스트가 들 수 있지만]], 당장 데드라인이 급하면 코드 리뷰 할 시간이 없는건 당연지사. 따라서, 코드 리뷰는 팀 또는 조직이 코드의 품질에 대해 신경 쓰고 있는지 여부를 알 수 있는 대표적인 수단이며, 많은 개발자들이 '개발 문화가 좋은 곳'의 요소 중 대표적으로 코드 리뷰 진행 여부를 꼽는다. == 누구의 코드를 리뷰하는가 == 당연히 타인이 작성한 코드를 리뷰하는 것이 일반적이지만, 자기가 짠 코드를 리뷰하기도 한다. 소스코드 커밋을 하기 직전에 잘못된 코드를 찾기 위해서이다. 비유하자면, 저자가 자기가 쓴 문단을 출판사에 제출하기 전에 한번 더 퇴고하는 것과 같다. == 코드 리뷰 코멘트 == 코드에서 잘못된 부분에 작은 메모지를 붙이는 것을 코드 리뷰 코멘트라고 부른다. 물론 실제 메모지는 아니고, 여러 코드리뷰 도구에서 제공하는 기능의 형태이다. 일반적으로 코드 리뷰 코멘트는 개발팀 멤버들이 모두 볼 수 있는 공개 메모이다. 따라서 코멘트가 너무 독설적이면 팀 내 분위기를 흉흉하게 만들 수 있다. == 코드 리뷰의 에티켓 == 힘들게 짠 코드를 남이 리뷰할 때의 비판은 언제나 부담스럽고 그 정도에 따라서 불쾌할 수 있다. 코드 리뷰를 한 타인이 본인보다 실력이 더 좋더라도 이러한 느낌은 피할 수 없게 된다. 다음은 코드 리뷰를 할 때의 에티켓이다. * 코드 내용만 비판하라. 코드를 짠 사람을 비판하지 말라: [[죄는 미워하되 사람은 미워하지 말라]]와 비슷하다. 예를 들어 의도치 않은 무한 루프가 있는 코드가 발견되면, "여기서 무한 루프가 발생합니다." 이렇게까지만 적자. 괜히 쓸데없이 "너무 실수를 자주 하시는 것 같습니다."라던지 "커밋을 하기 전에 자가 코드리뷰를 한번 더 해보셨으면 좋았을텐데 말입니다." 같은 오지랖을 펼치지 말자. 심지어 직속 상사라 하더라도. * 개인 취향은 코드 리뷰 대상이 아니다: 변수 이름, 함수 이름, 조건문 형태 등은 사람마다 다르게 코딩하게 된다. 프로그래머는 개인 성향이 강한 직업이 되기도 하다 보니, 더욱 이러한 특징이 나타나게 된다. 따라서 본인이 짠 코드와 타인이 짠 코드의 스타일이나 코딩 성향이 다르다 하더라도, 즉 개인 취향이 다르다 하더라도, 이를 타인에게 강요하는 것은 바람직하지 못하다. 다만, 다음은 예외적으로 코드 리뷰 대상이 된다. * 팀 내에 정해진 [[코딩 스타일]]을 거스르는 코드 * 오타나 문법에 맞지 않는 변수, 함수이름 * 가독성을 심하게 저하시키는 코드 * 이해가 잘 되지 않는 코드는 리뷰 대상이다: 내가 누군가의 코드를 잘 읽을 수 있다면, 그것은 코드 읽는 내 실력이 뛰어난 것이 아니라, 그 코드를 짠 사람의 실력이 뛰어난 것임을 잊지 말자. 이해가 잘 되지 않는 코드라면, 코멘트를 남겨서, 당사자가 코드를 알아보기 쉽게 코드를 더 개선하거나 주석 설명을 달게 유도하는 것이 좋다. 다만, 남들은 다 이해하는데 나만 이해하지 못하는 코드였다면 창피할 수 있으며, 이런 코멘트는 "전반적인 코드 퀄리티가 떨어진다" 라는 뜻으로 전해질 수 있으므로 꼼꼼하게 읽어보고 다른 팀원들에게 가볍게 물어보거나 한 뒤에, 어떤 부분이 이해를 어렵게 하는지 개략적으로 파악하여 남기자. * 필요한 코드리뷰만 하라: 코드 리뷰의 본연의 목적은, 더 나은 품질의 코드를 유지하는 것임을 잊지 말자. 코드의 품질을 올리는데 전혀 도움되지 못하는데도 불구하고, 그냥 자기가 봤을 때 고쳐야 한다고 생각된다는 이유로 불필요한 코멘트를 남기는 것은 적절하지 못하다. 특히 [[똥군기]] 잡는답시고 지나친 코드리뷰 코멘트를 남발하는 상사가 되지는 말자. 또한, 코멘트를 하나도 안 남기면 대충 봤다고 생각할까봐 억지로 수정점을 찾지 말고 "수고하셨습니다", "LGTM(Looks Good To Me)" 등의 한 마디와 함께 Approve 하는 게 좋다. == 효과 == 책을 출판하기 전에 퇴고를 해야 더 나은 책이 되듯이, 당연히 코드 리뷰 또한 버그가 더 적고 더 안정된 프로그램 개발로 이어진다. 코드 리뷰는 인사평가의 힌트가 되기도 한다. 예를 들어 어떤 팀원의 코드를 리뷰하는 것이 유난히 힘들다면, 그 팀원의 코딩 실력은 별로라고 볼 수도 있다. == 관련 문서 == == 관련 링크 == [[https://google.github.io/eng-practices/review/|Google - Code Review Developer Guide]] [[https://www.samsungsds.com/kr/insights/global_code_review.html|삼성SDS - 글로벌기업은 코드 리뷰를 어떻게 할까요?]] [[https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/|카카오 - 효과적인 코드리뷰를 위한 리뷰어의 자세]] [[https://blog.banksalad.com/tech/banksalad-code-review-culture/|뱅크샐러드 - 코드 리뷰 in 뱅크샐러드 개발 문화]] [[https://tech.kakaopay.com/post/remote-work-code-review/|카카오페이 - 재택근무 환경에서 효율적인 코드 리뷰 방법: 팀 그라운드 룰 정하기]] [[https://yozm.wishket.com/magazine/detail/1957/|요즘IT - 코드 리뷰가 개발 문화에 미치는 영향]] [[분류:프로그래밍]]