코드 리뷰 강의
절대적 골!
이해하기 쉽고, 유지 보수하기 편하기!
과거에는 최대한 완벽에 가깝게 개발 후 배포, 이후에는 적은 업데이트를 했다면 요즘에는 배포와 개발을 동시에 진행하는 경우가 많다. 소비자의 니즈가 워낙 빠르게 바뀌고 이를 적용시키기 위해.
test driven development
구현과 요구를 분리하고 구현 이전에 요구, 즉 test case를 먼저 제작한다. 구현부터 하게 되면 나중에 test case를 제작할 때 자기 자신을 속이게 된다. 자기가 구현한 것에 맞는 테스트 케이스만 떠올리게 된다는 뜻.
pair programming
제일 빨리 배우는 법. 선배 개발자랑 나란히 앉아서 한 컴퓨터를 가지고 코딩하는 것. 그러면 가장 지식의 공유가 활발하게 이루어진다. 구글링 부터 코드 작성, 로직 까지 빠르게 습득된다. 부트캠프식 강의 보다도 경험상 페어 프로그래밍이 잘된다. 그리고 같이 하다보면 어쩔수 없이 더욱 코딩 자체에 집중하게된다.
그래서 코드리뷰란?
소프트개발 흐름에서 꼭 필요한 단계.
다른 동료에게 커밋등을 하기 전에 리뷰를 듣는 과정.
코드 리뷰 단계.
1. 개발자가 변경 사항을 만든다.
2. 변경사항을 개발자가 동료들에게 보내 코멘트를 요청
3. 지정된 동료들이 개발자의 변경 사항에 대해 코멘트를 남긴다.
4. 코멘트에 따라 개발자가 변경사항을 수정하고, 보기 좋을 때까지 2,3 단계를 반복한다.
5. 모든 리뷰어들에게도 보기 좋다 라는 판단이 서면 repository에 넣고 완료.
코드 리뷰는 나를 위해서라기보다 내 코드를 읽을 사람을 위한 것.
코드 리뷰가 필요한 이유
당신의 변경 사항을 이해하기 쉽게 만듬
다신의 동료가 당신의 코드를 이해할 수 있어야함
당신의 변경사항에 동료가 남긴 의견으로부터 배움을 얻을 수 있음.
숙련된 개발자로부터 코딩 스타일과 팁을 배움.
당신의 팀이 공통된 코딩 스타일을 공유 할 수 있음.
결함을 줄일 수 있음.
당신의 coding decision 에 대한 개발 역사를 보관함.
동료의 의견은 코드 설계와 결정 사항에 대해 이해하는 데 매우 큰 도움이 됨.
새로 온 개발자는 committed logs와 의견으로부터 코드의 구조와 결정 사항을 이해할 수 있음.
당신의 코드에 일관적인 코딩 스타일을 유지할 수 잇음.
새로 온 개발자가 기존의 코딩 스타일을 따를 수 있도록 도와줌
일관적인 코딩 스타일은 이후에 코드를 refactoring 하거나 디버깅할때 큰 도움이 됨.
코드 리뷰의 가능한 단점.
거칠고 무례한 의견 때문에 CL owners may get discouraged.
리뷰가 늦어지면 개발 기간이 늦어짐.
코드 리뷰를 제대로 하려면 시간이 걸림.
경험이 부족한 개발자의 잘못된 CL(변경사항)을 리뷰하느라 숙련된 개발자의 시간이 허비될 수 잇음.
코드리뷰를 위해서는 어느정도 숙련된 개발자가 필요.
코드리뷰는 문화의 영역이다.
코드 리뷰는 문화의 서포트가 필요하다.
동료를 존중하고, 코드 리뷰 문화를 만들기 위해서는 시간이 필요하고 기타 등등.
스타일 가이드: google style guide c++ 이외에도 다른 언어도 있음.
google.github.io/~~~
스타일 가이드의 목표
코드를 커밋할 때 반드시 가이드라인을 따라야한다.
코드는 작성자를 위한게 아니라 읽는 사람을 위해 써야한다.
클린 코드는 작성자가 작가라고 생각해야한다. 자주 읽히기에 읽는 사람을 위주로 작성해야한다.
구글은 아쉬운 사람을 놓치는 것보다 혹시라도 마음에 안드는 사람을 뽑는 것을 더욱 싫어한다.
그래서 구글러 끼리는 인정하는 분위기가 강하다.
평균적인 이름 짓기
이름은 최대한 길고 명확하게
함수는 작게 짜라. 하는 일이 명확하고 작은 일을 해야한다.
길게하면 디버깅도 문제가 생길 일이 많다.
testing이 중요한 이유
TESTING rocks! Debug Sucks!
디버깅은 보통 문제를 찾는 데 엄청 시간이 오래 걸림.
테스팅은 새로 작성한 코드에서도 결함을 검출할 수 있음.
테스팅은 테스트 코드를 필요로 하기 때문에, 유지보수 부담을 줄임.
Project Scalability
새로 온 개발자도 테스트 코드를 잘 작성해서 프로젝트에 기여할 수 있음.
동료나 외부 기여자에게서 도움을 받기에 가장 적합함.
대부분 unit testing 한다
함수하나 하나를 테스트.
code refactoring
refactoring 은 SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것. 즉 코드의 구조를 잘 정해진 규정대로 수정하는 기술.
SW를 더욱 이해하기 쉽게 만들고 수정하는 비용을 줄임.
꽤 오랫동안 숙련된 개발자들 사이에 전해내려오는 노하우로, 정돈되지 않고 일관적이지 않았음.
Refactoring is an overhead activity.
why refactor?
SW 설계 개선.
refactoring이 없으면 프로그램의 설계는 낡아짐 ( SW도 나이를 먹는다)
설계가 좋지 않은 코드는 보통 같은 일을 하는데 코드가 길고, 같은 일을 여러 곳에서 함.
이해하기 쉬움.
대부분의 sw 개발환경에서 누군가 언젠가는 당신의 코드를 읽어야할 때가 오기 때문에 그들을 위해 이해하기 쉬운 코드를 작성해야함.
결함 검출할 때도 있음.
프로그램 속도 향상
프로그램에 대해 더 잘이해하기 때문에.
글로벌 변수는 가급적 안 쓰는게 좋다.
장덕수의 요약!
1. 코드리뷰는 작성자를 위한 것이 아닌 읽는 사람(리뷰어)을 위한 것!
- 내가 작성한 코드에 대해 코멘트를 깔끔하게 작성하자(리뷰어가 한 달 후의 나일지도 모른다).
- 지금 귀찮더라도 변수의 데이터 타입 잘 쓰고, 이름도 이해할 수 있게 잘 짓자.
2. 함수 만들 때
- 이름에서 기능이 잘 표현되도록!
- 하나의 함수가 많은 기능 수행하지 않도록 최대한 잘게 쪼개라. 함수가 커지면 나중에 디버깅할 때 힘들다.
3. 코드리뷰할 때 긍정적이고 건설적인 피드백을 할 수 있도록 하자.4. 좋은 개발자는 코드를 새로 커밋할 때 CL(Chang List)을 이해하기 쉽게 만든다.
- 오픈 소스를 볼 때 committed log 봐야 하는 경우가 많다(어떤 시점에서 어떤 부분이 어떻게, 왜 바뀌었는지 파악하기 위해).
- 그래서 좋은 개발자는 코드를 바꿀 때 왜 바꿨는지, 어떤 문제가 있었는지 등을 다 코멘트로 작성해 놓는다(이것은 ... 한 이유로 ... 하게 바꾸는 것이 좋다. 이것에 대한 레퍼런스: xxx..)