- 코드를 지속적으로 사용하기 위해서는 가이드라인을 만드는 것이 필요함.
- 가이드라인에는 프로그래머들이 개발할 때 반드시 지켜야할 규칙들을 포함시켜야 함.
- 이 장에서는 Google의 개발 규칙 및 지침에 대한 원칙과 프로세스에 대해 설명함.
Good - 조직이 추구하는 목표에 맞는 것 ( i.e 런타임 최적화, 메모리 사용 감소)
Bad - 조직이 추구하는 목표에 맞지 않거나, 일관되지 않은 것
장점
- 공통적인 코드스타일을 사용하면 엔지니어가 코드를 설명하는 것보다 코드가 무엇을 말하는지에 집중할 수 있음.
- 규칙을 정하므로써, 엔지니어는 무의식적으로 회사가 원하는 방향으로 개발 패턴을 따르는 경향이 있음.
아래와 같은 것을 고려하며, 코드 스타일이 제공할 목표를 정의하면 유용한 코드 스타일 및 규칙을 쉽게 정할 수 있다.
- "우리가 앞으로 나아가려고 하는 목표는 무엇입니까?"
- "코드스타일에 어떤 규칙이 들어가는 이유가 무엇입니까?"
- "코드스타일을 통해 회사가 얻는것은 무엇입니까?"
Google 코드스타일 규칙의 목표는 개발 환경의 복잡성을 관리하고, 코드베이스를 관리 가능한 상태로 유지하면서
엔지니어가 생산적으로 작업할 수 있도록 하는 목표를 달성하기 위해 다음과 같은 코드스타일 규칙을 정의했다.
- Pull their weight
- Optimize for the reader
- Be consistent
- Avoid error-prone and surprising constructs
- Concede to practicalities when necessary
무의미한 규칙을 많이 생성하지 않는다. 단순히 몇명만이 필요한 규칙을 공통의 규칙으로 명시화하지 않는다. 만약 그렇게 하게 된다면, 규칙들이 너무 많이 생겨 오히려 방해가 될 수 있다.
코드를 쓰는 사람보다 읽는 사람에게 더 친숙하게 코드를 짜라.
구글에서는 변수명이나 함수명을 엄청 길게 써야할지라도 코드를 읽는 사람이
직관적으로 이해할 수 있게 하기 위해 프로그래머는 기꺼이 그렇게 해야 된다.
여러 팀에서 개발을 진행하지만, 개발 스타일은 모두 일관성있게 작성하도록 노력해야 한다. 예를 들어, 개발하는데 있어 사용하는 UTILS LIB 또는 API는 구글 개발자들이 공통으로 사용하는 것을 쓰도록 노력해야 한다.
- 코드가 일관되면, 코드가 이해되도록 작성하는 것에 몰두하는 것보다 해당 기능을 구현하는 것에 더 집중할 수 있음.
- 코드가 일관되면, 코드를 이해, 편집 및 생성할 수 있는 Tool을 더 쉽게 구축할 수 있음.
- 코드가 일관되면, 새로운 사람들이 들어와서 일을 더 빠르게 업무에 적응할 수 있음.
- 코드가 일관되면, 사람들이 쉽게 해당 코드에 진입할 수 있기 때문에, 업무 수행을 할 수 있는 팀을 꾸리는 것에도 용이함.
때로는 코드 가이드를 정할때 내부 의견만 듣지 말고, 외부의 의견도 반영해라.
구조가 좋을지라도 친숙하지 않은 독특한 구조의 코드를 제한한다.
독특한 구조의 코드는 당시에는 좋을수 있지만, 시간이 지나면 그 코드의 의미를 잃어버릴 수 있기 때문에
사용하지 않도록 한다.
필요한 경우 예외케이스를 만들어라.
코드 규칙을 무조건적 만족시킬순 없으므로, 무조건 규칙을 따르는 것이 아니라 필요시 예외 규칙을 만들어라.
구글 스타일 가이드의 큰 범주 3가지를 소개한다.
구글은 표준 라이브러리 사용에 있어 버그를 유발할 수 있는것들에 대해 사용 가이드를 정해놓는다. 해당 가이드에는 결정을 한 이유와 목표를 명시한다.
코드 사용의 사례를 명시한다.
예를 들어, 작성자의 코드를 사용할 때, 동작, 변수, 설명에 대한 주석을
달아야하는지에 대한 여부, 주석 위치가 포함된 가장 좋은 예시를 코드상에 포함시킨다.
코드의 일관성을 위해 변수, 함수, 클래스, 파라미터 명명 규칙, 들여쓰기 간격 가져오기 순서와 같은 것들을 정한다.
구글의 가이드라인을 따르려 하지 말고, 본인들의 프로젝트에 맞는 가이드라인을 찾길 바랍니다.
코드 가이드는 바뀌어야 한다.
예를 들어, 새로운 뭔가가 생겨 기존의 규칙이 개발자들에게 시간을 단축시켜줄 수 있다던가 하는 경우
기존의 규칙을 변경하여 새로운 규칙을 만들 필요가 있다.
구글에서는 목표로하는 코드베이스의 수명과 확장성을 고려했을때, 스타일가이드가 변경되어야 된다는 것을
인식해 스타일가이드를 업데이트하는 일련의 프로세스를 구축함.
- 실제 코드베이스 상에서 기존으 규칙이 문제를 일으키는 경우에만 구글 엔지니어 커뮤니티에 변경 제안을 올린다.
- 커뮤니티에서는 수많은 엔지니어들이 이것에 관해 충분한 토론을 거친다.
- 실제 언어 사용자로부터 피드백을 받는다.
- 커뮤니티 합의에 의해 개선사항에 대한 평가를 받은 뒤, 또 다시 최종 의사 결정을 거쳐 반영된다.
구글에서는 style arbiters를 두어 기존의 코드 가이드라인을 지키는 선에서 스타일 가이드들이 변화되도록 중재한다.
구글에서는 4명의 c++ style arbiter가 있고, 짝수의 사람들 사이에서 합당하다고
결정되어야 스타일 가이드가 수정된다고 한다.
구글에서 규칙은 일반적으로 더 크고 일반적인 경우를 위해 설계되었지만, 때로는 특정 상황에서 특정 규칙에 대한 예외를 만든다. 이런 예외 케이스의 경우 스타일 중재자와 협의하여 예외를 승인하는 유효한 사례가 있는지 검토 후 여부를 결정합니다.
예를 들어, 프로젝트 별 네임스페이스를 사용해야하는데 이를 예외케이스로 만들자는 경우 거부될 수 있다.
Guidence는 사람들이 스타일 가이드에 맞춰 코드를 작성하는데 있어 자주 실수하거나 놓치는 부분,
또는 코드를 잘 작성하는 노하우들을 설명하는 자료이다. 스타일 가이드의 경우 반드시 따라야 되지만,
Guidence의 경우 하면 좋다 정도의 수준으로 받아들인다고 한다.
다음과 같은것들이 Guidence에 포한된다고 한다.
- 일반적으로 수정하기 더 어려운 영역에 대한 언어별 조언(예: 동시성 및 해싱).
- 언어 업데이트와 함께 도입된 새로운 기능에 대한 자세한 분석과 코드베이스 내에서 사용하는 방법에 대한 조언.
- 당사 라이브러리에서 제공하는 주요 추상화 및 데이터 구조 목록. 이것은 이미 존재하는 구조를 다시 만드는 것을 막고 "라이브러리가 특정 기능을 제공하는지 여부를 제공합니다.
구글에서는 실제로 규칙들이 적용되기 위해 많은 노력들은 한다고 한다.
- 신입사원의 경우 Style Guide와 권장사항들을 가르치는 교육기간이 있다.
- 다양한 자료들을 최신화 하기 위해 리소스들을 투자하고 있다.
- 멘토들이 코드 review를 통해 Style Guide에 대한 이해와 전반적인 교육을 도와준다.
Error Checker는 개발한 코드가 일련의 Rule에 적합한지 검사하는 도구를 말한다.
구글에서는 Error Checker를 활용하여 개발자들이 실제로 잘 짜여진 코드를 만들어냈는지 일일히 확인하는 수고를
덜었고, 규칙 적용 프로세스를 자동화 했다고 한다.
Code Formatter는 구글에서 사용하고 있는 Code Style에 맞게 코드를 변경해주는 도구를 말한다.
구글에서는 Code Formatter를 통해 개발자들이 사소한 코드 스타일을 맞추기 위해 시간을 지연하지 않도록 하고, 코드를 공유하기 전에 Code Formatter가 수행됐는지 확인한다고 한다.
저자는 구글과 같이 큰 규모의 코드를 관리하는 집단이 Code Rule과 Style을 정의하므로써
코드를 지속가능하게 만들 수 있다고 얘기하고 있다.
Code Rule이나 Style 프로세스를 구축하는 것은
모든 회사에게 필수적인 것으로 생각된다.
- 우리 회사가 앞으로 나아가려고 하는 목표는 무엇인가?
- 그 목표를 수행하기 위해서는 어떤 Code Style과 Rule을 적용해야 되는가?
- Error Checker와 Code Formatter를 구축할 필요가 있는가?