google practice / 통일화 / 어떻게 빠르게 / 소프트웨어 엔지니어링 / best practices / 코드리뷰 / 빌드 시스템 / 린팅 linting / lint / build system/ google way / code review / 코드, 소프트웨어 엔지니어링
구글에서 사용하는 방식
소프트웨어 엔니지이렁 at goolge 책 내용 일부
- What I learned from Software Engineering at Google | Swizec Teller
- stub, mock 보다 fake 를 사용하자, 이 fake 는 그 담당자 가 만든다.
- 자주 배포한다. 적은 변화량이 디버깅이나 되돌리기 좋다.
- 매일, 매시간 등으로 자동으로 배포하도록 구성한다
- dependency 에 대한 업그레이드 도 마찬가지다.
- 만약 여럿이 사용하는 코드를 자신의 코드를 변경했다면, 당신이 그 코드와 관련된 코드를 변경해라. 당신이 가장 잘 알며, 당신이 함수를 deprecated 로 만들어서 다른 사람에게 업그레이드를 요청해도 그들은 굳이 하지 않는다.
협업 방식(코딩표준, 빌드시스템, 통신, linting, 코드리뷰)
- What I learned from Software Engineering at Google : programming
- https://www.reddit.com/r/programming/comments/om5afz/what_i_learned_from_software_engineering_at_google/h5jzwla?utm_source=share&utm_medium=web2x&context=3
면책 조항: 저는 공개적으로 알려진 Google 관행을 사용한 경험에 대해 말하는 Google 엔지니어입니다. 나는 나 자신 외에 어떤 것도 대표하지 않는다.
Microsoft와 같은 다른 대기업과 비교하여 Google 엔지니어링 방식에서 가장 극단적인 측면은 회사의 균일성입니다. 몇 개의 프로젝트 외에도 모든 프로젝트의 전체 코드베이스는 동일한 규칙과 프로세스를 가진 하나의 큰 저장소에 있습니다. 이는 엔지니어가 회사에 합류할 때 기여하는 데 시간이 더 오래 걸리지만 초기 단계 이후에는 훨씬 더 빠르게 회사의 모든 제품에 대한 코드를 기여할 수 있음을 의미합니다. 이것은 다른 팀이 만든 구성 요소 간의 통합, 한 팀이 다른 팀과 위기의 시간을 강화하고, 다른 팀이 소유한 코드를 수정하고, 다른 팀이 작성한 코드가 작동하는 방식을 배우고, 팀을 전환하는 데 도움이 됩니다.
이 균일성은 다음과 같은 여러 측면이 있습니다.
코딩 표준: 회사에는 하나의 표준이 있습니다. 언어마다 세부 정보가 있지만 Google에서 Java를 작성하면 작업 중인 프로젝트에 관계없이 동일하게 보일 것입니다. 코딩 표준은 상세하고 합리적입니다(기술 변화에 따라 시간이 지남에 따라 진화합니다). 다른 방식으로 코드를 작성하고 표준이 마음에 들지 않더라도 단일 진실을 갖는 것은 코드 검토 마찰을 줄입니다.
균일한 코드 저장소: 대부분의 Google 코드는 하나의 거대한 가상 저장소에 있습니다. 다른 제품은 단순히 저장소의 디렉토리입니다. repo에 등록할 때 로컬로 복사하지 않습니다. 변경되지 않은 파일은 변경해야 할 때까지 가상으로 액세스됩니다. 빌드 시스템은 빌드 대상도 캐시하므로 코드를 변경하지 않은 경우 제품 바이너리를 다시 빌드하지 않고도 쉽게 사용할 수 있습니다.
균일한 빌드 시스템: Google은 다른 언어에 대해서도 동일한 make 파일과 동일한 빌드 시스템을 사용합니다. 때로는 동일한 make 파일에서도 다른 언어가 지정됩니다. 빌드/실행/테스트를 위한 구문은 제품 전반에 걸쳐 동일하며 인프라 코드의 검사 테스트는 인프라 소비자의 테스트를 자동으로 실행합니다.
균일한 저장 및 통신: 무엇이든 저장하거나 통신해야 하는 경우 유일한 답은 프로토버퍼입니다. 다른 것을 사용하려면 정말 설득력 있는 근거가 필요합니다. 이를 통해 언어, 제품, 팀 및 구성 요소 간에 스토리지, 통신 및 rpc가 원활하게 이루어집니다. Protobufs는 기본적으로 모든 것과 이에 능숙한 모든 엔지니어 간의 인터페이스입니다. Google에서 사용하는 모든 언어에 동일한 protobuf를 빌드할 수 있으므로 언어 간 코드를 쉽게 만들 수 있습니다.
Linting: 코드 표준과 빌드 시스템이 균일하기 때문에 Linting에 대한 투자가 증가하면 회사 전체에 이익이 됩니다. 강력한 Linting은 코드 검토 마찰을 더욱 줄여줍니다.
코드 리뷰는 "코드 소유권"(code ownership)과 "언어 능숙함"(language proficiency)(가독성)으로 나뉩니다. 때로는 같은 사람이지만 코드 소유자가 "언어에 가장 능숙한 사람"이지 않은 경우가 많습니다. 이 시나리오에서 한 사람은 제품에 어떤 것이 좋은지 말하고 다른 사람은 일반 코드가 좋은지 말할 것입니다. 이 명확한 구분은 코드 품질과 균일성이 유지되도록 합니다.
소규모 기업은 때때로 유사한 문제(예: 여러 언어 사용 또는 제품 간 통합)를 겪지 않기 때문에 이러한 요소의 대부분은 대기업에 도움이 됩니다. 그러나 그들은 대규모 엔지니어링의 어려운 문제 중 일부에 대한 훌륭한 솔루션입니다.
댓글 없음:
댓글 쓰기