코드리뷰

하면 좋은게 아니다. 그냥 필수 요소.
pull request에 대한 리뷰라고 볼 수 있다.

코드리뷰 과정이 있으면 읽는사람을 위한 코드를 짜게 됨.

수정 제안/제안한 이유/레퍼런스

코드리뷰는 팀웍.
건설적인 피드백을 하는 것이 중요. 개발자도 사람.

구글 스타일 가이드

스타일 가이드를 지키는 방법.

1. 코드리뷰
2. 자동화 도구를 사용
3. 언어 전문가, 프로젝트 오너 (Readability & ownership)가 피드백

Testing

Testing rocks, Debug sucks!

• 디버깅은 보통 문제를 찾는 데 시간이 엄청 오래 걸림.
• 테스팅은 새로 작성한 코드에서도 결함을 검출할 수 있음.
• 테스팅은 테스트 코드를 실제로 만들어야 하기 때문에(만들고 가지고 있기 때문에), 유지보수 부담을 줄인다.

test driven development(TDD) : test가 기본이다!

• 요구사항과 구현를 분리.

• 테스트는 실행가능한 문서다.

• 구현 코드를 작성 하기 전 테스트 코드부터 작성하는 것 (test driven).

• 내 손으로 코드가 잘 짜였는지 확인하지말고 기계에게 시켜라!

Testing vs Debug

Testing

• 구현하기 전 혹은 개발 과정 중에,
• 요구사항(기대값, 바람직한 행동)에 대한 명세와
• 그 요구사항이 잘 도출 되는지 확인하는 코드를 작성하는 과정
• 단위 별(e.g. 함수 별)로 검사

"이런 인풋에서는 이런 아웃풋이 나와야해 라는 명세를 기술"
"기대하는 행동을 테스트로 기술한 다음 코드로 짜고 예상했던대로 작동하는지 보는 것"
"어쨋든 중요한 건 프로그램을 만들기 전(main함수의 괄호도 열기 전)에 테스트를 많이 짜놓고 시작해야 한다는 점"
(RB-tree 구현 과제를 예로 들자면 test-rbtree.c 가 테스트 코드.
그걸 코드를 짜는 것이 테스트를 만드는 것이고, rbtree.c와 함께 컴파일해서 돌려보는 것이 테스트.)

Debug

• 개발 완료 후 실행을 하다가 뭔가 잘못되었을 때,
• 전체 프로그래밍을 검사
• 오류가 발생한 부분을 찾아서 파고 들어감.

Refactoring

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