68. 코드 리뷰 입문

---코드 리뷰 입문---

1. 코드 리뷰 - 개발자가 작성한 코드를 다른 개발자가 검토하는 것

 장점 : 잠재된 버그 조기 발견, 코드 품질 개선, 문제가 터졌을 때 작성자가 부재해도 리뷰한 개발자가 있으면 빠른 대처 가능. 개발자가 의견을 교류하며 학습할 수 있는 기회.

 단점 : 감정 소모.

 한 가지 작업(버그 잡기, 기능 추가 등)이 끝나면 해당 부분에 대해 코드 리뷰.

 도구는 버전 관리 시스템(git, svn 등)을 이용해 작업단위를 구분하고 코드 리뷰를 도와주는 도구들을 이용.

2. 좋은 코드란?

 사람마다 기준이 다르다. 하지만 강연자 분의 기준은 이해하기 좋은 코드.

 - 내가 작업한 코드도 몇 주 지나고 보면 뭘 작업한건지 몰라 다시 해독하는 시간이 필요하다.

 - 남이 작업한 코드는 해독하는 시간을 더 많이 들여야 한다.

 - 내가 작성한 코드를 남이 봐야 할 때도 마찬가지이다.

 그러기 위해서는 형식을 맞춰야 한다. (코딩 컨벤션, 코딩 스탠다드)

 모두 같은 형식으로 코드를 작성하여 코드의 가독성을 높이자.

 주석을 잘 달자.

 코드를 수정했으면 주석도 수정하자.

 이걸 잘 못하게 되면 팀 프로젝트에서 엄청난 혼란이 올 수 있다.

 좋은 코드 = 이해하기 쉬운 코드 = 읽기 쉬운 코드 => 주석이 없어도 바로 해석이 가능한 코드

 변수 이름에는 상황을, 함수 이름에는 기능을 반영하자.

 

 리팩토링은 계속, 도구를 이용하자. => (뒤는 비주얼 스튜디오에서 쓰는 법)

 - Rename => 바꾸길 원하는 애를 우클릭하면 Rename Symbol(이름 바꾸기), 또는 컨트롤+R

 - Go To Define => 우클릭하고 정의로 이동 또는 F12, 또는 컨트롤+클릭

 - Peek Define => 정의된 곳을 픽해줌 (알트+F12)

 - Find All References => 우클릭하고 모든 참조 찾기 (쉬프트+F12)

 함수 리팩토링

 - 이름으로 기능을 완전히 표현하도록 = 이해하기 쉽게

 - 가능한 짧고 이해하기 쉽게

 SOLID 객체 지향의 5대 원칙

 - SRP (단일 책임의 원칙 : Single Responsibility Principle)

 - OCP (개방 폐쇄의 원칙 : Open Close Principle)

 - LSP (리스코브 치환의 원칙 : The Liskov Substitution Principle)

 - ISP (인터페이스 분리의 원칙 : Interface Segregation Principle)

 - DIP (의존성 역전의 원칙 : Dependency Inversion Principle)

 단위테스트 (Unit Test)

 - 함수가 의도된 대로 정확히 작동하는지 검증하는 절차. 함수에 대응하는 테스트함수를 만들어 놓으면 완료. 

 - 코드 수정에 대한 두려움이 사라지고 자연스럽게 좋은 코드를 작성하게 됨.

 - 테스트 러너 코드와 도구 이용

 애자일 방법론

 - 소프트웨어 개발 방법에 있어서 무계획 개발과 계획이 과도한 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다.

 - 관련 키워드 : 익스트림 프로그래밍 XP, 스크럼, 짝프로그래밍, TDD

 - 폭포수 모델 등 기존 방법에서 개선된 방법. 일부를 만들고 확인해보고 더 살을 붙이고 확인해보는 식.

추천 도서

 - Clean Code

 - Code Complete 2

 - C#으로 배우는 적응형 코드