대부분 엔지니어링 조직에는 내부 코드베이스를 관리하는 규칙이 있다. 예) 소스코드를 저장하는 위치, 코드 포맷팅, 명명 방식, 패턴, 예외와 스레드 사용법 등을 규정한다. 규칙은 제안이나 권장사항이 아닌 엄격하고 꼭 지켜야하는 법이다. 한편 지침은 권장사항과 모범 사례를 말한다.
구글에는 코딩할 때 따라야하는 규칙들을 모아서 프로그래밍 스타일 가이드로 정리해 표준으로 삼았다. 이 스타일 가이드는 구글의 코드를 지배하는 종합적인 규약 모음집이다.
8.1 규칙이 필요한 이유
규칙을 관리하는 목표는 좋은 행동을 장려하고 나쁜 행동을 억제하기 위함이다. 좋은, 나쁜의 해석은 관심사가 다르기 때문에 조직마다 차이가 있다.
가장 먼저 조직이 추구하는 가치를 파악해야 한다. 무엇을 장려하거나 억제할지를 규정하는 규칙과 지침은 그 가치를 기준으로 정해진다.
확립된 규칙과 지침은 조직이 커지더라도 일관되게 통용되는 공통의 코딩 어휘가 되어 준다. 어휘가 통일되면 엔지니어들은 코드를 표현하는 형식보다 코드에 담을 내용에 집중할 수 있다.
8.2 규칙 만들기
규칙을 정의할 때는 어떤 목표를 이루려하는지에 집중해야 한다.
8.2.1 기본 원칙 안내
규칙을 만들 때 염두에 두어야 하는 중요한 원칙들은 다음과 같다.
- 규칙의 양을 최소화 한다
- 코드를 읽는 사람에게 맞춘다.
- 일관되어야 한다.
- 오류가 나기 쉽거나 예상치 못한 동작을 유발하는 구조를 피한다.
- 꼭 필요하다면 실용성을 생각해 예외를 허용한다.
1)규칙의 양을 최소화 한다
조직 내 모든 엔지니어가 새로운 규칙들을 익히고 적응하는 데는 비용이 든다. 규칙이 너무 많다면 엔지니어들이 다 기억하지도 못 할 것이고 새로 합류한 엔지니어가 적응하기도 어렵다.
2)읽는 사람에게 맞춘다
코드 작성자보다 읽는 사람에 최적화해야 한다. 작성되는 횟수보다 읽히는 횟수가 더 많으며 시간이 지날수록 차이가 벌어진다. 따라서 읽기 난해한 것보다 타이핑하기 지루한 편이 낫다. 독자 중심주의의 일환으로 구글은 엔지니어가 의도한 행위를 분명하게 알려주는 증거를 코드에 남기라고 요구한다.
3)일관되어야 한다
4)일관성이 안겨주는 이점
코드베이스의 스타일과 기준이 일관되면 코드를 작성하는 엔지니어와 읽는 이들은 어떻게 표현하느냐가 아닌 무엇을 수행하느냐에 집중할 수 있다. 또 일관성은 규모를 확장하기 쉽게 도와준다. 조직 확장에는 도구 활용이 핵심이며 코드가 일관되면 코드를 이해하고 수정하고 생성하는 도구를 더 쉽게 만들 수 있다.
그리고 조직이 성장하면서 같은 코드베이스를 공유하는 엔지니어의 수도 늘어나는데 이때 코드를 가능한한 일관성 있게 관리하면 엔지니어들이 새로운 팀으로 옮겨 적응 하는 시간이 단축된다. 그 결과로 조직의 필요에 맞게 인력을 유연하게 재배치할 수 있다. 또 시간이 흐르면서 엔지니어 일부가 프로젝트를 떠나고 새로운 인력이 합류하게 되도 코드가 일관성이 있으면 이런 전환 비용이 낮아지고 코드와 엔지니어 모두 거의 제약 없이 재배치될 수 있다.
5)표준 정하기
스타일 가이드는 과학적이고 기술적인 선택보다 지역적인 규약에 따르라고 명시한 규칙이 많다. 해당 영역에서의 일관성을 더 중요하게 생각하기 때문이다.
일반적으로 규약은 바깥세상과 일관되게 잡는 편이 유리하다. 작고 독립적이고 수명이 짧은 코드라면 내부의 일관성이 중요하고, 수명이 길고 확장될 가능성이 큰 코드라면 널리 쓰이는 표준을 따르는 게 유리하다.
6)오류를 내기 쉽거나 예상과 다르게 동작할 여지가 있는 구조는 피하자
복잡한 기능에는 미묘한 함정이 숨어있는 경우가 많다. 따라서 정확하게 이해하지 못한 채 사용하면 그 복잡성 때문에 오용하여 버그를 유발하기 쉽다. 심지어 정확히 이해하고 사용했다고 해도 나중에 합류한 팀원이나 유지보수를 맡은 엔지니어도 같은 수준으로 이해할지는 보장할 수 없다.
이로 인해 구글의 파이썬 스타일 가이드에서는 리플렉션 등 몇가지 고급 기능을 사용하지 못하게 제한하고 있다.
7)실용적 측면을 인정하자
스타일 가이드의 규칙들에 때로는 예외가 필요하다는 것을 잘 알고 있다. 따라서 꼭 필요하다면 최적화나 실용성을 위해 예외를 허용한다.
8.2.2 스타일 가이드
모든 스타일 가이드 규칙은 세 범주로 나눌 수 있다.
- 위험을 피하기 위한 규칙 - 구글의 스타일 가이드에는 기술적인 이유 때문에 반드시 써야 하거나 쓰면 안 되는 언어 특성들에 관한 규칙들이 담겨있다. 어떤 언어 특성은 사용하고 어떤 구조는 피해야 하는지를 설명하는 규칙들이다.
- 모범 사례를 적용하기 위한 규칙 - 코드 작성 시 모범 사례를 반드시 따르도록 강제하는 규칙도 담겨있다. 이런 규칙들은 코드베이스를 건실하고 관리 가능하게 지켜준다. (주석 관련 규칙들, 소스파일의 구조도, 명명 규칙…), 또 새롭거나 아직 널리 이해되지 못한 언어 기능을 제한하기도 한다.
- 일관성을 보장하기 위한 규칙 - 구글 스타일 가이드에는 사소한 문제를 다루는 규칙도 많다. 이 규칙들의 목적은 단순히 결정을 내리고 그 결정을 문서로 남기는 것이다. 사소한 것으로 어떻게 할지 시간 낭비를 하지 않고 더 중요한 일에 시선을 돌릴 수 있다.
8.3 규칙 수정하기
세월이 흐르면 기존 결정이 내려질 당시와는 내부 사정이 달라지고 결정에 영향을 준 요인들도 변할 수 있다. 만약 엔지니어들이 특정 규칙을 우회하는 데 에너지를 쓰고 있다면 그 규칙에 기대했던 트레이드오프를 재검토해야 할 것이다. 모든 규칙을 유용하고 최신 상태로 유지하려면 업데이트가 필요한 규칙이 무엇인지를 적시에 알아챌 수 있어야 한다.
구글 스타일 가이드의 규칙에는 각각의 결정을 뒷받침하는 근거를 명시해뒀다. 규칙을 추가할 때는 장단점과 잠재적인 파장을 분석하고 결정을 실행하는 데 수반되는 변경량이 구글 규모에서는 무리가 없는지 검증하는 데 많은 시간을 사용한다. 각 결정에 이른 근거를 문서로 남겨두면 규칙을 변경해야 할 때가 언제인지를 알아내기 쉬워진다는 이점이 있다.
사례) 221p
8.3.1 프로세스
구글이 추구하는 긴 수명과 확장 가능성을 감안하여 변경해야할 것이 있는지를 찾아내고 갱신하는 프로세스를 수립했다. 스타일 가이드의 수정 제안의 형식은 먼저 현재 문제를 찾아내 설명한 다음 해법을 보여준다. 이 때 문제는 현존하는 구글 코드에서 발견된 패턴으로 입증해야 한다.
규칙이 수정되어야 할 시점을 알아차리기에는 스타일 가이드에 입각해 코드를 작성하는 엔지니어들의 커뮤니티가 가장 유리할 것이다. 실제로도 스타일 가이드 수정 대부분이 커뮤니티에서의 토론으로부터 출발한다.
8.3.2 스타일 중재자
구글 스타일 가이드들은 언어별로 소유자가 따로 있어서 최종 결정과 승인을 책임진다. 이 소유자들을 스타일 중재자라고 부른다. 프로그래밍 언어별로 경험 많은 전문가 그룹이 스타일 가이드를 소유하고 결정권자 역할을 한다.
그리고 제안된 수정은 엔지니어링 측면에서 트레이드 오프를 논의하여 결정하며 스타일 가이드가 지향하는 목표에 입각하여 판단한다. (개인의 취향이 아닌 트레이드 오프가 기준이 됨)
8.3.3 예외
규칙을 따르기보다 예외를 인정하는 쪽이 이득이라고 판단될 때만 예외를 허용한다.
8.4 지침
규칙과 더불어 구글은 다양한 형태의 프로그래밍 지침도 관리한다. 지침이란 구글의 엔지니어링 경험에서 선별한 지혜이자 과거로부터 배운 교훈들로부터 추린 모범 사례들을 문서로 남긴 것이다. 지침은 주로 사람들이 자주 실수하는 것 혹은 아직 익수치 않는 새로운 주제라서 혼란스러워하는 것들에 집중한다.
8.5 규칙 적용하기
규칙을 강제하는 방법으로 교육과 훈련을 통한 사회적인 방법과 도구를 이용한 기술적인 방법이 있다. 구글은 다양한 정규 교육을 운영하고 있다. 또 엔지니어들이 규칙을 인지하고 이해하도록 하기 위해 구글의 훈련 프로그램의 중심에는 코드 리뷰가 자리한다.
도구를 활용해서 규칙이 실제로 잘 지켜지는지 확인할 수도 있다. 도구를 사용하면 전에 없던 규칙이 생겼을 때도 모든 프로젝트의 모든 엔지니어가 규칙들을 잘 준수하는지 알 수 있다.
하지만 도구를 활용하더라도 모든 규칙을 강제로 적용하기는 불가능할 수 있다. 때로는 사람이 판단해야만 하는 규칙도 있기 때문이다. 그리고 기술보다는 사회적 문제를 다루는 규칙도 있으며 사회적 문제를 기술적 시각으로 해결하려 드는 것은 현명하지 않다. 하지만 기술적 문제를 다루는 규칙이라면 가능한 한 기술적으로 자동 집행되게 하는 걸 선호한다.
8.5.1 오류 검사기
언어 사용법과 관련한 규칙들의 상당수는 정적 분석 도구로 강제할 수 있다. 이런 도구를 활용하면 코드 작성자는 적용해야 할 규칙을 모두 숙지해야 하는 부담을 덜 수 있다. 또 어떻게 고쳐야 할지도 함께 제시해주니 규칙을 준수하는 비용을 낮출 수 있다.
8.5.2 코드 포맷터
구글은 코드의 형식을 일관되게 관리하기 위해 자동 스타일 검사기와 포맷터를 적극 이용한다. 그래서 엔지니어들은 로직 구현에만 집중하면 된다.
구글은 프리서브밋 검사로 포맷터를 반드시 사용하게 한다. 코드를 리포지토리로 서브밋 하기 전에 빌드 인프라의 서비스가 포맷터를 수행하여 서브밋할 코드와 차이가 있는지 비교한다.
8.6 마치며
큰 조직이라면 코드 베이스의 복잡성을 관리하여 감당할 수 있는 수준으로 유지하는 데 규칙이 큰 도움이 된다. 규칙 모음은 엔지니어링 프로세스에 기준을 잡아주어 코드베이스를 계속 확장하고 성장할 수 있게 해 준다.
8.7 핵심 정리
- 규칙과 지침의 목표는 시간과 확장 관점에서의 탄력성을 높이는 것이어야 한다.
- 상황이 변하면 규칙도 달라져야 하니 규칙이 만들어진 근거 데이터를 알고 있어야 한다.
- 모든 것을 규칙으로 강제해서는 안 된다.
- 일관성이 핵심이다.
- 가능한 한 규칙들이 자동으로 적용되도록 해야 한다.