이 글은 This Is My 10 Questions React Code Reviewing Routine 를 작성자인 Chak Shun Yu 의 동의를 받고 작성되었습니다. 글의 재미를 위해 적절한 의역이 있지만, 만약 오역이 있다면 댓글로 알려주세요.

원글은 Merge Request(MR)라고하지만, 이 글에서 핵심이 아니기 때문에 전통적인 표현인 PR을 사용합니다

이 글을 쓰는 이유

어떤 개발자인지에 상관없이 코드리뷰는 엔지니어링 팀에서 일할 때 일상적인 책임의 일부가 되었습니다. React 개발자도 예외는 아니죠. 더 나은 React 코드를 작성하는 방법을 알려주는 글은 많지만, React 코드 리뷰를 잘하는데 데 도움이 되는 블로그, 비디오 또는 자습서는 거의 없습니다.

물론 동료의 코드를 리뷰하는 것은 개발자로서의 우리 책임의 중요한 부분이지만, 많은 개발자가 기대하는 책임은 아닙니다. 그들은 코드를 작성하는 대신 읽는 것이 지루하다고 느끼고, 자신의 리뷰가 의미가 없으며, 그저 리뷰어로서 머리수를 채우는 것일 뿐이라고 생각합니다.

개인적으로 저는 PR마다 같은 의견을 리뷰하곤 했고 코드 리뷰를 별로 좋아하지 않았습니다. 그러나 이 주제에 대해 많은 시간을 보내고 React 개발자로서 다양한 측면을 살펴본 결과, 개발에서 발생하는 문제가 React 코드를 제대로 리뷰하는 방법을 몰라서 발생했다는 사실로 귀결된다는 사실을 알게 되었습니다.

원래 제 루틴은 PR을 열고 생각 없이 모든 코드를 위에서 아래로 읽고 제가 발견한 모든 항목에 대해 코멘트를 추가하는 것이었습니다. 당연히 이 과정은 재미없었고 제 리뷰의 품질은 자연스럽게 별로 좋지 않았습니다.

요즘 저는 항상 계획과 주제를 염두에 두고 React 코드를 검토합니다. 이 일을 시작한 이후로 리뷰가 지루하지 않았고 시간이 지날수록 리뷰의 질이 높아졌다고 동료들에게 피드백을 받았습니다.

저는 이제 동료들의 코드를 검토하는 것을 정말 즐깁니다. 그들의 코드를 검토함으로써 그들의 코딩 스타일에 대해 배우고, 코드를 이해하고, 코드에 대해 질문하고, 새로운 것을 배울 수 있습니다. 궁극적으로는 코드 품질을 향상시키기 위해 작업에 대한 더 좋은 다른 방법을 제공 할수도 있고요.

이 글은 제가 React 코드를 검토하는 동안 스스로에게 묻는 모든 질문을 공유합니다. React 코드를 검토하는 방법을 잘 모르거나 무엇에 중점을 둬야 할지 모르겠다면 이 질문들이 시작하는 데 도움이 될 것입니다. 이것들을 기초로 제가 했던 것처럼 검토 체크리스트를 만들고, 의식적인 프로세스를 리뷰하기 시작하고, 팀에 더 의미 있는 리뷰를 제공할수 있고, 어쩌면 리뷰를 즐기기 시작할 수도 있습니다. 🙂

1. 이 코드가 동작하나?

리뷰에서 가장 중요한건 역시 코드가 작동하는지 확인하는 것입니다. 이건 코드 자체에서 쉽게 확인할 수 는 없지만 그래서 대부분 CI에 의존하거나 로컬에서 직접 코드를 확인하죠. 또한 PR까지 올라온 거라면.. 여러분은 당연히 동작할거라고 믿을 거고요 ^^;

그러나 그 모든 것에도 불구하고 코드를 읽을 때 코드 동작할지 의심하는 것은 좋은 자세입니다. 최악이라고 해봤자 여러분은 코드를 더 잘 이해할 수 있게 되고, 최선의 시나리오는 코드 제안자가 놓치고 있던, 어쩌면 품질을 개선하는 데 도움이 될 수 있는 몇 가지 디테일을 알 수 있게 될테니까요.

2. PR이 무엇을 위한 것인지 이해하고 있나?

종종 리뷰어는 PR을 볼때 자기가 Linter나 다른 정적 분석 도구인 것처럼 검토합니다. 그들은 코드 구현에만 주의를 기울이고 모든 것이 제대로 구현되었는지 확인하죠. 하지만 문제는 정적 분석 도구가 동일한 작업을 더 빠르고 효율적이며 안정적으로 수행할 수 있다는 것입니다. 코드 디테일에 주의를 기울이는 것은 좋지만, 코드가 실제로 무엇을 하기위한 것인지 이해하는것이 포인트가 되어야 합니다.

PR에서는 정적 분석 도구도 할수있는 일보다는 코드 제안자와 함께 생각하는게 중요합니다. 더 의미 있는 피드백을 제공하기 위한 것이든, 향후 작업을 예상하기 위한 것이든, 먼저 무슨 일이 일어나고 있는지 이해해야 합니다. 그러나 그렇게 하려면 먼저 PR에서 무슨 일이 일어나고 있는지 이해해야 합니다. 여기에는 맥락, 목적 및 구현과 같은 모든 것이 포함됩니다.

