코드 리뷰, Code Review

*류석영 교수님의 코드 리뷰 강의를 시청한 후 작성하였습니다.

개인적으로 강의를 듣고 나서 드는 생각은, 교수님의 밝은 에너지가 상당히 인상적이라는 것이다. 강의의 짜임새가 정말 좋았고 강의 내내 밝은 분위기가 유지되었다.

그리고 정글 학생들을 위해 강의 PDF 파일을 어느 정도 한글로 번역을 진행하셨다는 점과, 티 타임 때 조언해주시는 말씀을 들어보면 항상 배려가 넘치신다는 생각이 든다.

코드 리뷰, Code Review

소프트웨어 개발 단계에서 이제는 꼭 필요한 단계이다. 이제는 작은 회사라도 제대로 된 회사는 꼭 코드 리뷰를 한다. 코드를 우리 repository에 넣어도 될까요?라고 요청하고 확인 받는 것이 코드 리뷰이다. 코드 리뷰는 읽는 사람이 편할 수 있게 개선해주는 것이다. 누군가는 읽을 나의 코드를 이해하기 쉽게 만드는 것이다.

소프트웨어 개발 모델

• Waterfall model -> Agile model
• Careful code design -> Continuous integration
• Minimal updates -> Continuous development

예전처럼 처음부터 끝까지 조심스럽게 다 짜고 난 후 제품을 내놓는 것이 아니라, 현재는 일단 만든 모델을 시장에 내놓고 계속해서 발전시키는 형식으로 변하였다.

테스트가 기본이다. Test-Driven Development

• 구현하기 전에 테스트부터 짠다.
  평범한 예제와 corner case(이상하면서도 되야 하는 예제)를 미리 짜놓는다. 테스트부터 짜지 않으면 코드를 하면서 나를 속인다.
• 구글이 테스트를 강하게 하는 기업 중 하나이다. 테스트 없이는 변경된 코드를 반영하지 않는다.

Pair Programming

• 2명의 개발자가 하나의 컴퓨터 앞에서 프로그래밍하는 것을 말한다.
• 빠르게 지식을 배울 수 있다.
• 이렇게 2명이서 일하면 빠르게 배울 수 있고, 지켜보기 때문에 잘하게 된다. 또한 친해지기 때문에 물어보러 가기가 쉬워진다.

코드 리뷰가 필요한 이유

• 다른 사람이 읽기 쉽게 코드를 개선할 수 있다.
• 리뷰어가 남긴 의견으로부터 팁을 배울 수 있다.
• 결함을 줄일 수 있다.
• coding decision에 대한 개발 역사를 보관할 수 있다. 새로 들어온 사람이 커밋들을 보고 이해할 수 있게 된다.
• 일관적인 코딩 스타일을 유지할 수 있게 되면서 refactoring 및 debugging에 큰 도움이 된다.
• 협력심을 기를 수 있다.

+ 제일 좋은 코드 리뷰 ex. ~~한 코드는 ~~한 이유로 ~~하게 바꾸면 좋습니다. + 레퍼런스 링크

코드 리뷰의 단점

• 거칠고 무례한 의견으로 인해 의지를 떨어뜨릴 수 있다.
• 리뷰가 늦어지면 개발 기간이 늦춰진다.
• 코드 리뷰를 제대로 하려면 시간이 오래 걸린다.
• 경험이 부족한 개발자의 코드를 리뷰하느라 숙련된 개발자의 시간이 허비될 수 있다.
• 코드 리뷰를 위해서는 어느 정도 숙련된 개발자가 필요하다.

Guideline

• 그 언어의 전문가, 해당 프로젝트의 전문가는 꼭 필요하다.
• 코드 리뷰는 작성하는 사람을 위한 것이 아니라, 읽는 사람을 위한 것이다.
  ex. 타입을 선언 안하는 등, 편하다고 생각하는 것을 익숙하게 쓰다보면 스노우볼로 큰 구멍이 생길 수 있다. 디버깅이 오래 걸릴 수 있다.
• 타입(const, let 등)도 그냥 쓰고 변수도 짧은 것이 아니라 길게 써서 읽으면 무슨 변수인지 알 수 있도록 한다.
• 언어나 프레임워크에 새롭게 추가된 기능 은 테스트 케이스가 충분치 않으니 지양하고 기본에 충실해야 한다.

General Naming Rule

• 약자 사용을 지양한다.

int price_count_reader;		// Good!
int num_errors;				// Good!
int n;						// Bad!
int nerr;					// Bad!

• 함수는 작게 짜라. 엄청 많은 일을 하도록 짜면 디버깅하기 힘들다.
• 팀 혹은 사내에서 일관된 코딩 스타일을 유지하는 것이 좋다.

Testing

• 소프트웨어 분야에서 제일 큰 분야 중 하나이다.
• 바람직한 행동을 기술하는 것이다. ~~한 입력값을 넣었을 때 ~~한 출력값(기대값)이 나와야 하는지 미리 짜는 것이다.

Testing Rocks! Debug Sucks!

• 테스팅 짱이에요! 디버깅은 후져요!
  

• 디버깅은 보통 문제를 찾는 데에 시간이 오래 걸린다. 결함을 찾는 데에도 오래 걸린다.

• 테스팅은 시간을 줄이면서도 새로 작성한 코드에서 결함을 검출할 수 있다.

• 유지보수를 간편히 할 수 있다.

• 새로 온 개발자도 테스트 코드를 잘 작성해서 프로젝트에 기여할 수 있다.

Code Refactoring

• SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것이다. 즉, 코드의 구조를 잘 정해진 규정대로 수정하는 기술이다.
• SW를 더 이해하기 쉽게 만들고 수정하는 비용을 줄인다.
• 하지만 시간이 어느 정도 소모되는 작업이다.

Refactoring이 필요한 이유

• 새로운 기술이 나오기 때문에 Refactoring이 없으면 프로그램의 설계가 낡아진다.
• 결함을 검출할 때도 있고 이해하기 쉬워진다.

Refactoring의 몇 가지 요소

• 함수는 작게 나눠라.
• 전역 변수는 지양해라.

디버깅과 테스팅의 차이

• 디버깅은 프로그램을 개발하면서 한다. 범인이 누구인가 찾아가는 것이 디버깅이다.
• 테스팅은 프로그램을 개발하기 전에 짠다. c언어로 치면 main 함수를 짜기도 전에 짜는 것이다. 내 머리로 이해한 것을 바탕으로 테스팅을 먼저 짜는 것이다.