류석영 교수님 강의를 내 멋대로 정리해둔 것임을 알립니다...

위의 사진은 5천만 사용자를 모으는 데, 걸린 시간을 표현한 것이다.
옛날에는 어떤 상품을 출시하기 전까지 많은 검증과 Test를 하고 출시했지만, 이제는 그런 시대가 지났다. 그러다간, 다른 상품이 먼저 나와서 시장을 점유할 것이다.
이 포인트에서 우리는 코드리뷰의 중요성을 역설할 수 있다.
상품을 빨리 만들어서, 그 이후 추가작업을 잘 할 수 있도록 해야하기 때문이다.
코드리뷰를 해야하는 이유
1. 이해하기 쉬워야 하고
2. 유지보수 하기 편한 코드를 만들기 위해
코드리뷰의 장점(필요성)
- Change List(CL)을 이해하기 쉽게 만드려고 한다.
- 동료가 당신의 코드를 이해할 수 있어야 하니까
- 내 CL에 동료가 남긴 의견으로부터 유용한 팁 등을 배운다
- 숙련 개발자로부터 스타일, 팁을 배울 수 있다.
- 소속된 팀의 공통된 코딩 스타일을 공유할 수 있따.
- 결함을 줄일 수 있다.
- 코드가 왜 이렇게 결정 됐는지에 대한 개발 역사를 보관한다. (Code decision 확인 용이)
- 동료들의 의견은 코드 설계과 결정 사항에 대해 이해하는 데 큰 도움이 된다.
- 새로운 개발자가 보고 이해하기 편하다.
- 팀 뿐만 아니라 개인도 일관적이 코딩 스타일을 유지할 수 있다.
- 새로운 개발자가 기존 코딩 스타일을 따를 수 있도록 도와준다.
- 일관적 코딩 스타일은 이후에 코드를 리팩토링하거나 디버깅할 때 도움이 된다.
- 코드가 투명하게 관리된다.
- 전사적인 협력이 가능해진다.

코드리뷰의 단점(문제점)
- 거칠고 무례한 의견 떄문에 의기소침해질 수 있다.
- 리뷰가 늦어지면 개발 기간 늦어질 수 있다.
- 코드 리뷰 제대로 하려면 시간이 걸린다. 문화로 자리잡기 까지도 시간이 오래 걸린다.
- 경험이 부족한 개발자의 잘못된 CL을 리뷰하느라 숙련된 개발자 시간이 허비될 수 있다.
- 제대로 된 코드 리뷰를 위해서는 어느정도 숙련된 개발자가 필요하다.
코드리뷰 스텝
- 소프트엔지니어가 코드를 바꾼다. 그 것을 리스트(CL = Change List)화 한다.
- 주변 동료들에게 코드리뷰 해달라고 요청을 한다.
- 거기에 코드리뷰를 남긴다.
- 많은 사람들이 다 LGTM(Looks Good To Me) 할 때까지 2,3번을 반복한다.
- 많은 사람들이 다 LGTM하면 CL을 업데이트 완료한다.
코드리뷰를 해주는 입장에서 팁
- "~한 이유로 ~한 결정을 하는 것이 좋다."라는 의견을 남기는 것이 좋다. + 참조 사이트 공유하면 좋다.
- 코드리뷰를 하면서, 언어로 정리 해주다보면 내가 아는 것이 정리되는 경험을 할 수 있다.
코드 작성 시 팁
- naming을 할 때, 약자로 짓지 말고, 웬만하면 풀어 써라.
- 함수는 한 역할(최소한의 역할)만 하고, 이름에서 그 함수의 역할이 뭔지 알게 하라.
- 다른 사람들 의견을 굳이 따르지 않아도 되지만, 팀에서의 규칙은 따르자.
Test와 Debuging의 차이
Test는 주로 개발 중에(코드 작성 중에) 확인하며, 결함을 발견하기 위한 Process다.
반면, Debuging은 결함의 원인을 찾고 코드를 수정하는 Process다.

코드 리팩토링(Refactoring)
Refactoring은 SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것이다. 즉, 코드의 구조를 잘 정해진 규정대로 수정하는 기술이다.
SW를 더 이해하기 쉽게 만들고, 수정하는 비용을 줄인다.
※ Refactoring이 없으면 프로그램의 설계는 낡아진다.
부가적인 말씀
오오 코드리뷰 문화! 멋지당!
Good Code와 Bad Code 모두 WTF은 디폴트군옄ㅋㅋ