[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 8)

728x90

CH.8 스타일 가이드와 규칙

대부분의 엔지니어링 조직에는 내부 코드베이스를 관리하는 규칙이 있고 구글도 마찬가지다. 프로그래밍 스타일 가이드를 통해 코딩할 때 따라야 하는 혹은 하지 말아야 하는 규칙을 모아서 정리했으며 프로그래밍 언어별로 관리한다.

8.1 규칙이 필요한 이유

목표는 '좋은' 행동을 장려하고 '나쁜'행동을 억제하기 위함이다. '좋은'과 '나쁜'의 해석은 조직마다 차이가 있으며 따라서 조직이 가장 먼저 추구하는 가치를 파악한 뒤, 규칙과 지침을 정해야 한다.

8.2 규칙 만들기

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

8.2.1 기본 원칙 안내

모든 조직에 필요한 가치는 규모와 시간 양쪽 측면에서 탄력적인 엔지니어링 환경이 지속되도록 하는 것이다. 이런 배경에서 목표는 개발 환경의 복잡도를 관리하고 엔지니어들의 생산성을 희생하지 않는 선에서 코드베이스를 관리 가능하게끔 유지하는 것이다.

다만 여기서 트레이드오프가 발생한다. 규칙 중 상당수가 엔지니어들의 자유를 제한한다는 점이다. 하지만 표준은 일관성을 높여주고 의견 대립을 줄여주므로 혜택이 더 크다. 이러한관점에서 중요한 원칙들은 다음과 같다.

규칙의 양을 최소화한다
규칙이 많으면 다 기억도 못할뿐더러 새로 합류한 엔지니어가 적응하기 어렵고 관리 비용도 커진다. 따라서 너무 자명한 규칙은 의도적으로 배제한다.

읽는 사람에게 맞춘다
코드는 작성되는 횟수보다 읽히는 횟수가 더 많으며 시간이 지날수록 차이가 벌어진다.

일관되어야 한다
코드가 일관되게 작성되어 있다면 엔지니어들은 익숙지 않은 부분을 살펴볼 일이 생겨도 상당히 빠르게 작업을 이어갈 수 있다.

일관성이 안겨주는 이점
'어떻게' 표현하느냐가 아닌 '무엇을' 수행하느냐에 집중할 수 있으며 규모를 확장하기 쉽게 도와준다.

표준 정하기
조직 내 규약을 만들어 고수하는 것만으로는 충분하지 않을 때가 있어서 때로는 외부 커뮤니티에서 정착된 표준도 고려해야 한다.

오류를 내기 쉽거나 예상과 다르게 동작할 여지가 있는 구조는 피하자
복잡한 기능에는 미묘한 함정이 숨어 있는 경우가 많아서 버그를 유발하기 쉽다.

실용적 측면을 인정하자
일관되고 단순한 코드베이스를 추구한다고해서 그 외의 모든 것을 맹목적으로 무시하기를 원하지는 않는다.

8.2.2 스타일 가이드

다음은 언어 스타일 가이드에 들어가야 할 3가지 규칙이다.

위험 회피하기
기본적으로 기술적인 이유 때문에 반드시 써야 하거나 쓰면 안 되는 언어 특성들에 관한 규칙들이 담겨 있다.

모범 사례 강제하기
코드베이스를 건실하고 관리 가능하게 지켜준다. 예를 들어 주석을 어디에 어떻게 작성해야 하는지를 명시한다.

일관성 구축하기
규칙 중 상당수는 기술적으로는 별다른 영향이 없다. (ex. 들여쓰기 공백 수) 하나를 선택하여 더 중요한 일로 시선을 돌릴 수 있게 했다.

그 외...
가이드 문서만으로 초심자를 숙련자 수준까지 끌어올릴 수는 없으므로 모든 것을 집어넣지는 않았다.

8.3 규칙 수정하기

구글 스타일 가이드의 규칙에는 각각의 결정을 뒷받침하는 근거를 명시해뒀다. 근거를 문서로 남겨둠으로써 규칙을 변경해야 할 때가 언제인지를 알아내기 쉬워진다는 이점이 있다.

8.3.1 프로세스

긴 수명과 확장 가능성을 위해 변경해야 할 게 있는지를 찾아내고 갱신하는 프로세스를 수립하였다.

8.3.2 스타일 중재자

언어별로 소유자가 따로 있어서 최종 결정과 승인을 책임지는데 이들을 스타일 중재자라고 부른다. 개인의 취향이 아닌 트레이드오프가 기준이 되며 스타일 가이드 수정은 투표가 아니라 합의로 이루어진다.

8.3.3 예외

일부 규칙은 예외를 허용한다. 규칙을 따르기보다 예외를 인정하는 쪽이 이득이라고 판단될 때만 예외를 허용한다.

8.4 지침

규칙과 더불어, 다양한 형태의 프로그래밍 지침도 관리한다. 지침이란 구글의 엔지니어링 경험에서 선별한 지혜이자 과거로부터 배운 교훈들로부터 추린 모범 사례들을 문서로 남긴 것이다. 지침은 주로 사람들이 자주 실수하는 것 혹은 아직 익숙지 않은 새로운 주제라서 혼란스러워하는 것들에 집중한다. 규칙이 반드시 지켜야 하는 것이라면 지침은 되도록 따라야 하는 것이다.

8.5 규칙 적용하기

규칙을 정해도 적용하지 않으면 의미가 없다. 규칙을 강제하는 방법으로는 교육과 훈련을 통한 사회적인 방법과 도구를 이용한 기술적인 방법이 있다.

사회적인 방법: 정규 교육 및 훈련 프로그램(ex. 코드 리뷰)
기술적인 방법: 자동화 도구

하지만 때로는 사람이 판단해야만 하는 규칙도 있다. (ex. 너무 뻔하거나 중요하지 않은 타입은 굳이 이름을 짓지 말고 auto를 허용하라)

8.5.1 오류 검사기

C++ 스타일 가이드의 규칙 중 90%는 자동으로 검증할 수 있다고 한다. 따라서 코드 분석기를 활용하면 규칙을 준수하는 비용을 크게 줄일 수 있다.

8.5.2 코드 포맷터

구글은 코드의 형식을 일관되게 관리하기 위해 자동 스타일 검사기와 포맷터를 적극 이용한다. 그래서 한 라인의 길이로 몇 글자가 적당할지는 더 이상 논의거리가 되지 않으며 이런 일은 그저 스타일 검사기에 맡기고 엔지니어들은 로직 구현에 집중하면 된다.

구글은 프리서브밋 검사(서브밋 직전 검사)로 포맷터를 반드시 사용하게 한다. 차이가 있다면 해다 ㅇ서브밋을 거부되며, 이때 거부 메시지에 코드 포맷터 사용법 안내가 포함되어 전달된다.

8.6 마치며

규칙은 복잡성을 관리하는데 큰 도움이 되고 프로세스에 기준을 잡아주어 코드베이스를 계속 확장하고 성장할 수 있게 해준다.

8.7 핵심정리

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