3. 코드가 가독성있나?

우리는 작동하는 코드에 만족해서는 안 됩니다. 작동되는 코드는 최소한의 요구 사항이어야 하지 결정적인 요소가 되어서는 안됩니다. 우리는 결국 코드베이스에 병합되어 사용자에게 배포되는 코드를 유지 관리하는 것입니다. 그러나 코드 자체와 달리 코드를 만든 개발자는 영원히 함께 작업할 수 없습니다. 제작자 자신조차도 몇 달 후에 자신의 코드를 이해하는 데 어려움을 겪을 가능성이 큽니다.

이러한 이유로 읽기 좋은 코드를 갖는 것은 중요합니다. 더 읽기 쉬운 코드가 있다는 것은 다른 개발자가 코드를 이해하고 향후 유지 보수 관련 작업을 더 쉽게 수행할 수 있다는 것을 의미합니다. 구체적인 예로는 콘텐츠 상태, 인라인 조건부 렌더링, 커스텀 훅뿐 아니라 코드를 배치할 위치, 구성, 변수 및 함수의 이름 등이 있습니다.

그러나 가독성은 특정 코드 패턴이나 주제에만 국한되지 않습니다. 개발자가 코드를 이해하기가 얼마나 쉬운지에 관한 것입니다. 결국 가독성은 PR에서 주요한 요소이고, 이는 엔지니어링 팀의 장기적인 투자가 필요합니다.

4. 컴포넌트나 훅이 너무 크진 않나?

소프트웨어 개발의 고전적인 안티 패턴은 소위 God Object 입니다.(역자. 뭐든 알아서 해주는 객체). 이것은 모든 책임을 저장하는 object, class 또는 function와 같은 모든 프로그래밍 요소를 나타냅니다. God Object는 너무 많이 알고 너무 많이 하며 너무 많은 맥락을 포함합니다. 결과는 유지 관리, 이해, 리팩토링, 작업이 어렵고 매우 취약한 괴물이 되어버리고 말죠.

God Object 말고도 우리는 React 개발에서 피해야 할것이 몇가지 더 있습니다. 특히 재사용성, 확장성, 단일 책임원칙같은 것들입니다. React 컴포넌트와 훅을 보며 그 목적을 이해하고, 너무 많은 일을 하고 있는지 확인하세요. 만약 이런 문제가 있다면 코드 품질이 떨어지게 하지 않기 위해 컴포넌트나 훅으로 분리하고 추상화하여 이 문제를 해결하는 것이 좋습니다.

5. 컴포넌트나 훅이어야 하나?

4번처럼 충분히 추상화하지 않아 잠재적으로 God Object 훅이 만들어질 수 있는 반면, 너무 많은 추상화는 꼭 좋지많은 않습니다. 모든 것을 구성 요소나 훅으로 만드는 것은 궁극적으로 React 코드 품질을 저하시킬 수도 있습니다.

레이어를 여러개로 분리하면 Prop Drilling이나 React의 안티 패턴을 방지할 수 있습니다. 모든 로직을 담는 커스텀 훅은 너무 많은 추상화가 발생하여 코드베이스가 체계화되지 않고 어수선하게 될 수 있거든요.

이를 염두에 두고 그 구성이 필요한지 여부를 끊임없이 자문하면 실제로 코드를 건드리지 않고도 코드 아키텍처에 기여할 수 있게 되겠죠?

6. 이 API 디자인을 단순화할 수 있나?

함수 매개변수든, React 컴포넌트의 Props든, 커스텀 훅 매개변수든 이를 구현하는 것은 쉬운 일이 아닙니다. 결국 API 디자인의 한 형태입니다. 특히 React props를 사용하면 복잡하고 중복되는 API가 양산되기 만들기 쉽습니다.

비슷한 UI를 가진 두 개의 컴포넌트가 boolean props을 가졌다면 enumeration props를 고려하는 것이 더 나을 수 있습니다. 항상 함께 사용하는 두 개의 props가 있다면 하나로 결합하는 것이 더 나을 테니까요. enumeration 또는 boolean prop가 특정 분기에만 관련이 있다면, 컴포넌트를 분할하는 것이 좋습니다. 각 컴포넌트가 배열 및 렌더함수를 전달만 하는 경우 렌더 props 패턴을 고려하는 것이 더 나을 수 있습니다.혹은 prop drilling을 많이 하는 경우 컴포넌트 합성 패턴을 고려해 볼 가치가 있습니다.

위 사항은 React props의 API 디자인을 고려할 때 제안할 수 있는 구체적인 예입니다. 그러나 일반적으로 이러한 특정 예제나 props에만 국한되지 않고 유틸리티 함수 및 커스텀 훅에도 적용될 수 있습니다. 가장 중요한 것은 이를 염두에 두고 코드 제안자의 API 설계를 이해하고 그에 따라 피드백을 제공하는 것입니다.

7. 테스트가 있나?

