[책 리뷰] 구글 엔지니어는 이렇게 일한다 - 코드리뷰 파트

책 '구글 엔지니어는 이렇게 일한다' 중 코드리뷰에 관한 파트를 읽고 신기했던 부분과 인상깊었던 부분을 기록하였다.

신기했던 부분

• 소유권의 개념과 소유권자를 별도 파일로 명시. 이걸 우리팀에 어떻게 적용할 수 있을까? 필요할까 생각해봤을때 아직은 그렇지 않은거같다 싶음
• 변경 코드는 200줄로! 신규는 제외겠지! 구글은 대부분 기존코드의 변경이니까! → 그래도 변경 PR에서도 200줄이라니 뭔가 신기함!

인상깊었던 부분

• 코드는 작성되는 것 보다 읽히는 횟수가 많다
• 코드 리뷰는 설계를 번복하거나 재논의하는 자리가 아니다

• 작성자의 설계를 존중하라.
  • 리뷰어들은 작성자가 선택한 방식을 존중하고 그 방식에 결함이 있을 때에만 대안을 제시해야 한다. 작성자가 선택한 방식에서 결함을 찾게 된다면 작성자와 리뷰어 모두 배움의 기회로 생각하면 된다.

• 코드리뷰가 완벽할 필요는 없다
  • 코드리뷰마저 완벽할 필요가 없다는 이유가 명확하다. 코드리뷰를 통해 얻고자 하는 이점은 완벽한 코드를 구현하는 게 아니기 떄문임!
  • 그래서 코드리뷰를 통해 얻을 수 있는 이점을 더 와닿아!! 완벽함을 지향하지 않기 때문에 얻을 수 있는 이점들 아닐까! 구글이 코드리뷰를 통해 얻고 있는 이점들에 집중해보자

• PR 전 스스로 검증하는 시간을 통해 안일한 태도 버리기

• 코드리뷰를 통해 지식이 양방향으로 공유된다는 점은 크게 공감함
• 나와 나의 코드를 동일시하지 말고, 내가 제안한 변경은 나의 것이 아니라 팀의 소유임을 잊지 말라
• 리뷰어의 댓글은 모두 TODO 취급해라

• 모든 커밋은 롤백 가능성이 있기 때문에 가능한 작고 원자적이어야 한다.
  • 커밋이 중간에 롤백되더라도 깨지지 않도록 커밋해야한다는 소리!
  • 예를 들어 1번 커밋과 2번 커밋이 있을 떄, 2번 커밋이 롤백됐다고 테스트 실패하거나 기능이 동작하지 않으면 그거는 적절한 단위의 커밋이 아님
  • 나는 앵귤러 커밋 스타일인가? 그거 하고 있어서 feat, fix. test, docs 구분하느라 fix와 test를 분리해서 커밋할떄도 있었는데,
    중간에 test 커밋만 롤백되면 테스트가 깨지게 되는 셈임! 이럴 때는 하나로 묶는 게 더좋았으려나?
  • → 의도의 단위!! 어차피 피쳐 브랜치는 스쿼시 되기 때문에 롤백 대상이 아니라서 원자성을 신경쓸 필요 없어. 이 경우 커밋은 의도의 단위대로 커밋하는 게 더 적절하다!

요약