Code Review 진행 시켜?!

이현석·2023년 3월 16일
0
post-thumbnail

들어가며

지난 12월 Unity 엔진으로 게임을 만들며 IT의 현재와 발전을 간략히 소개 했다.

초거대 AI 모델 GPT-3 및 메타버스 (호라이즌, 제페토) 부터 프로그래밍(분석/설계/개발/테스트)도 자동으로 해주는 모델인 Github의 Copilot 까지

  1. 이제는 모바일을 넘어 메타버스의 시대
  2. 제품 중심이 아닌 서비스 중심 시대
  3. IT는 지원 도구가 아닌 서비스 자체
  4. 개인 역량과 함께 IT 협업이 중요

이렇게 4가지 Key word를 뽑을 수 있었다.

그 중 네번째 IT 협업 관점에서 최근 고민과 Code Review를 하려는 이유를 설명하려 한다.

코드 리뷰 란?

소프트웨어 개발 과정에서 개발자들이 작성한 코드를 다른 개발자들이 검토하고 분석하는 것

코드 리뷰를 하려는 이유

SK Hynix SystemIC에 와서 가장 당혹(?)스러운 것 중 하나가 코드를 리뷰하는 문화의 부재였다. 당연히 IT 전문 업체가 아니며 파운드리(반도체 위탁생산사업) 회사로서 SI 위주의 Project 진행 과 생산/제조 우선순위의 업무 진행을 해야 하기 때문인 것 같다.

하지만 IT 기술 역량 강화와 자체 개발 인력으로 팀을 구성하는 시점에 더 좋은 문화 정착과 장기적으로 회사 그리고 개인의 발전을 위해 반드시 코드 리뷰는 반드시 필요한 활동이라고 생각 한다.

각론

코드 리뷰(Code Review)는 소프트웨어 개발에서 중요한 활동 중 하나로 코드의 품질을 향상시키고, 버그를 줄이고, 개발자들의 역량을 향상시키기 위해 수행된다. 다음은 코드 리뷰를 정말 왜 하는지에 대한 상세한 이유 이다.

코드 품질 향상: 코드 리뷰를 통해 더 나은 코드 품질을 만들 수 있습니다. 다른 개발자들이 코드를 검토하고 수정하는 것은 코드의 오류나 개선할 점을 찾아내는데 도움이 되며, 이를 통해 코드의 가독성, 유지보수성, 확장성 등을 향상시킬 수 있습니다.

버그 감소: 코드 리뷰는 버그를 줄이는데 매우 효과적입니다. 다른 개발자들이 코드를 검토하고 수정하는 것은 코드에서 발생할 수 있는 오류나 예기치 않은 상황을 사전에 예방할 수 있기 때문입니다.

개발자 역량 향상: 코드 리뷰는 개발자들의 역량 향상에 큰 역할을 합니다. 다른 개발자들이 코드를 검토하고 수정하는 것은 개발자들이 어떤 실수를 범하는지, 더 나은 방식이 있는지 등을 배울 수 있게 해주기 때문입니다.

코드 일관성 유지: 코드 리뷰는 코드 일관성을 유지하는데 매우 효과적입니다. 다른 개발자들이 코드를 검토하고 수정하는 것은 코드의 일관성을 유지하고 규칙을 준수하는 것을 도와주기 때문입니다.

팀 협업 향상: 코드 리뷰는 팀 협업을 향상시키는데 큰 역할을 합니다. 다른 개발자들이 코드를 검토하고 수정하는 것은 팀원들 간에 서로 배울 수 있는 기회를 제공하며, 코드에 대한 의견을 공유하고 토론하는 기회를 만들어줍니다.

글로벌 기업의 코드 리뷰 현황

100% 코드 리뷰, 모든 코드를 리뷰하는 Google/Gooler

