[번역] 전 구글직원을 위한 개발도구 가이드
구글내 개발환경 익숙한 개발자가 퇴사후 다른 회사에 갈때의 개발도구들
원본URL: An ex-Googler's guide to dev tools (sourcegraph.com)
몇 년 전, 나는 구글에서 짧은 프로젝트를 수행했습니다. 그 이후로 많은 변화가 있었지만 Google의 내부 개발자 도구에 대한 짧은 노출조차도 나에게 지속적인 인상을 남겼습니다. 여러 면에서 Google 내부의 개발 도구는 세계에서 가장 진보된 도구입니다. Google은 자체 소프트웨어 시스템을 확장하는 데뿐만 아니라 규모의 소프트웨어를 효과적으로 구축하는 방법을 파악하는 선구자였습니다. 코드베이스 볼륨, 코드 검색 가능성, 조직 지식 공유 및 다중 서비스 배포와 관련된 문제를 대부분의 다른 회사가 아직 도달하지 못한 정교함 수준에서 처리했습니다. (참조, 구글에서 소프트웨어 엔지니어링을참조하십시오 .)
그러나, 다른 방법으로 구글의 내부 개발도구들은 특히 거의 모든 사람들이 Google의 고유한 내부 생태계와 긴밀하게 결합되어 있습니다. 불행히도, 그것은 당신이 떠날 때 당신과 함께 그들을 데려 갈 수 없다는 것을 의미합니다.
'Google 디아스포라'는 세계 최고의 기술 조직 중 한 곳에서 일하면서 배운 교훈을 제공하는 놀라운 재능있는 사람들과 함께 많은 다른 조직을 시드했습니다. 그러나 Google 외부에서 프로그래밍에 적응하는 것은 어려울 수 있습니다, 당신이 당신의 처분에 더 이상 없는 도구에 의존하게 된 경우에 특히 그렇습니다.
수년에 걸쳐, 나는 내 자신의 경험과 구글을 떠난 다른 많은 사람들의 경험에서 배웠습니다. 그래프의 초기 고객의 대부분은 구글을 떠난 후 전 구글어 누락 코드 검색으로 시작했다. 저는 이 사람들과 긴밀히 협력하여 그들이 채우려는 격차를 이해하여 그들의 필요를 충족시키기 위해 Sourcegraph을 구축할 수 있었습니다. 시간이 지남에 따라, 패턴은 전 Google에서 개발자 도구에 대한 자신의 경험에서 영감을 자신의 조직에 새로운 개발 도구를 도입하고자하는 방법의 관점에서 등장. 일부는 성공적이었고 다른 사람들은 성공하지 못했습니다.
나는 실용주의와 실용성에 대한 눈으로 작성 전 구글의 외부 도구를 개발하는 가이드를 작성하는 것이 도움이 될 것이라고 생각했다. 의심의 여지가 많은 전 구글 그들은 단순히 그들의 새로운 회사에 구글 내부 개발 도구 생태계를 복제 할 수 있기를 바랍니다, 하지만 당신은 바다를 끓일 수 없습니다. 다음은 여러분이 시작해야 할 위치와 전 Google가 그들을 만드는 도구와 새로운 팀을 가능한 한 생산적인 도구로 찾기 위해 취할 수 있는 일반적인 경로입니다.
소프트웨어 개발 수명 주기
최근에 다른 회사에 가입하기 위해 Google을 떠난 경우 예전만큼 생산적이지 않다는 전반적인 좌절감을 느낄 수 있습니다. 당신은 당신이 뭔가를변경해야한다고 생각하지만, 그것은 무엇입니까? 첫 번째 단계로, 당신은 당신이 매일 무엇을하는지에 대해 생각하고 고통이 어디에서 오는지 확인해야합니다.
구글 내부와 외부 모두, 소프트웨어 개발 수명 주기는 다음과 같이 보인다 :
빌드하려는 기능이나 수정해야 하는 버그를 생각해 보십시오.
많은 코드를 읽고, 문서를 디자인하고, 동료에게 질문을 합니다. 문제와 솔루션이 기존 시스템에 어떻게 부합하는지 에 대한 이해를 구축하고 있습니다.
코드 작성을 시작합니다. 당신은 단지 작업 뭔가를 먼저 목표로. 이 작업을 수행하는 동안 다시 돌아가 서 문서를 찾거나 몇 번 더 코드를 읽으십시오.
당신은 그것을 작동, 하지만 당신은 발송 할 준비가 되지 않았습니다. 이제 수정하고, 몇 가지 더 많은 테스트를 추가하고, 코드를 리팩터링하여 다음 사람이 더 깨끗하고 쉽게 이해할 수 있도록 몇 가지 테스트를 위반했습니다. 당신은 분기까지 밀어. CI가 실행될 때까지 기다렸다가 몇 가지 추가 수정 사항과 작은 개선 사항을 구현할 수 있습니다.
검토를 위해 패치를 제출합니다. 팀원들은 몇 가지 의견을 남깁니다. 변경합니다. 어쩌면 검토자가 변경을 승인하기 전에 몇 라운드가 있을 수 있습니다.
패치를 병합하고 배포됩니다.
제자리에 있는 모니터링 시스템은 생산 문제가 있는지 여부를 결정합니다. 중단을 일으킨 패치인 경우 패치를 수정할 수 있습니다.
이 프로세스의 모든 단계에서는 일반적으로 개발자 환경을 고정하는 도구가 있습니다. 도구는 작업 주기를 형성하고 생산성에 엄청난 영향을 미칩니다.
생산성을 향상하려면 더 나은 도구를 찾아야 합니다. Google 내부의 거의 모든 도구와 Google 외부에서 가장 가까운 유사한 도구를 식별하는 유용한 GitHub 리포지토리가 d있습니다.
https://github.com/jhuangtw/xg2xg. 이 목록은 포괄적이지만 약간 압도적입니다. 그렇다면 어디서부터 시작해야 할까요?
첫 달: 새로운 도구가 없으며 기존 도구를 배우십시오.
첫 달에는 아무 것도 변경하지 마십시오. 그냥 바로 개발을 배울 수 없습니다. 팀의 새 구성원으로서 팀이 사용하는 모든 도구를 변경할 수 있는 영향이나 권한이 없을 수 있습니다. 또한 새로운 팀이 어떻게 그리고 왜 행동하는지, 그리고 현재 도구 집합을 사용하는 이유에 대한 지식도 부족합니다. 단순히 Google에서 일한 모든 것을 복사붙여 두는 것이 반드시 새 팀에서 작동하는 것은 아닙니다. 그래서 새로운 팀에 대 한 작동 하는 것을 하지 않는 것과 함께 배울 것이 있습니다.
먼저 해내기 쉬운 것들 먼저하기
나는 코드 검색이 일반적으로 시작하는 좋은 도구라고 생각합니다. 예, 나는 코드 검색 회사의 공동 설립자입니다, 그래서 물론 나는 말할 것이다, 하지만 여기에 내 이유가 있습니다 -이 당신과 함께 공명하지 않는 경우, 나는 다음 섹션으로 건너 뛰는 것이 좋습니다!
그것은 도구 전 구글 일반적으로 그들의 일상 생활에서 가장 그리워 중 하나입니다.
다른 코드 검색 엔진을 직접 시도하고 다른 코드와 공유하기 전에 좋은 지 확인할 수 있습니다. 즉, 게이트키퍼의 승인을 받거나 귀중한 사회적 자본을 소비하여 다른 사람들이 자신을 사용하지 않은 도구를 시도하도록 설득할 필요가 없습니다.
새 팀에 코드 검색 도구가 아직 없기 때문에 다른 사용자가 기존 습관을 변경하도록 강요할 필요는 없습니다. 그들이 할 경우, 그것은 나쁜 중 하나, 그들은 그것을 많이 사용하지 않습니다, 또는 좋은 당신은 이미 좋은 코드 검색을 가지고, 그래서이 섹션을 건너 뜁니다!
새 회사에 조직에 몇 개 이상의 팀이 있는 경우 개인으로서 합리적으로 grok을 사용할 수 있는 코드를 더 많이 처리할 수 있습니다. 그리고 훨씬 더 작은 회사에서 일하더라도 종속성을 통해 수많은 오픈 소스 코드를 끌어당길 가능성이 있습니다. 이 코드는 새 기능을 빌드하거나 중요한 버그의 원인을 추적할 때 어느 시점에서 다이빙해야 하는 모든 코드입니다.
거의 모든 개발자가 요즘 처리해야 하는 코드의 규모를 감안할 때 코드 검색이 부족하면 개발 속도가 크롤링 속도가 빠르게 느려질 수 있다는 것은 당연합니다.
코드 검색 엔진을 평가할 때 고려해야 할 몇 가지 사항이 있습니다.
쿼리 언어: 정규 식은 테이블 스테이크입니다. 코드 검색 쿼리 언어가 표현력이 있고 사용하기 쉬운지 확인하려고 합니다. 리터럴 검색은 직관적이어야 하며 고급 패턴 일치를 사용할 수 있어야 합니다.
배율 : 코드 검색 엔진이 코드베이스 크기로 확장되었는지 확인합니다. 코드베이스가 몇 기가바이트 이상인 경우 코드 검색 엔진이 https://swtch.com/~rsc/regexp/regexp4.html trigram 인덱스를 사용하는지 여부가 가장 중요한 이유는 큰 코드베이스의 배율에서 정규 식 일치를 얻는 방법입니다.
코드 브라우징: Google 코드 검색 사용자로서 검색이 스토리의 절반에 불과하다는 것을 알 수 있습니다. 결과를 클릭하면 클릭하여 정의로 이동하고 코드를 체크 아웃하고 IDE에서 개발 환경을 설정한 것처럼 쉽게 참조를 찾을 수 있습니다. * 훌륭한 코드 브라우징없이, 당신은 자주 편집기와 코드 검색 엔진 사이의 컨텍스트 전환될 것입니다.
권한: 회사에서 코드베이스 권한을 적용하는 경우 코드 검색 엔진이 코드 베이스 권한을 준수하는지 여부를 고려해야 합니다.
전체 비용: 코드 검색 엔진의 가격과 도구를 온라인 상태로 유지하는 유지 관리 오버헤드를 모두 고려하십시오. 사용 중인 일반적인 코드 검색 엔진은 다음과 같습니다.
* OpenGrok : 이제 오라클에 의해 유지 되는 상당히 오래되었지만 영구 코드 검색 엔진
* 하운드
: Etsy의 엔지니어가 만든 코드 검색 엔진이 만들고 오픈 소스
: 스트라이프에서 넬슨 엘하지에 의해 만들어진 코드 검색 엔진
추가로 소스 그래프 이 있습니다.
좋은 모니터링 받기
개발 대상에 대한 또 다른 좋은 초기 영역은 모니터링입니다. 어떤 시점에서 모든 엔지니어는 생산 문제를 처리해야합니다. 생산은 개발과는 매우 다른 장소이며 중단점을 설정하거나 인쇄물을 추가하고 몇 초 만에 효과를 볼 수 없습니다. 컴퓨팅 리소스, 개발자 시간 및 최악의 경우 사용자와 고객에게 고통을 주어 프로덕션 업데이트가 비용이 많이 듭니다.
프로그램 배포는 지난 5-10년 동안 많이 변경되었습니다. 마이크로 서비스, Kubernetes, 클라우드로 이동 -이 기업이 소프트웨어를 배포하는 방법에 큰 변화입니다. 많은 기업들이 이러한 새로운 패러다임과 기술을 채택했지만, 이러한 새로운 생산 환경에서 디버깅을 쉽게 하기 위해 아직 모니터링 인프라를 업데이트하지 않았습니다.
다행히도, 구글 외부 세계에서 모니터링 및 관찰의 상태를 크게 개선 한 최근 몇 년 동안 몇 가지 좋은 새로운 오픈 소스 도구와 회사가 있었다.
* 프로메테우스는 보르그몬과 유사한 타임시리즈 메트릭 트래커이자 시각화도우미입니다. 응용 프로그램을 계측하여 시간이 지남에 따라 변경되는 CPU 사용률, 오류 율 및 p90 대기 시간과 같은 메트릭을 추적할 수 있습니다.
* 그라파나 는 바이스로이와 유사한 대시보드 도구입니다. 일반적인 상황은 Grafana와 Prometheus를 연결하는 것이므로 전체 응용 프로그램 상태를 나타내는 여러 가지 주요 메트릭의 단일 페이지 보기를 구성할 수 있습니다.
Google은 Dapper와 함께 점점 더 일반적인 다중 서비스 아키텍처를 위한 필수 도구인 분산 추적을 개척했습니다. Dapper의 제작자 중 한 명인 벤 시겔만은 라이트스텝을시작했습니다. 분산 추적은 이제 허니콤, 센트리 와 같은 유료 오퍼링과 Uber 엔지니어가 구축한 예거(Jaeger)와같은 오픈 소스 프로젝트를 포함한 많은 모니터링 시스템의 특징입니다.
모니터링은 프로덕션 환경에 통합되어야 하기 때문에 코드 검색보다 도입하기가 약간 까다롭습니다. 여기에는 배포 환경을 변경하는 경우가 많으며, 이는 배포 환경을 제어하는 팀을 설득하는 것을 의미합니다. 계측되는 코드를 소유한 다양한 팀에 패치를 제출하는 계측 코드를 추가할 수도 있습니다. 그러나 새로운 도구를 도입하는 것은 기존 습관을 바꿀 사람이 필요하지 않다는 점에서 여전히 쉽습니다. 사람들은 도구를 처음 배포하려고 할 때 강력한 이의 를 제거하는 새로운 도구를 자유롭게 사용할 수 있습니다.
당신이 좋은 곳에서 꼭 할 것 : 코드 검토
코드 검색 및 모니터링을 도입해도 팀의 모든 사람에게 기존 워크플로를 변경하도록 요청할 필요는 없습니다. 그러나 코드 검토 도구를 변경합니다.
기회는 당신이 잠시 동안 구글에 있었다면, 코드 검토가 구글 외부에서 수행되는 방법은 조금 이상한 당신을 강타했다. GitHub 풀 요청은 가장 일반적인 코드 검토 도구이지만, 전 Google는 일반적으로 그것에 대해 몇 가지 불만이 있습니다.
그것은 간단하지 않고 때로는 리뷰의 마지막 라운드 이후 변경 사항을 볼 수 없습니다. 쉬운 경로는 전체 뛰어난 diff를 검토 할 수 있습니다.
누적된 CR에 대한 지원은 없습니다.
변경 집합의 모든 파일에 대한 전체 diff가 하나의 거대한 페이지로 표시되며 검토한 덩어리를 추적하기가 어렵습니다.
GitHub PR은 리뷰를 수행하는 방법에 대해 매우 의견이 없습니다. 타사 통합을 추가하지 않으면 검토 프로세스가 느슨해 보일 수 있으며 타사 통합이 있더라도 더 세분화된 검토 및 사인오프 정책을 시행할 수 없습니다.
특정 언어에 대한 제한된 퍼지 점프 - 투 - 데프 또는 찾기 참조가 있지만, 비판이 구글 내부에서 지원하는 수준에 가까운 곳은 없습니다.
당신이 구글의 외부 얻을 수있는 비판에 가장 가까운 것은 Gerrit입니다. 게릿은 리트벨드의 포크로 인생을 시작했는데, 그 자체는 구글의 원래 코드 리뷰 도구인 몬드리안의 오픈소스 포크였습니다. 따라서 Google이 코드 검토를 수행하는 정확한 방식을 지원하기 위해 만들어진 도구 라인에서 내려오므로 매우 친숙해져야 합니다.
Phabricator는 전 Googlers종종 GitHub 끌어 오기 요청을 선호하는 또 다른 코드 검토 도구입니다. Phabricator는 페이스 북의 내부 코드 검토 도구로 생활을 시작하고 이후 오픈 소스및 외부 세계에 발표되었다. 또한 호스트 인스턴스와 지원을 제공하는 Phacility 뒤에 회사가 있습니다.
조사 가치가있는 또 다른 도구는 전 GoogleR 피오트르 카민스키에 의해 만들어진 검토 할 수 있습니다. Gerrit 또는 Phabricator와는 달리 클라우드 전용이지만 오늘날 Google 내부에서 수행하는 것과 가장 가까운 코드 검토 환경을 제공할 수 있습니다.
Gerrit, Phabricator 또는 팀의 나머지 팀에 검토 가능한 이점을 판매할 때, 팀이 기존 코드 검토 도구로 느끼는 기존 고통을 식별하는 것이 중요합니다. 다음은 GitHub-Pull-Request와 같은 도구에서 Gerrit 와 같은 도구로 전환하여 몇 가지 일반적인 통증 지점을 해결하는 방법입니다.
Gerrit는 명시적 사인오프를 통해 보다 체계적인 검토 프로세스를 용이하게 하며, 팀을 성장시키고 조직 전체에 더 엄격한 검토 정책을 적용하려는 경우 좋을 수 있습니다.
Gerrit을 사용하면 파일별로 파일을 이동하고, 마지막 검토 라운드 이후의 변경 내용을 보고, CRs를 스택할 수 있으므로 더 큰 diffs를 쉽게 검토할 수 있습니다. 이를 통해 더 빠르고 철저한 검토를 수행할 수 있습니다.
Gerrit, Phabricator 및 Reviewable을 사용하면 Google 내부에 있었던 일반적인 검토 흐름을 면밀히 근사하게 할 수 있지만 코드 인텔리전스를 제공하지 않는 한 가지는 코드 인텔리전스입니다. 현재 코드 검토 도구에 코드 인텔리전스가 없거나 GitHub PR 코드 인텔리전스가 부족한 경우 Sourcegraph 브라우저 확장 을 시도해 보십시오. 이렇게 하면 소스그래프 인스턴스에 연결되어 코드 검토 중에 도구 설명, 점프 투-데프 및 상호 참조를 제공합니다. GitHub PR, GitLab MR, 파브리케이터 및 비트 버킷 서버와 함께 작동합니다. 게릿에 대한 지원이 진행 중입니다.
최종적으로 드래곤을 죽을 준비 (최종 결과)
소프트웨어 개발 수명 주기에서 가장 난해할 수 없는 부분은 종종 CI와 빌드 시스템입니다. 빌드를 이해하려면 전체 코드베이스의 모든 부분을 상당히 미묘한 차이로 이해하는 경우가 많기 때문입니다. 빌드 속도를 높이는 것은 다양한 사람들이 시간이 지남에 따라 하려고 하는 일이므로 빌드 코드는 실제로 부정적인 결과가 전혀 없는 변화에 대해 충분히 이해하는 사람들의 수가 매우 작은 지점에 도달할 때까지 증가하는 해킹 및 최적화 집합을 발생시킵니다.
요컨대, 빌드 시스템은 종종 큰 거대한 헤어볼이며, 낮은 매달려 개발자 생산성 과일을 선택하기 전에 분열하려고주의해야합니다. 블레이즈는 당신이 지금 사용하는 것보다 더 나은 세계였고 구글은 심지어 도움이 베이젤라는 블레이즈의 파생 상품을 오픈 소스했기 때문에, 이 문제를 해결하기 위해 유혹 할 수있다. 그러나 Bazel은 Blaze가 아닙니다 - 하나는, 그것은 함께 무료로 제공되는 대규모 분산 빌드 클러스터가 부족합니다 - 구글 외부의 세계는 구글이 아닙니다.
바젤은 은색 총알이 아닙니다. Bazel이 처음 출시되었을 때 Go 커뮤니티의 많은 오픈 소스 프로젝트는 표준 Go 빌드 도구를 사용하여 사용으로 전환했습니다. 그러나 1 년 이내에 이러한 중 많은 사람들이 사용의 복잡성, Go 커뮤니티의 나머지 부분에서 익숙하지 않고 빌드가 실제로 Bazel으로 느려진 것처럼 보였기 때문에 다시 전환되었습니다. 그 이후로 바젤의 Go 지원에 큰 개선이 있었지만, 바젤을 교체하면 어떤 개선 사항이 있는지 엄격하게 평가해야 합니다.
이 엄격한 평가를 수행하려면 이미 다른 훌륭한 개발 도구가 많이 준비되어 있어야 합니다. 특히 코드베이스의 여러 부분에서 빌드 스크립트를 실제로 탐색하고 해당 코드베이스의 삽입 및 아웃을 이해할 수 있으므로 훌륭한 코드 검색을 원할 수 있습니다. 빌드 시스템을 변경하는 것은 여러 엔지니어링 팀의 승인이 필요한 복잡한 변경이 될 것이기 때문에 훌륭한 코드 검토 도구를 배치해야 합니다.
드래곤을 죽일 준비가 되면 대규모 코드베이스에서 확장 가능한 빌드를 사용하도록 설계된 Bazel 외에도 여러 빌드 도구가 있다는 것을 이해해야 합니다. 여기에는 다음이 포함됩니다.
* Buck
, from Facebook
* Gradle
, popular in the Java world
* Pants
, created by an ex-Googler originally for Twitter and Foursquare
* Please
, a newish build tool created by ex-Googlers, heavily inspired by Blaze
블레이즈에서 크게 영감을 전 구글에 의해 만들어진 새로운 빌드 도구 또한 사용자 베이스가 있다, 빌드 도구, 하지만 CI 서비스 구글 의 외부 세계에 슈퍼 빠르고 확장 가능한 빌드를 가지고 전 구글 R 이브 Junqueira에 의해 시작, 어떤 기본 빌드 도구가 사용 되는 것과 는 별개입니다.
모든 것들을 위한 것
Google은 대부분의 다른 회사와 달리 개발자 경험과 개발자 도구의 우선 순위를 지정합니다. Google사용자 및 전직 Google사용자들은 타고난 재능과 능력에 엄청난 레버리지를 추가하는 일류 개발 도구를 직접 사용한 경험을 제공합니다.
Google을 떠난 후 경쟁 우위 중 하나는 이러한 경험을 적용하여 새로운 조직에 훌륭한 새로운 개발 도구를 적용하여 자신의 생산성과 팀원의 생산성을 높이는 것입니다. 이러한 도구를 사용하여 소프트웨어 개발을 위한 효과적인 모범 사례를 대규모로 확산함으로써 Google의 주요 경쟁 우위 중 하나인 엔지니어링 조직의 효율성(새로운 회사에 가져올 수 있습니다)을 가져올 수 있습니다.
규모의 소프트웨어를 구축하는 것은 어렵습니다. 신화맨의 달을읽은 모든 사람들이 알다시피, 당신은 더 많은 엔지니어를 고용하여 더 나은 소프트웨어를 얻을 수 없습니다. 더 나은 도구가 필요합니다. 소프트웨어가 최종 사용자의 생산성을 높이는 것처럼 개발자 도구는 소프트웨어를 구축하는 사람들의 생산성을 높이는 승수입니다. 따라서 새로운 회사의 사명을 진정으로 믿는다면, 특별한 지식을 전 Googler로 사용하고 사용할 수 있는 최고의 개발자 도구를 제공하는 것이 우선 순위 중 하나입니다.
