Part III 프로세스
CHAPTER 8 스타일 가이드와 규칙
조직 내부 코드베이스를 관리하는 규직은 어디든 존재한다
규칙은 법이다.
지침은 권장사항과 모법사례를 이야기함
따르는 편이 이득이라 어지간하면 따르라고 권한다
코드의 지속 가능성을 높이도록 이끄는것
규칙이 필요한 이유
좋은 행동을 장례하고 나쁜 행동을 억제하기 위함
조직에 따라 좋고 나쁨은 틀릴수 있다
규칙 만들기
규칙을 만들때 어떤 규칙이 필요하지? 가 아니라 어떤 목표가 필요하지로 잡근 하는게 좋다
기본 원칙
규칙을 만들때 염두해 두어야 하는 일
- 규칙의 양을 최소화 한다
- 코드를 읽는 사람에게 맞춘다
- 일관되어야 한다
- 오류가 나기 쉽거나 예상치 못한 동작을 유발하는 구조를 피한다
- 꼭 필요하다면 실용성을 생각해 예외를 허용해라
스타일 가이드
- 위험을 피하기 위한 규칙
- 모법 사례를 적용하기 위한 규칙
- 일관성을 보장하기 위한 규칙
- 무엇을 선택했냐 보다 선택했다는 사실에 의의를 둠
규칙 수정하기
엔지니어들이 규칙을 우회하는데 애를 쓰고 있으면 그 규칙에 기대했던 트레이드오프를 재검토해야됨
프로세스
스타일 가이드 수정 프로세스는 해법을 중심으로 돌아간다
문제가 주어지면 현시점에서는 다른 결론에 도달할 수 있는지를 다시평가
스타일 중재자
구글의 스타일 가이드들은 언어별로 소유자가 따로 있어서 최종 결정과 승인을 책임진다.
예외
스타일 가이드의 규칙은 법과 같지만 일부 규칙은 예외를 허용한다.
규칙을 따르기보다 예외를 인정하는 쪽이 이득이라고 판단될 때만 예외를 허용
지침
지침에는 복잡한 주제에 관한 길고 깊은 논의부터 권장하는 모범사례에 관한 짧고 집중적인 조언까지 다양하다
규칙 적용하기
규칙을 정해도 적용하지 않으면 의미가 없다
규칙을 강제하는 방법으로는 교육과 훈련을 통한 사회적인 방법과 도구를 이용한 기술적인 방법이 있다
- 오류 검사기
- 코드 포멧터