유튜브를 통해 전산학부 교수님의 코드리뷰에 대한 강의를 들었다.
실제로는 방대한 내용이라고 하셨는데, 간단하고 핵심인 부분만 요약해주셨다.
경험이 많은 건 아니지만 와닿는 내용이 꽤 있었다.
동영상을 보면서, 나중에 일을 하면서 다시 기억을 하기 위해 몇 가지 중요해보이는 키워드를 적어 보았다.
Software Development Models
과거 - 개발 대상의모든 스펙을 협의하고 갖추고 한번에 시작 , 최소한의 변경점
Waterfall modelCareful code design
Minimal updates
현재 - 테스트 버전 런칭 후 지속적인 develop
Agile model
Continuous integration
Continuous deployment
이러한 이유로 코드 리뷰가 중요해지고 있다.
글로벌 회사들의 주요 개발문화
1. Test-Driven Development
Separation of requirements and implementation.
Tests are executable document, which are always synchronized with the code.
No source code without tests
제품의 요구사항과 구현을 분리한다.
다양하고 가능한 종류의 Input을 고려한 테스트를 많이 시도함. 테스트 없이는 소스코드 작성도 없다.
한번에 많은 변경점이 있는 commit보다 자잘하게 commit을 많이하는게 디버깅에 유리하다.
2. Pair promramming
Two developers with one machine
Fast knowledge transfer
하나의 컴퓨터에 앉아서 코드를 짜는 방식
3. Code Reivew - 제대로된 글로벌 회사들 (Facebook, Google, Amazon)은 코드리뷰를 중요시한다.
One stage in a software development workflow
Gets feed back from your colleagues on your code to submit
It is Not about
- Getting comments on overall software designs
- Planning requirements or features for a product
-> 단지 코드 변화에 대한 코멘트임
Step 1. A software engineer (SWE) implements a CL (change list)
Step 2. The CL owner sends the CL to his/her colleagues for comments
Step 3. The designated colleagues leave comments on the received CL
Step 4. The CL owner changes his or her CL based on the received comments and iterates Steps 2 & 3 until the owner gets LGTM (looks good to me).
Step 5. When all reviewers say LGTM, the CL owner submits the CL to the repository.
중요한점 * 코드리뷰는 작성하는 사람을 위한게 아니라 읽는 사람을 위한 것이다.
Why is code review necessary?
- 작성자의 CL 을 이해하기 쉽게 만듬 ( 동료가 이해할 수 있어야함)
- CL에 동료가 남긴 의견으로부터 tips & lessons을 배움.
- 숙련된 개발자로부터 코딩 스타일과 팁을 배움.
- 팀이 공통된 코딩 스타일을 공유할 수 있음
- 결함을 줄일 수 있음.
- 작성자의 code decision에 대한 개발 역사를 보관함
- 동료의 의견은 코드 설계와 결정 사항에 대해 이해하는데 큰 도움이됨.
Google C++ style Guide : https://google.github.io/styleguide/cppguide.html (좋은 code examples이 있음 )
Google C++ Style Guide
Google C++ Style Guide Background C++ is one of the main development languages used by many of Google's open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn ca
google.github.io
코드 리뷰어는 이상적으로는 프로젝트 오너, 해당 언어의 전문적인 지식을 갖춘 사람이 참여해야 한다.
코드리뷰는 읽는 사람을 위한 것이다.
JAVA에는 귀찮아서 제대로 명시안하고 타입을 자동화 하는 부분들이 있음 이런 부분들은 디버그하기 정말 어려워진다.
기존에 코드가 있으면 기존 코드 스타일에 맞추어라.
나만 먼저 알고 있는 새로운 기능 사용하지 말 것.
General Naming Rule
- Name should be descriptive.
- Avoid abbreviation
- Give as descriptive a name as possible
Function
- Write small and focused functions
- A function that perform multiple operations is hard to maintain as a project grows
-> 너무 많은 기능 가진 함수 만들지 말 것,
가장 중요한 것은 특정 스타일을 따르는 것이 아니라 일관된 코딩 스타일을 갖고 있는게 중요하다.
Testing
- Testing Rocks! Debug Sucks!
- 디버깅은 보통 문제를 찾는데 시간이 오래걸림.
- 테스팅은 새로 작성한 코드에서도 결함을 검출할 수 있음.
- 테스팅은 테스트 코드를 필요로 하기 때문에, 유지보수 부담을 줄임.
- Project Scalability
- 새로 온 개발자도 테스트 코드를 잘 작성해서 프로젝트에 기여할 수 있음
- 동료나 외부 기여자에게서 도움을 받기에 가장 적합함.
Testing Types
- Unit Testing
Test an individual function, interface or class.
Mostly validate execution behaviors of a single function.
- Integration Testing - 함수는 작성자가 예상한 상황에만 사용되는게 아님, 통합적인 환경에서 테스팅 되야함.
Test execution behaviors when two or more modules interoperate.
- Regression Testing - 과거에 테스팅 되었던 기능들이 그대로 사용 가능한지
Validate whether an existing /developed software performs the same way even after its source code is changed
Code Refactoring - 기능은 유지한 채로 개선하는 것, 이해하기 좋은 코드, 개선하기 좋은 코드가 좋다.!
- Refactoring은 SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것. 즉, 코드의 구조를 잘 정해진 규정대로 수정하는 기술임. SW를 더 이해하기 쉽게 만들고 수정하는 비용을 줄임.
- 꽤 오랫동안 숙련된 개발자들 사이에 전해내려오는 노하우로, 정돈되지 않고 일관적이지 않았음.
- Refactoring is an overhead activity
Why Refactor?
- SW 설계 개선
- Refactoring이 없으면 프로그램의 설계는 낡아짐.
- 설계가 좋지 않은 코드는 보통 같은 일을 하는데 코드가 길고, 같은 일을 여러 곳에서 함.
- 이해하기 쉬움
- 대부분의 SW개발 환경에서, 누군가 언젠가는 당신의 코드를 읽어야할 때가 오기 때문에, 그들을 위해 이해하기 쉬운 코드를 작성해야함.
- 결함 검출할 때도 있음.
- 프로그램 속도 향상
- 프로그램에 대해 더 잘 이해할 수 있음