Google은 코드 리뷰 개발자 가이드(https://google.github.io/eng-practices/review/)를 통해 코딩 스타일을 비롯한 주요 원칙을 공개하고 있다. Google이라면 자유롭게 코드 리뷰를 하도록 할 것 같지만, 표준과 프로세스, 정책을 엄격히 적용 중.

Microsoft의 개발자는 매일(Daily) 코드 리뷰 수행. Microsoft의 전체 직원 수는 14만 명이고, 이중 44%인 6만 명에 이르는 개발자의 75%가 매일 코드 리뷰를 하는 중.

네카라쿠배당토를 중심으로 자동화된 배포와 테스트는 기본 중의 기본이 되어 문화가 정착됨.
테스트 기반의 코딩인 TDD(Test Driven Development)를 필수로 적용하고, 코드 Merge 전에 코드 리뷰는 필수적인 프로세스가 됨. 국내 IT 선도기업들은 회사에서 표준을 제공하기보다는 팀 상황에 맞추어 자율적으로 코드 리뷰 방법을 결정해서 자율적으로 적용하고 있지만, 대부분의 회사는 GitHub에서 제공하는 PR(Pull Request)을 활용해서 리뷰 요청과 검토를 완료(Approve)하는 방식으로 코드 리뷰를 진행 중임.

<<<<코드 리뷰 기사>>>>



리뷰의 5가지 규칙

1. 왜 개선이 필요한지 이유를 충분한 설명해 주세요.

리뷰어가 코드 개선의 필요성을 느끼고 리뷰를 남긴다면 충분한 이유가 뒷받침되어야 합니다. 만약 코드 리뷰가 주관적이거나 추상적이라면 리뷰이는 혼란을 느낄 수 있습니다. 그래서 피드백을 작성할 때 리뷰이가 개선의 필요성을 느낄 수 있도록 구체적인 이유를 작성하면 좋습니다.

const data = [
  ['데이터베이스', 'A', 3],
  ['교양영어', 'B+', 1],
  ['철학', 'A', 2]
];

위 코드는 2차원 배열을 사용한 자료구조이며 학점 정보를 담고 있는 data라는 변수가 있습니다. 변수명만 봐서는 어떤 의도를 가진 변수인지 파악하기 힘들고, 데이터가 확장되거나 비슷한 자료구조가 추가될 때 문제가 야기될 수도 있습니다. 따라서 리뷰어는 구체적이고 의도를 가진 변수명으로 변경하고자 합니다.

안 좋은 리뷰
“data 변수 말고 다른 변수명으로 하세요."
“data 변수 말고 grade로 하세요.”

변경에 대한 이유를 설명하지 않고 제안도 애매하게 하는 리뷰입니다. 리뷰이 입장에서는 왜 다른 변수명으로 변경을 해야 하는지 알 방법이 없겠죠.

좋은 리뷰
“data라는 이름은 현재의 자료구조가 무엇인지 그 의도를 알기가 어렵네요.
학점 정보를 담고 있는 자료구조 같은데 이와 관련된 변수명을 짓는다면
현재 정의한 자료구조가 무엇인지 그 의도를 쉽게 파악할 수 있을 것 같아요.”
개선이 필요한 이유를 구체적으로 설명한 피드백입니다. 답을 알려주는 것이 아니라 개선의 필요성만 설명하고 있기 때문에 리뷰이는 스스로 생각하고 학습할 계기가 됩니다.

2. 답을 알려주기보다는 스스로 고민하고 개선 방법을 선택할 수 있게 해주세요.

업무와 코드 리뷰를 병행하는 건 쉽지 않은 일입니다. 업무량은 많은데 코드 리뷰까지 신경 쓰려고 하다 보니 상세히 코드를 살펴보지 못하는 경우도 생기는데요, 그럴 때 리뷰어는 “000로 변경하세요”, “000을 쓰세요”와 같이 현재 코드의 개선점을 찾아 답을 알려주는 리뷰가 늘어나기도 합니다. 이러한 리뷰가 늘어날수록 리뷰이는 주어진 리뷰의 코드만 변경할 뿐 스스로 고민하는 시간은 줄어듭니다. 답을 알려주는 리뷰가 많아질수록 코드에 대한 애정도 사라지고 수동적인 개발자가 될 수 있으므로 스스로 고민하고 개선 방법을 찾는 것이 중요합니다.

const result = [];
arr.forEach(item => {
  if(item % 2 === 0) {
    result.push(item);
  }
});

위 코드는 배열을 순회하며 짝수인 값만 result 배열에 추가하는 코드입니다. 리뷰어는 배열 내장 메서드를 통해 코드를 변경하고자 합니다.

안 좋은 리뷰
“arr.filter(item => item % 2 === 0);으로 사용하세요."
filter의 사용 코드를 알려주는 피드백입니다. 리뷰이 입장에서는 filter의 동작 방식을 제대로 이해하지 못한 채 수정하게 됩니다. 또한 비슷한 코드가 여러 군데 있음에도 불구하고 이곳만 수정할 수도 있습니다.

좋은 리뷰
“자바스크립트에는 배열에는 다양한 내장 메서드들이 존재합니다.
그중 filter 메서드를 활용해 보세요.
이 메서드를 활용하면 코드량을 줄일 수 있습니다.”
답을 알려주기보단 키워드(filter)를 알려줌으로써 어떤 식으로 검색해야 하는지 방법을 제시하고 있는 피드백입니다. 리뷰이 입장에서는 동작 방식을 찾아보고 스스로 학습할 기회가 생기고 비슷한 코드를 리팩토링할 수도 있습니다.

3. 코드를 클린 하게 유지하고, 일관되게 구현하도록 안내해 주세요.

‘클린 코드’는 개발자라면 한 번쯤 고민해 봤을 만한 주제입니다. 코드의 품질을 높이기 위해 개발자들은 항상 깨끗하게 코드를 유지하려고 노력을 많이 하는데요. 코드 가독성이 높아지고 일의 생산성도 향상되기 때문에 코드 리뷰를 할 때도 코드를 깨끗하게 유지하는 방법을 고민하는 것은 중요합니다. 클린 코드를 작성하는 방법은 다양하지만, 이번 글에서는 일관성 있게 코드를 작성하기 위해 리뷰어가 코드 리뷰를 할 때 어떤 시각으로 봐야 하는지 알아보도록 하겠습니다.

const checkNumber = (comNum, myNum) => {
  return myNum.reduce((prev, curr) => {
    if (comNum[curr]) return prev + 1;
    return prev;
  }, 0);
}
function calculateEarningRate(list, totalPrizeMoney, investMoney) {
  const result = [];
  for(let i=0; i < list.length; i += 1) {
    result.push((list[i] / investMoney) * 100);
  }
  return result;
}

두 가지 함수가 있고 같은 애플리케이션에서 동작합니다.
먼저 함수 선언 방식이 일관되지 않습니다. 아무 의미 없이 함수 표현식과 함수 선언식을 사용하고 있습니다. 그리고 두 함수의 자료구조 반복문 방식이 일관되지 않습니다. checkNumber 반복문은 reduce를 사용했고 calculateEarningRate 반복문은 for문을 사용하였습니다. 리뷰어는 이 두 가지 상황에 대해 리뷰하고자 합니다.

안 좋은 리뷰
"함수 표현식을 사용하셨군요. reduce의 사용도 잘 활용했네요."
이 피드백은 코드의 전체를 본 것이 아니라 독립적으로 본 경우입니다. 일관된 코드인지 확인하기 위해서는 코드 전체를 봐야 합니다.

좋은 리뷰
"함수를 선언하는 두 가지 방식(함수 표현식, 함수 선언식)을 사용했는데
특별한 이유가 아니라면 함수를 선언하는 방식을 스스로 정하고 그 컨벤션 규칙을
따르도록 해보세요. 일관되게 동작하는 코드는 훨씬 보기 좋고 쉽게 수정할 수 있습니다.
그리고 reduce를 통해서 새로운 자료구조를 만든 건 잘했습니다.
하지만 같은 반복처리를 하는 과정에서 calculateEarningRate 에서
for문을 사용한 건 아쉽네요. reduce와 비슷한 방식의 다른 고차 함수를 찾아서
써보면 더 일관된 코드를 유지할 수 있을 거 같습니다."
함수를 반복적으로 선언하는 곳은 프로젝트에서 정한 컨벤션 규칙을 지키면서 코드를 작성하는 게 좋습니다. 만약 프로젝트 내 컨벤션 규칙이 없다면 본인이 정한 예상할 수 있는 수준의 컨벤션 규칙도 좋습니다. 리뷰이가 작성한 코드에서 일관되지 않은 부분을 알려주고 어떤 방식으로 수정하면 좋을지 방법을 제안하는 피드백입니다.

4. 리뷰 과정이 숙제검사가 아닌 학습과정으로 느낄 수 있게 리뷰해 주세요.

코드 리뷰를 하는 목적은 서로 생각을 공유하고 좀 더 깔끔한 코드를 작성하기 위함입니다. 그러나 코드 리뷰를 받아본 경험이 적은 개발자에게는 리뷰가 숙제로 받아들일 수도 있습니다. 이러한 상황을 예방하기 위해 리뷰이가 코드리뷰를 학습 일부로 받아들이기 위해 피드백을 자주 주고받고, 성장하고 있다는 생각을 심어주는 것이 좋습니다.

class Component {
    constructor(node) {
        this.node = node;
    }

    render(child) {
        this.node.appendChild(child);
    }
}

class Header extends Component {
    constructor(node) {
        super(node);
    }
}

class List extends Component {
    constructor(node) {
        super(node);
    }
}

Header, List 클래스가 Component 클래스를 상속받는 코드입니다. 기능 구현에는 큰 문제가 없어 보입니다. 타입 에러가 발생하지도 않을 것 같고요. 리뷰이의 숨은 의도를 파악하기 위해 먼저 충분한 대화를 통해 의도를 파악하는 것이 좋습니다. 리뷰이는 향후 확장성을 고려하여 미리 클래스를 나눴을 수도 있기 때문입니다. 만약 그런 것이 아니라면, 몇 가지 아쉬운 부분은 보입니다. 자식 클래스의 constructor에서 아무 일을 하지 않고 부모 클래스를 호출만 합니다. 그리고 Component 클래스에서 선언한 메소드도 사용하지 않습니다. 이러한 무의미한 상속은 불필요하다는 것을 리뷰하고자 합니다.

안 좋은 리뷰
“클래스 상속은 필요 없습니다.”
리뷰이의 의도는 파악하지 않은 채 클래스 상속은 필요 없다고 단정을 짓고 있습니다. 먼저 왜 이렇게 짰는지 의도를 파악하는 것이 좋습니다.

좋은 리뷰
"Component 클래스를 상속 받는 건 좋네요.
그러나 자식 클래스에서 부모 클래스를 호출만 하기 때문에 모든 클래스에서
상속받는 건 오히려 중복 코드 같아 보이기도 하는데 이렇게 작성해 주신 이유가 있을까요?"
먼저 ‘중복 코드’라는 단어를 사용하여 상속의 불필요한 이유를 설명하고 있습니다. 그리고 리뷰이의 생각은 다를 수 있으므로 의도를 물어봅니다. 리뷰이는 이 피드백을 보며 본인이 왜 이렇게 코드를 작성했는지 다시 되돌아보겠죠. 그 과정에서 어떤 부분을 수정해야 되는지 고민하고 학습할 수 있는 계기가 됩니다.

5. 리뷰를 위한 리뷰를 하지 마세요. 피드백 할 게 없으면 칭찬해 주세요.

리뷰할 부분이 없는데 흔적을 남기기 위해 리뷰할 경우 서로 어색해지는 경우도 발생합니다. 예를 들어, 깔끔하게 짜인 코드에 다른 디자인 패턴을 권유하는 것입니다. 리뷰이 입장에서는 잘 짜인 코드임에도 불구하고 안 좋은 코드라 여기고 잘못된 방향으로 아키텍처가 설계될 수 있습니다. 또는 앞뒤의 연관 관계없이 “코드가 복잡해 보입니다.”, “코드가 읽기 어렵습니다.”와 같은 리뷰는 서로 감성소비만 심해집니다. 따라서 리뷰할 부분이 없으면 칭찬 피드백을 주는 것도 한 가지 방법입니다.

아래는 칭찬 피드백에 대한 예시입니다.

  • 코드량이 적당해서 읽기 편하네요.
  • 많은 고민이 코드에서 엿보이네요.
  • 성능에 아주 유리한 코드라고 생각되네요.
  • 전에 코드보다 훨씬 좋아진 거 같네요.
  • 예외 처리가 꽤 꼼꼼해서 좋네요.
  • 함수, 변수명이 직관적이어서 좋네요.

‘칭찬은 고래도 춤추게 한다.’라는 속담도 있듯이 리뷰할 때 좋은 코드, 깔끔한 코드를 보고 칭찬한다면, 서로 시너지 효과를 증대시킬 수 있습니다.

마치며

코브 리뷰는 결국 비용의 문제로 귀결된다.
당장 하면 돈과 시간이 들지만 혹자는 이런 말은 했다 "빨리 가는 유일한 방법은 제대로 가는 것이다."
장기적으로 보면 이것 만큼 오래가고 비용을 아낄 수 있는 방법은 없는 것 같다.
우리 함께 코드 리뷰 묻고 더블로 가자.

profile
溫故知新

0개의 댓글