구글 엔지니어는 이렇게 일한다 - 8장, 9장

8장 스타일 가이드와 규칙

스타일 가이드의 목표 → 코드의 ‘지속 가능성’을 높이도록 이끄는 것

8.1 규칙이 필요한 이유

조직이 추구하는 가치를 기준 삼아 무엇을 장려하거나 억제할지 규정하는 규칙, 지침이 정해짐

확립된 규칙과 지침은 조직이 커지더라도 일관되게 통용되는 공통의 코딩 어휘가 되어줍니다.

어휘가 통일되면 엔지니어들은 코드를 표현하는 ‘형식’보다 코드에 담을 ‘내용’에 집중할 수 있습니다.\

8.2 규칙 만들기

목표에 집중하면 규칙이 따라옵니다.

8.2.1 기본 원칙 안내

• 규칙의 양을 최소화 할 것
  • 다 기억하지도 못할 뿐더러 관리 비용이 많이 들게 됨
• 코드를 읽는 사람에게 맞출 것
  • 코드는 작성 되는 횟수보다 읽히는 횟수가 더 많음 → 읽기 난해한 것보다 타이핑하기 지루한 편이 낫다
  • 엔지니어가 의도한 행위를 분명하게 알려주는 증거를 코드에 남겨라
  • 다른 코드를 찾아보거나 참조할 필요 없이, 함수의 구현부를 들여다보지 않고도 호출 지점에서 무슨 일이 벌어지는지를 명확히 이해할 수 있도록 하는 것
  → ex, 접근 지정자 명확하게 명시 하기
• 일관 될 것
  • ‘단 하나의 답’만 사용한다는 일관성
  • 같은 컴포넌트를 사용하고 동일한 규칙을 따른 코드를 구성한다면 수많은 관리 작업을 자동화해주는 도구를 제작 할 수 있음
  → Swift macro 기능 활용 가능
  • 외부 커뮤니티에서 정착된 표준도 고려해야 함
    • 수명이 길고 확장 될 가능성이 크다면 언젠가 외부 코드와 상호작용 가능성이 있음
    • 널리 쓰이는 표준을 따르는게 유리
    → Swift가 사용하는 단어들 사용하기
    → 큰 오픈소스에서 어떤 컨벤션을 사용하는 지 많이 보기
• 오류가 나기 쉽거나 예상치 못한 동작을 유발하는 구조는 피할 것
  • 복잡한 기능에는 함정이 숨어있는 경우가 많음 → 버그 유발 가능성 높음
  • 다른 엔지니어도 동일하게 이해하고 사용할 지 보장 불가
  • 유지보수하기 쉽도록 명료하고 직관적인 코드 추구
• 필요 시에는 실용성을 생각하여 예외를 허용함
  • 상호 운용성 고려
    • 기본 명명규칙은 카멜 케이스지만, 표준 라이브러리 기능을 모방하는 기능에 한해서는 스네이크 케이스 이름 허용

8.2.2 스타일 가이드에 들어가야하는 내용

• 위험을 피하기 위한 규칙
  • 어떤 언어 특성은 사용하고 어떤 구조는 피해야 하는지를 설명하는 규칙들
• 모범 사례를 적용하기 위한 규칙
  • 주석 관련 규칙 → 어디에 어떻게 작성되어야 하는가
  • 가독성을 높이도록 설계
  • 자동 포맷팅 도구
  → SwiftLint
• 일관성을 보장하기 위한 규칙
  • 사소한 문제를 다루는 규칙을 정하기 → 사소한 문제에 시간 낭비하지 않도록

8.3 규칙 수정하기

• 스타일 가이드의 규칙에 각 결정을 뒷받침하는 근거를 명시 → 규칙을 변경해야 할 때가 언제인지 파악 가능

8.4 지침

• 과거로부터 배운 교훈들로부터 추린 모범 사례들을 문서로 남긴 것
• 올바른 코딩 습관을 위해 독려하는 조언들

