Code_Review 강의 정리

코드리뷰 강의 (류석영 교수님)

 

• 코드리뷰에서 중요한 것

Test-Driven Development

1. 요구사항과 구현을 분리

- 구현하기 전에 test부터 짜야 한다.

- 인풋에 대한 아웃풋, 인풋이 코너케이스로 들어오는 경우, 엣지케이스가 들어왔을 때의 아웃풋을 예상하기 위함

 

2. 커멘트 많이 남길 것

- 개발 기간이 길어질수록 커멘트와 코드가 멀어지는데, 테스트는 그럴일 없다.

- 커멘트는 글인데 반해, test는 실행 가능한 문서다.

 

3. 테스트 없이 커밋하지 말 것

- 자잘하게 많이, 빨리 커밋해라

 

Pair programming

- 선배 어깨너머로 배운다

- 컴퓨터 하나로 코딩

- 다른 사람이 보고 있어서 집중 놓지 않을 수 있다.

 

• 코드리뷰란 무엇인가?

이제는, 소프트 개발 흐름에서 꼭 필요한 단계, 선택이 아님

소프트 설계는 코드리뷰가 아니다.

코드 '변화'에 관한 것이다

 

• 구글코드리뷰 스텝

step 1 : SoftWare Engineer(SWE)가 변화시키려는 코드를 CL(change list)이라고 부른다.

step 2 : 동료에게 comments 부탁

step 3 : 지목받은 동료가 comments를 남긴다.

step 4 : 2-3명의 리뷰어의 comments를 바탕으로 코드를 계속 수정

step 5 : 모든 리뷰어가 LGTM(Looks Good To Me)하면, CL을 repository에 넣는다.

 

• 코드리뷰가 왜 중요한가?

- 당신의 Change List 를 이해하기 쉽게 만든다.

- 동료가 당신의 코드를 이해할 수 있어야 한다.

- 동료가 남긴 의견으로부터 tips & lessons들을 배운다.

- 당신의 팀이 공통된 코딩 스타일을 공유할 수 있다.

- 당신의 코드에 일관적인 코딩 스타일을 유지할 수 있음

- 일관적인 코딩 스타일은 이후에 코드를 refactoring하거나 디버깅할 때 큰 도움이 됨

- constructive feedback 필요

- 코드리뷰를 다른 팀과도 하면 수준이 높아짐, 협력이 더 잘됨

• 제일 좋은 커멘트는 

~이유로 ~게 바꾸는게 좋다 + reference/link 첨부

예를 들어, list arr 집합적인 데이터구조가 있을 때, 원소를 가졌는지 비었는지 체크하는 방식이, is_Empth함수 혹은 size(len(list))==0 일때 로 하는데, 전자가 좋음

 

• 코드리뷰의 단점(문제점)

- 거칠고 무례한 의견

- 개발기간 늦어짐

- 시간

- 숙련된 개발자의 시간 허비

그러나, 숙련된 개발자도 다른 사람의 코드를 보며 본인의 생각을 말로 표현하는 연습을 하게 되면서 많이 배운다. 커멘트는 서로 주고 받으므로 대화하면서 배우는 부분이 많음

결론은, 코드리뷰는 문화가 필요하다

 

• Cord Review Course

Code review 

Code review workflow with Git 

Code review etiquette 

Coding style guidelines

Testing 

Code review case studies 

Code refactoring 

Secure coding 

Clean code

 

• Coding style guidelines

- 코드리뷰는 두가지 역할 이상이 할 것(해당 코드 언어의 전문가, project owner)

- 코드리뷰는 reader를 위한 것.

클린코드를 인용하면, 

여러분은 작가입니다. 프로그래밍 언어로 글을 쓰는 것일뿐, 작성자 자신도 reader

type 명시, 이름도 줄이지 말고 길게 쓸 것

- 새로운 기능은 최대한 자제

- 함수만드는게 가장 중요한데,

1) 한번에 한가지 일만 하도록(가장 작게) 2) 하는 일을 명확하게 3) 이름에서 드러나도록

 

• Testing 

Testing Rocks! Debug Sucks!

- 디버깅은 보통 문제를 찾는데 엄청 시간이 오래 걸림

- 테스팅은 새로 작성한 코드에서도 결함을 검출할 수 있음

- 테스팅은 테스트 코드를 필요로 하기 때문에, 유지보수 부담을 줄임

 

Project Scalability

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

- 동료나 외부 기여자에게 도움을 받기에 가장 적합함

 

Testing Types

- Unit Testing ** : 대부분. 단위 하나, 즉 함수 하나씩 테스트

- Integration Testing : 여러개의 상황에서 테스트

- Regression Testing : 나이트닝 테스트

- End-to-End(E2E) Testing

 

• Code refactoring 

- Refactoring은 SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것, 즉, 코드의 구조를 잘 정해진 규정대로 수정하는 기술임.

- SW를 더 이해하기 쉽게 만들고 수정하는 비용을 줄임.

- 꽤 오랫동안 숙련된 개발자들 사이에 전해내려오는 노하우로, 정돈되지 않고 일관적이지 않았음.

- Refactoring is an overhead activity

 

Why Refactor?

- SW 설계 개선

Refactoring이 없으면 프로그램의 설계는 낡아짐.

설계가 좋지 않은 코드는 보통 같은 일을 하는데 코드가 길고, 같은 일을 여러 곳에서 함.

- 이해하기 쉬움

대부분의 SW 개발 환경에서, 누군가 언젠가는 당신의 코드를 읽어야할 때가 오기 때문에, 그들을 위해 이해하기 쉬운 코드를 작성해야함.

- 결함 검출할 때도 있음.

- 프로그램 속도 향상

프로그램에 대해 더 잘 이해하기 때문에

 

코드리뷰에서 가장 중요한 것
- 이해하기 쉬운 코드
- 유지보수하기 쉬운 코드