코드 리뷰

코드 리뷰란, 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검(examining)하고, 피드백을 주는 과정을 말한다.

여기에서 피드백이란 오타, 버그 가능성, 개발 표준 등에 대한 의견이 될 수도 있고, 좋은 코드에 대한 긍정적인 피드백이 될 수도 있다. 코드 리뷰의 핵심은 단순히 코딩 스타일을 일관되게 유지하거나, 예상되는 문제를 일찍 파악하는 데에 그치지 않고 코드에 대한 책임이 그 코드를 만든 사람 혼자에게 있지 않고 우리 모두에게 있다는 문화를 만드는 데에 있다고 할 수 있다.

우리 팀의 코드에 관하여

- 컨벤션

코드를 작성할 때 가장 우선 시 되는 것이 팀 컨벤션인데 우리 팀 같은 경우에는 크게 컨벤션을 통일하지 않았다. mock 데이터의 경우에도 개인의 파일을 만들어 사용하였고 클래스 명 컨벤션도 파스칼 케이스, 카멜 케이스, 하이픈 케이스 등으로 다양했다. 그러나 팀 전체의 이해도를 높이는 것이 중요하기 때문에 이러한 컨벤션도 맞춰주는 게 좋다고 한다.

- 공통 파일

기존에 팀에서 상의되지 않은 부분이 라이브러리와 같은 공통으로 사용하는 곳에 도입되었을 때는 예기치 못한 충돌이나 오류가 발생할 수 있으므로 만약에 도입했을 경우 팀에게 꼭 알려줘야 한다.

- 리렌더가 일어나지 않는 경우

레퍼런스를 확인해야 한다. 레퍼런스끼리는 주소값으로 확인하므로 동일한 레퍼런스가 되는 경우가 있다. 이럴 경우에는 렌더가 한 번 밖에 일어나지 않으므로 새 레퍼런스를 만들어줘야 한다.

- 디테일 페이지

디테일 페이지에서도 mock 데이터를 사용하여 사진이나 설명, 제품 영양 정보 등을 바꿔주는 작업을 해주면 백엔드 작업 시 유리하다고 한다.

- 구조 분해 할당

기존에는 모든 컴포넌트를 props를 사용해 작업했으나 구조 분해 할당을 하면 props를 지워주고 간단하게 코드를 작성할 수 있다.

- Fetch API

fetch 함수로 해당 데이터를 호출할 때 api 주소를 string 형으로 작성했는데 주소를 관리하는 컴포넌트를 따로 만들어주어 한 번에 관리할 수 있게끔 만들어주면 상수화 처리하여 외부에서 사용이 가능하다고 한다.

- 변수명

변수명은 될 수 있으면 카멜 케이스로 작성하고 팀 내에서 변수명의 케이스를 통일해주는 게 좋다. 나 같은 경우에는 그 태그의 역할을 쓰고 언더바를 쓰고 그 뒤에 부가 설명을 써주는 방식을 썼는데 한 눈에 태그가 무슨 역할을 하는지 볼 수 있어서 좋은 것 같다. 그리고 useState를 사용하고 있으니 isLike 와 같이 상태를 물어보는 식으로 작성하는 방법도 좋았다.

- 약어

리스트 페이지에서 map 함수를 사용할 때 약어를 사용했었는데 팀 전체의 이해를 위해 약어 사용을 최대한 피하고 풀어서 쓰는 것이 좋다고 한다.

- 조건문

불필요하게 조건문 작성하지 않을 것! 값을 내보낼 때는 삼항연산자를 사용해 코드의 길이를 줄여주고 로직을 내보낼 때는 if else문을 사용한다.

나의 코드에 관하여

1. 변수명

useState는 상태를 관리해주는 함수이므로 변수명을 Boolean 타입으로 선언해주면 직관적이다.

// 수정 전
[heartClick, setHeartClick] = useState(false)

// 수정 후
[isLike, setIsLike] = useState(false)

2. key값

map 함수를 사용할 때 key값에 index를 넣어주었는데 key값은 고유해야 하므로 index 대신 다른 값을 넣어줘야 한다.

3. DOM

로그인 페이지에서 비밀번호의 hide show 기능을 구현할 때 DOM을 사용했는데 리액트에서는 되도록이면 쓰지 않는 게 좋다고 한다. 대신 state를 사용하여 구현할 수 있다.

// 비밀번호 hide or show 수정 전
  const hideOrShow = e => {
    const pwDom = document.querySelector("#user-pw");
    if (pwDom.type === "password") {
      pwDom.type = "text";
      e.target.innerText = "🙈";
    } else {
      pwDom.type = "password";
      e.target.innerText = "🙉";
    }
  }
  
// 비밀번호 hide or show 수정 후
  const [pwType, setPwType] = useState("password");
  
  const hideOrShow = e => {
    if (pwType === "password") {
      pwType = "text";
      e.target.innerText = "🙈";
    } else {
      pwType = "password";
      e.target.innerText = "🙉";
    }
  }

📝 코드 리뷰 후기

소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드 리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.
- 스티브 맥코넬(Steve McConnell)

코드 리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서 전체적인 조직의 역량을 강화하는 중요한 역할을 한다는 이유를 깨달은 것 같다. 다른 사람의 코드를 보면서 좋은 점은 배우고 오류가 나는 곳은 왜 오류가 나는지 공부할 수 있었고 내 코드에 대한 피드백을 들으면서 코드를 더 잘 짜는 방법에 대해서 알 수 있어서 좋은 시간이었던 것 같다!

본격적인 프로젝트에 들어가면 지금보다 더 복잡한 코드들을 작성해야 하니 이보다 더 많은 코드 리뷰가 더 자주 이루어져야 할 것이다. 하지만 그로 인해 결국 더욱 완성도 높은 코드가 될 것이라고 생각하면 그정도의 수고는 완성 후의 쾌감으로 날려버릴 수 있을 것 같다..!