8.5 규칙 적용하기

• 코드리뷰
• 자동화 도구 사용
  • 세밀하게 판단하는 로직을 만들기 위해서는 많은 비용이 듬
  • 주관적인 것들이 많기 때문에 강제화 하기 어려움

8.6 마치며

모두가 함께 사용하는 규칙 모음은 엔지니어링 프로세스에 기준을 잡아주어 코드베이스를 계속 확장하고 성장할 수 있게 해줍니다. 그 결과 코드베이스와 조직 모두 오랜 기간 살아 숨 쉴 수 있게 됩니다.

8.7 핵심정리

• 규칙과 지침의 목표는 시간과 확장 관점에서의 탄력성을 높이는 것이어야 합니다.
• 상황이 변하면 규칙도 달라져야 하니 규칙이 만들어진 근거 데이터를 알고 있어야 합니다.
• 모든 것을 규칙으로 강제해서는 안됩니다.
• 일관성이 핵심입니다.
• 가능한 한 규칙들이 자동으로 적용되도록 해야 합니다.

9장 코드 리뷰

코드 리뷰는 ‘버그가 코드베이스로 침투하기 전에 잡아낸다’처럼 확실하고 쉽게 납득되는 이점을 제공

9.1 코드 리뷰 흐름

• 프리커밋 리뷰 - 변경을 코드베이스에 커밋하기 전 수행하는 리뷰
• 코드 리뷰의 최종목표: 다른 엔지니어로부터 해당 변경을 적용해도 된다는 합의를 이끌어 내는 것

9.2 코드 리뷰 @ 구글

• 구글에서 변경에 대한 승인을 받기 위해서는 세 가지 측면에서 리뷰를 통과해야 함
  • 타 엔지니어로부터 정확성과 이해 용이성 평가
  • 코드 영역을 관리하는 코드 소유자로부터 변경 코드가 적절하다는 승인
  • 가독성 승인

9.3 코드 리뷰의 이점

코드의 정확성 확인

• 변경에 적합한 테스트가 갖춰졌는가?
• 설계는 적절한가?
• 정확하게 동작하고 효율적인가?
• 정확성 평가가 주관적으로 흘러가지 않도록 코드 작성자가 선택한 방식을 존중할 것
  • 리뷰어가 대안을 제시하는 것은 가능하나, 이해하기 더 쉽거나 기능을 개선하는 대안일 때만 제시

코드 리뷰에 들이는 시간은 테스트, 디버그, 회귀 테스트에 투입되는 시간을 줄여줍니다. 물론 코드 리뷰 프로세스 자체를 단순화하여 가볍게 유지해야만 합니다.

→ 작은 PR, 상세한 내용 작성하기

• 변경된 코드를 다른 엔지니어도 잘 이해할 수 있음
  • 작성자의 관점에 치우치지 않는 피드백을 제공
• 코드베이스가 일관되도록 관리 가능
• 팀이 주인의식을 더 강하게 느낄 수 있음
  • 코드는 ‘자신의 것’이 아니라 협업을 통해 만들어지는 ‘조직의 공동 소유물’임을 인식 시켜줌
  • 가장 뛰어난 엔지니어조차 가면 증후군을 겪거나 자기비판이 너무 심할 수 있음→ 코드 리뷰는 그들의 작업 결과를 검증하고 인정해주는 효과가 있음
  • 코드 작성자가 자신의 코드를 한번 더 들여다보게 하는 효과
  → PR을 작성하면서 code changes를 살펴보면서 내용을 작성하게 되는데, 놓친 부분을 발견하거나 더 좋은 방법이 생각나서 보완하게 되기도 함
  → 다만 작은, 상세한 PR을 쓰지 않는다면 이 단계는 없을 것
• 지식 공유
• 리뷰 프로세스는 제안, 신기술 소개, 조언을 통해 리뷰어가 변경 작성자에게 도메인 지식을 전파하도록 이끌어줍니다.
• 기록