리뷰할 때 테스트를 고려하라는 것이 무슨 의미일까요? 테스트 코드는 늘 있어야 한다고 모두들 생각하지만 실전 리뷰에서 테스트가 얼마나 자주 잊혀지고 무시되는지 알기에 이에 실망하죠. 하지만 새로운 기능, 수정 사항 또는 일반적으로 코드가 테스트되었는지 확인하는 것은 엔지니어링 팀에 장기적으로 엄청난 도움이 될 것입니다.

여기에는 새 코드에 대한 새 테스트 작성뿐만 아니라 이미 있던 이전 테스트 수정도 포함됩니다. 일반적으로 PR은 그 목적과 추가되는 코드를 마치 문서처럼 볼수있도록 테스트를 하나 이상 갖는 것이 최소 요구 사항이어야 합니다. 그렇지 않은 경우 팀이 이를 처리하는 방식에 따라 Request Change가 필요할수 있겠죠.

8. 테스트가 의미있나?

어떤 사람들은 Test가 있는게 없는 것보다 낫다고 주장하지만 저는 그 의견에 전적으로 동의하지 않습니다. 일반적으로 Test는 코드베이스의 코드 품질을 보장하는 첫 번째 단계일 수 있지만 단순히 PR을 넘기기 위한 기만적인 단계일 수도 있습니다. 잘못된 테스트는 잘못된 보안 감각, 실제로 작동하지 않는 배포 코드, 시간과 노력 낭비로 이어질 수 있습니다.

코드 제안자가 테스트를 포함했다면 그들이 설정, 트리거 및 검증같은 필수로 해야 할 일을 하고 있는지 확인하세요. 구현 세부 정보에만 의존적이진 않은지, 설정은 맞는지, 적절한 상태관리가 되고있는지. 다른 모든 부분은 매우 다르게 구현할 수 있지만 아주 작은 변경이라도 테스트의 신뢰성에는 상당한 영향을 미칩니다.

9. 이 기능의 접근성 면은 어떻게 되어있나?

웹 개발의 필수적인 부분은 모든 유형의 사용자가 애플리케이션에 액세스할 수 있어야 한다는 것입니다. 불행히도 모든 웹 응용 프로그램이 Screen Reader, 키보드를 사용한 제어 또는 기타 그룹에 최적화된 것은 아닙니다.

어떤 개발자도 존재하는 모든 기능에 대해 적절한 접근성을 구현하는 방법을 알지 못할 것입니다. 그렇다면 당신이 할일은 명백합니다. 검토자로서 이 주제를 인지하는 사람이 되어 제안자가 접근성을 구현하는 것을 잊었다면 상기시키거나 리소스를 제공하거나 필요한 경우 먼저 코드 제안을 하면 됩니다.

10. 해당 문서를 최신화 했나?

기존 코드를 리팩토링하거나 변경할 때 가장 자주 잊어버리는 것은 문서화입니다. 코드 주석, 문서 또는 README이든, 그것들이 최신 상태라고 가정하는 것은 항상 위험한 행동입니다.

업데이트해야 하는 공식 문서, 문서 페이지 또는 주석이 있다는 것을 알고 있다면 리뷰에서 확실히 말해주세요. 특히 코드 제안자가 코드베이스의 특정 부분에서 정상적으로 작동하지 않을 때 기존 문서의 모든 부분을 아는 것은 거의 불가능합니다. 문서를 최신 상태로 유지하는 것은 당신을 포함한 팀의 노력이 있어야 합니다.

그리고 코드리뷰에 대한 나의 생각

동료들의 코드를 리뷰할때 중요한 건 무엇에 집중해야 하는지 알고 이를 의식적인 프로세스로 만드는 것입니다. 불행하게도, 많은 개발자들은 이렇게 하지 않아 검토가 지루하고 싫증나며 의미없다고 느낄 수 있습니다.

하지만, 실제로 코드 리뷰는 그런 느낌이 들지 않게 할수 있을 뿐더러 팀의 코드 품질을 올릴 수 있는 효과적인 방법입니다. 이걸 돕기위해 여기서는 당신이 React 코드 리뷰를 하며 스스로 질문해야할 10가지 질문을 제시합니다. 이 질문들은 당신이 집중해야할 주제를 깨닫고 리뷰 루틴을 만드는데 도움을 주고, 당신의 리뷰 품질을 강화시키는데 도움을 줄것입니다.

역자의 변

실제로 여기있는 10가지 질문은 평소에 지나쳤던 사소하지만 중요한 내용에 대해서 다루고 있습니다. 어쩌면 애써 무시하려고 했던 저의 모습이 떠올라서인지 뜨끔하면서 읽게 되기도 했는데요. 저 또한 이런 질문들을 보고 공감했으며, 더 많은 개발자 분들이 보고 한국 Frontend 생태계가 나아졌으면 해서 이 글을 번역하게 되었습니다.

이 글을 읽는다고 10가지 질문을 모든 PR 에서 할수는 없겠지만, 계속해서 의식하고 리뷰하는 문화를 만들어가다보면 더 나은 개발자가 될수 있겠죠 ?

끝까지 읽어주셔서 감사합니다.