소프트웨어 버그로 인해 개발자와 소프트웨어 회사에는 많은 시간과 비용이 소요됩니다. 2014년을 예로 들면, 널리 사용되는 SSL 프로토콜 구현의 ("goto failure") 버그로 인해 유효하지 않은 SSL 인증서가 승인되고 날짜 형식과 관련된 또 다른 버그로 인해 Twitter에서 광범위한 서비스 중단이 발생했습니다. 이러한 오류는 정적 분석을 통해 감지되는 경우가 많습니다. 실제로 코드나 문서를 읽는 동안 빠르게 식별할 수 있으며, 최종 현실은 프로덕션 환경에서 이러한 상황이 여전히 발생한다는 것입니다.
이전 작업에서는 소프트웨어 개발에 버그 탐지 도구를 적용한 경험이 잘 보고되어 있습니다. 그러나 정적 분석 도구를 사용하여 개발자가 성공한 사례가 너무 많지만 엔지니어가 항상 정적 분석 도구를 사용하려고 하지 않거나 도구에서 생성된 경고 정보를 적극적으로 무시하지 않는 데에는 다음과 같은 이유가 있습니다.
제대로 통합되지 않음 . 도구가 개발자의 작업 흐름에 통합되지 않았거나 프로그램 실행에 너무 오랜 시간이 걸립니다.
잘못된 경고입니다. 알림 정보의 타당성이 낮습니다.
신뢰할 수 없습니다. 오탐으로 인해 사용자는 더 이상 결과를 신뢰하지 않습니다.
결함의 실제 활용 시나리오는 불분명합니다. 신고된 버그는 이론적으로는 가능하지만 실제 활용 시나리오에서는 결함이 명확하지 않습니다.
수리 비용이 너무 높습니다. 감지된 코드 결함을 수정하는 것은 비용이 너무 많이 들거나 위험합니다.
경고는 이해하기 어렵습니다. 사용자는 알람 정보의 구체적인 내용과 원리를 이해하지 못합니다.
다음 기사에서는 Google의 이전 경험과 Java 언어 분석 및 학술 문헌을 위한 FindBug 사용에서 얻은 교훈을 설명하고 마침내 Google의 소프트웨어 엔지니어가 일상적으로 사용할 수 있는 정적 분석 인프라 아키텍처를 성공적으로 구축했습니다. Google 도구는 엔지니어의 의견을 바탕으로 문제가 있는 코드가 회사 전체의 코드 저장소에 병합되기 전에 엔지니어가 매일 수정하는 수천 가지 문제를 감지할 수 있습니다.
도구 범위 측면에서 우리는 정적 분석을 Google의 핵심 개발 프로세스에 통합하고 대다수의 Google 개발자에게 서비스를 제공하는 데 중점을 둡니다. 많은 정적 코드 분석 도구는 Google에 배포된 20억 줄의 코드에 비해 작아질 것이므로 대규모 시나리오에서 복잡한 분석을 실행하는 기술은 우선 순위가 높지 않습니다.
물론 전문 분야(예: 항공우주, 의료 장비 분야)에서 작업하는 Google 외부 개발자가 특정 정적 분석 도구 및 워크플로를 사용할 수 있다는 점을 고려해야 합니다. 또한 특정 유형(예: 커널 코드 및 장치 드라이버)과 관련된 개발 프로젝트를 수행하는 개발자는 특정 분석 방법이 필요할 수 있습니다. 정적 분석에서 우수한 결과가 많이 나왔습니다. 우리는 우리가 보고한 경험과 통찰력이 독특하다고 믿지 않지만, Google의 코드 품질과 개발 경험을 향상시키는 데 우리의 작업을 정리하고 공유하는 것이 유익하다고 굳게 믿습니다. .
용어의 정의. 우리는 용어에 대해 다음과 같은 정의를 사용합니다. 분석 도구는 소스 코드에서 하나 이상의 "검사기"를 실행하고 소프트웨어 오류를 나타낼 수 있는 "결함"을 식별합니다. 개발자가 문제를 확인한 후 사전 조치를 취하지 못한 경우, 개발자가 식별된 결함을 발견하고 적절한 수정을 취하지 않으면 이를 "실제 오탐지"로 간주합니다. 정적 분석이 보고된 결함을 정확하게 식별하지 못하지만 개발자가 가독성과 유지 관리성을 향상시키기 위해 코드를 수정하는 조치를 적극적으로 취하는 경우 이는 유효한 "오탐지"가 아닙니다. 분석 결과 실제 코드 오류가 보고되었지만 개발자가 코드 문제를 이해하지 못하고 아무런 조치도 취하지 않은 경우 이는 "실제 오탐"으로 간주됩니다. 우리는 R&D 관점의 중요성을 강조하기 위해 이러한 개념적 구별을 사용합니다. 도구 작성자가 아닌 개발자는 도구의 오탐률을 인식하고 직접적인 영향을 미칩니다.
아래에서는 Google 소프트웨어 개발 프로세스의 핵심 사항을 간략하게 설명합니다. Google에서는 거의 모든 개발 도구(개발 환경 제외)가 중앙 집중화되고 표준화되어 있습니다. 인프라의 많은 부분은 내부 팀이 소유한 스크래치로 구축되어 실험적 유연성을 유지합니다.
소스 코드 제어 및 코드 소유권. Google은 단일 소스 코드 관리 시스템을 개발하여 사용하고 있습니다. 그리고 거의 모든 Google 독점 코드를 저장하는 단일 분기로 실험해 보세요. 개발자는 종종 기능이 아닌 릴리스로 구분되는 분기를 제한하는 "트렁크 기반" 개발 접근 방식을 사용합니다. 모든 엔지니어는 코드 소유자의 승인을 받아 코드를 변경할 수 있습니다. 코드 소유권은 경로를 기반으로 합니다. 디렉터리 소유자는 하위 디렉터리에 대해 동일한 권한을 갖습니다.
시스템 구축. Google 코드 베이스의 모든 코드는 컴파일 독립적인 Bazel 버전으로 컴파일됩니다. 즉, 빌드의 쉬운 배포 및 병렬화를 용이하게 하려면 모든 입력을 명시적으로 선언하고 소스 제어에 저장해야 합니다. Google 빌드 시스템의 Java 규칙은 JDK 및 소스 제어 Java 컴파일러에 의존하며 이러한 바이너리는 새 버전을 신속하게 도입하여 모든 사용자를 위해 업데이트될 수 있습니다. 빌드는 일반적으로 소스(헤드를 통해)에서 제공되며 바이너리 구성 요소를 분기에 체크인하는 경우는 거의 없습니다. 모든 개발자가 동일한 빌드 시스템을 사용하기 때문에 모든 코드는 오류 없이 성공적으로 컴파일될 수 있습니다.
분석 도구. Google에서 사용하는 정적 분석 도구는 일반적으로 복잡하지 않습니다. Google 인프라는 이 수준의 시스템에서 절차 간 또는 프로그램 기반 무결성 분석 실행을 지원하지 않으며 대규모 고급 정적 분석 기술(예: 분리 논리 기술)을 사용하지도 않습니다. 간단한 검사기라도 워크플로우에 통합을 지원하려면 분석 인프라가 필요합니다. 일반 개발 프로세스의 일부로 배포된 분석기 유형은 다음과 같습니다.
스타일 검사기(예: Checkstyle, Pylint 및 Golint)
확장 가능한 버그 찾기 컴파일러(예: Error Prone, ClangTidy, Clang) 추상 구문 트리 패턴 일치 도구, 유형 기반 검사기, 호출되지 않은 변수를 감지하는 분석기를 포함하되 이에 국한되지 않는 Thread SafetyAnalytics, Govet 및 CheckerFramework).
프로덕션 서비스의 프로파일러를 호출합니다(예: 코드 주석에 언급된 직원이 여전히 Google에서 근무하는지 확인).
빌드 출력의 속성(예: 출력 바이너리 크기)을 확인합니다.
Google의 C++ 린터는 if 문 뒤에 괄호가 있는지 확인하여 'goto failure' 취약점을 포착할 수 있습니다. 패턴 일치 기반 검사기는 날짜 형식 오류를 식별하므로 Twitter를 충돌시킨 코드는 Google과 컴파일되지 않습니다. Google 개발자는 또한 AddressSanitizer와 같은 동적 분석 도구를 사용하여 버퍼 취약점을 찾고 ThreadSanitizer를 사용하여 데이터 경합 문제를 찾습니다. 이러한 도구는 테스트 중에 실행되며 때로는 프로덕션 트래픽이 있는 환경에서도 실행됩니다.
통합 개발 환경(IDE). 개발 프로세스 초기에 정적 분석 문제에 대한 진입점은 IDE에 통합되는 것입니다. 하지만 Google 개발자는 다양한 편집기를 사용하므로 빌드 도구를 호출하기 전에 모든 개발자의 오류를 일관되게 감지하기가 어렵습니다. Google은 널리 사용되는 사내 IDE와 통합된 분석을 사용하지만, 분석할 수 있는 특정 IDE를 요구하는 것은 멀고 힘든 일입니다.
테스트 중입니다. 거의 모든 Google 코드에는 단위 테스트부터 대규모 통합 테스트까지 해당 테스트 링크가 포함되어 있습니다. 테스트 활동은 시스템 구축에 통합되어야 하는 첫 번째 개념입니다. 컴파일 프로세스와 마찬가지로 독립적이고 분산되어 있습니다. 대부분의 프로젝트에서 개발자는 코드에 대한 테스트 사례를 작성하고 유지 관리하며 일반적으로 별도의 테스트 또는 QA 그룹이 없습니다.
Google의 지속적인 빌드 및 테스트 시스템은 코드가 제출될 때마다 테스트를 실행하고 개발자의 코드 변경으로 인해 실패한 빌드 실패 또는 테스트 사례에 대해 적시에 피드백을 제공합니다. 또한 프로젝트 종속성이 깨지는 것을 방지하기 위해 커밋하기 전에 변경 사항 테스트를 지원합니다.
코드 검토. Google에 제출된 모든 코드는 먼저 코드 검토를 통과합니다. 모든 개발자는 Google 코드의 어느 부분이든 변경할 수 있지만 코드 소유자는 병합을 위해 변경사항을 제출하기 전에 변경사항을 검토하고 승인해야 합니다. 또한 코드 소유자라도 변경 사항을 커밋하기 전에 코드를 검토해야 합니다. 코드 검토는 다른 개발 인프라와 긴밀하게 통합된 중앙 집중식 웹 기반 도구를 통해 수행됩니다. 정적 분석 결과는 코드 리뷰에 표시될 수 있습니다.
코드 공개. Google 팀에서는 릴리스를 자주 출시하며, 대부분의 릴리스 확인 및 배포 프로세스가 '푸시 온 그린(push on green)' 방법을 통해 자동화됩니다. 즉, 힘든 수동 릴리스 확인 프로세스에 의존하기가 어렵습니다. Google 엔지니어가 프로덕션에서 버그를 발견하면 서비스 중단에 비해 상대적으로 저렴한 비용으로 새 버전을 롤백하여 프로덕션 서버에 배포할 수 있습니다.
2008년부터 2010년까지의 초기 탐색 연구 단계부터 Google의 정적 분석 기술은 메릴랜드 대학의 William Pugh와 펜실베니아 요크 대학의 David Hovemeyer가 만든 독립 도구인 FindBug를 사용하여 Java 분석에 중점을 두었습니다. 도구. 컴파일된 자바 클래스 파일을 분석해 버그를 유발할 수 있는 코드 구조 모델을 추출하는 것이 원칙이다. 2018년 1월 현재 FindBugs는 Google의 극소수 엔지니어가 사용하는 명령줄 도구일 뿐입니다. "BugBot"이라는 소규모 Google 팀은 원저자인 Pugh와 협력하여 FindBugs를 Google 개발 프로세스에 통합하려는 세 가지 주요 시도를 했습니다.
우리는 시도를 통해 다음 사항을 배웠습니다.
1번 시도: 버그 대시보드. 2006년 처음에 FindBugs는 중앙 집중식 도구에 통합되어 매일 밤 전체 Google 코드 베이스를 스캔하고 엔지니어가 대시보드를 통해 볼 수 있도록 결과를 기록했습니다. FindBugs는 Google의 Java 코드 베이스에서 수백 개의 오류를 발견했지만 오류 메시지 대시보드가 일상적인 개발 프로세스와 분리되어 있고 기존의 다른 정적 분석 결과와 통합할 수 없었기 때문에 대시보드는 거의 효과가 없었습니다.
2번째 시도: 버그 개선에 집중하세요.
그런 다음 BugBot 팀은 매일 밤 발견되는 새로운 문제를 수동으로 분류하고 상대적으로 중요한 버그 보고서를 식별하고 처리하기 시작했습니다. 2009년 5월, 수백 명의 Google 엔지니어가 FindBugs 경고 해결에 초점을 맞춘 전사적 "Fix it" 주간에 참여했습니다. 총 3,954개의 경고(총 9,473개 중 42%)가 검토되었지만 16%(640개)만이 수정되었습니다. 실제로 보고된 결과(1746개) 중 44%가 버그 피드백 추적을 위해 제출되었습니다. Fixit 캠페인을 통해 FindBugs가 발견한 문제 중 상당수가 실제 코드 결함이라는 사실이 확인되었지만, 상당수는 실제 수정을 보장할 만큼 중요하지 않았습니다. 대규모 환경에서는 문제를 수동으로 분류하고 버그 보고서를 제출하는 것이 어렵습니다.
3번째 시도: 코드 검토에 통합하세요. 다음으로 BugBot 팀은 이러한 시스템을 통합하고 구현했습니다. 검토자가 검토가 보류 중이라는 알림을 받으면 FindBugs가 자동으로 실행되고 스캔 결과가 코드 검토에 대한 주석으로 표시됩니다. 위의 코드 검토 팀은 이미 이것을 구현했습니다. 코딩 표준/스타일 문제를 해결하세요. Google 개발자는 신뢰성을 위해 오탐지를 무시하고 FindBugs 결과를 필터링할 수 있습니다. 이 도구는 새로운 FindBugs 경고만 표시하려고 시도하지만 때로는 잘못된 분류로 인해 이를 새로운 문제로 처리합니다. 2011년에 코드 검토 도구가 교체되었을 때 이 통합은 두 가지 이유로 종료되었습니다. 실제로 높은 오탐률로 인해 개발자는 도구에 대한 신뢰를 잃었고, 개발자가 필터링을 사용자 정의할 자유가 있어 모든 당사자가 분석에 의문을 제기하게 되었습니다. 결과는 일관성이 없습니다.
FindBugs 실험과 동시에 Google의 C++ 개발 프로세스는 Clang 컴파일러에 새로운 검사 규칙을 추가하여 지속적으로 개선되었습니다. Clang 팀은 수정 권장 사항 정보를 포함한 새로운 컴파일러 검사기를 구현하고, ClangMR을 사용하여 분산 접근 방식으로 전체 Google 코드베이스에 걸쳐 업데이트된 컴파일러 최적화 검사를 실행하고, 코드베이스 질문의 기존 버그에 대한 코딩된 구현 수정 사항을 구현했습니다. 코드베이스가 수정된 문제로 표시되면 Clang 팀은 새로운 문제를 컴파일러 오류(Clang 팀이 Google 개발자가 무시할 것이라고 판단한 경고 대신)로 표시하여 해결해야 하는 빌드를 중단하는 새로운 검사기를 적용합니다. 통과하다. Clang 팀은 이 전략을 통해 코드베이스 품질을 향상시키는 데 매우 성공적이었습니다.
우리는 이 아이디어를 따라 javac 컴파일러를 기반으로 Error Prone이라는 패턴 분석 기반의 간단하고 사용하기 쉬운 Java 정적 분석 도구를 구축했습니다. 처음 도입된 검사 규칙은 PreconditionsCheckNotNull이라고 하며, checkNotNull(uid, "uid) 대신 checkNotNull("uid is null", uid)과 같이 프로그램 실행 시작 시 메서드 감지 입력 매개 변수가 비어 있는지 여부를 감지하는 데 사용됩니다. null입니다.").
연속 빌드를 중단하지 않고 PreconditionsCheckNotNull과 같은 검사기를 실행하기 위해 Error Prone 팀은 이를 사용하여 JavacFlume이라는 FlumeJava 빌드를 사용하는 ClangMR과 유사한 javac 기반 MapReduce 프로그램을 사용하여 전체 코드 베이스에 대해 이러한 검사를 실행합니다. JavacFlume은 일련의 수정 제안을 생성하고 차이점을 비교한 다음 이를 수정을 위해 전체 코드 베이스에 적용합니다. Error Prone 팀은 내부 도구 Rosie를 사용하여 대규모 코드 변경 사항을 작은 변경 사항으로 나누고 각 변경 사항은 단일 프로젝트에만 영향을 미치며 이러한 변경 사항을 테스트하고 코드 검토를 위해 해당 팀에 보냅니다. 팀은 코드에 적용되는 수정 사항만 검토하고 포함이 승인된 경우에만 Rosie가 실제 변경 사항을 커밋합니다. 결국, 기존 문제에 대한 모든 수리 및 변경이 승인되었으며, 기존 결함도 모두 해결되었습니다. 팀은 공식적으로 컴파일러 오류 방법을 공개했습니다.
이 패치를 받은 개발자를 대상으로 설문 조사를 실시했을 때 코드에 통합된 수정 사항을 받은 개발자 중 57%가 이러한 정보를 받고 기뻐했으며 41%는 중립적이었습니다. 2%의 사람들만이 부정적인 반응을 보이며 다음과 같이 말했습니다. "이렇게 하면 내 작업량이 늘어날 뿐입니다."
컴파일 오류는 개발 프로세스 초기에 표시되며 개발자 작업 흐름에 통합됩니다. 우리는 컴파일 검사기를 확장하면 Google의 코드 품질이 효과적으로 향상된다는 사실을 발견했습니다. Error Prone의 검사는 바이트코드가 아닌 javac의 추상 구문 트리에 대해 내부적으로 작성되므로(FindBugs와 달리) 팀 외부의 개발자가 비교적 쉽게 검사를 수행할 수 있습니다. 이러한 외부 기여를 활용하는 것은 Error Prone의 전반적인 영향을 높이는 데 중요합니다. 2018년 1월 현재 162명의 저자가 733개의 체커를 기여했습니다.
Google의 중앙 집중식 빌드 시스템은 모든 빌드 프로세스와 빌드 결과를 기록하므로 모든 사용자가 지정된 기간 내에 오류 메시지를 볼 수 있도록 합니다. 최근 컴파일러 오류가 발생한 개발자와 동일한 문제에 대한 수정 권장 사항을 받은 개발자에게 설문조사 피드백을 보냈습니다. Google 개발자는 코드에 병합된 패치와 달리 컴파일 타임에 플래그가 지정된 문제가 더 중요한 버그를 포착한다고 믿습니다. 예를 들어 설문 조사 참가자는 문제의 74%가 컴파일 타임에 "실제 문제"로 플래그가 지정되었다고 믿었습니다. 병합된 코드에서 문제가 발견되었습니다. 또한 설문 조사 참가자들은 컴파일 시간에 발견된 문제 중 6%(병합 단계에서는 0%)를 "중요"로 평가했습니다. 이 결과는 "생존자 편향 효과"로 설명할 수 있습니다. 즉, 코드 제출 시 더 많은 비용이 드는 수단(예: 테스트 및 코드 검토)을 통해 버그가 발견될 가능성이 더 높습니다. 가능한 한 많은 검사를 컴파일러에 강제하는 것이 이러한 비용을 피하는 확실한 방법입니다.
작업 규모를 확장하기 위해 컴파일을 중단하는 것이 더 큰 작업이 되기 때문에 컴파일러에서 검사를 활성화하는 표준을 정의하여 엄격한 고음 모드로 설정했습니다. Google의 컴파일러 검사는 읽기 쉽고 실행 가능하며 수정하기 쉬워야 합니다(가능한 경우 오류 메시지에는 일반적으로 구현 가능한 수정 제안이 포함되어야 함). 유효한 오탐지가 발생하지 않아야 합니다(분석 작업이 실제로 올바른 빌드를 중단해서는 안 됨). 코드) 스타일이나 코딩 규칙 문제가 아닌 실제 버그만 보고합니다. 이러한 기준을 충족하는 분석기를 측정하는 주요 목표는 단순히 문제를 감지하는 것이 아니라 코드 베이스 전체에서 이러한 컴파일러 오류를 자동으로 수정하는 것입니다. 그러나 이러한 표준은 코드를 컴파일할 때 Error Prone 팀이 활성화할 수 있는 검사 범위를 제한합니다. 정확하게 감지하거나 보편적으로 수정할 수 없는 많은 문제가 여전히 우리 앞에 있습니다.
Error Prone 팀이 컴파일 타임에 문제를 감지하는 데 필요한 인프라를 구축하고 이 접근 방식이 효과적이라는 것을 입증한 후에는 영향이 큰 버그가 더 많이 발견되기를 바랍니다. 우리가 수행하는 컴파일러 오류 검사에 국한되며 Java 및 C++ 이외의 언어에 대한 분석 결과를 제공합니다. 정적 분석 결과의 두 번째 통합 진입점은 Google의 코드 검토 도구인 Critique입니다. 정적 분석 결과는 Tricorder를 사용하여 Google의 프로그램 분석 플랫폼인 Critique에 표시됩니다. 2018년 1월 현재 Google의 C++ 및 Java 버전에는 컴파일러 오류가 없으며 모든 분석 결과는 컴파일러 오류 또는 코드 검토 단계에서 표시됩니다.
컴파일 시간 검사와 달리 코드 검토 중에 표시되는 분석 결과는 최대 10%의 효과적인 오탐률을 허용합니다. 코드 검토 중에 예상되는 피드백이 항상 완벽한 것은 아니므로 개발자는 실제로 채택하기 전에 해당 수정 제안을 평가해야 합니다. 코드 감사 단계 중 Google 검사기는 다음 기준을 충족해야 합니다.
이해하기 쉽습니다. 엔지니어가 명확하고 이해하기 쉽습니다.
해당 솔루션은 실행 가능하고 수정하기 쉽습니다. 수정에는 컴파일러 검사 단계보다 더 많은 시간, 생각, 노력이 필요할 수 있으며 검사 결과에는 문제를 검증하는 방법에 대한 지침이 포함되어야 합니다.
유효 오탐률은 10% 미만입니다. 개발자는 검사기가 실제 버그를 90% 이상 발견하는 것이 코드 품질에 상당한 영향을 미친다고 느껴야 합니다. 발견된 문제로 인해 프로그램이 올바르게 실행되는 데 방해가 되지 않을 수 있지만 개발자는 문제를 심각하게 받아들이고 수정하도록 선택해야 합니다.
일부 문제는 컴파일러에 표시될 만큼 심각하지만 자동 수정을 줄이거나 개발하는 것은 불가능합니다. 예를 들어 일부 문제를 해결하려면 코드를 리팩터링해야 할 수도 있습니다. 이러한 검사를 컴파일러 오류로 활성화하려면 기존 구현을 수동으로 정리해야 하는데, 이는 Google만큼 큰 코드 기반에서는 가능하지 않습니다. 코드 검토에서 이러한 검사를 보여주는 분석 도구는 새로운 문제 발생을 방지하여 개발자가 적절한 수정 조치를 취할지 여부를 결정할 수 있도록 해줍니다. 코드 검토는 사양 문제나 최적화된 코드 단순화 등 상대적으로 중요하지 않은 문제를 보고하기에 좋은 시기이기도 합니다. 우리의 경험에 따르면 컴파일 단계 중 보고는 항상 개발자가 받아들이기 어렵고 빠르게 반복하고 디버깅하기가 더 어렵습니다. 예를 들어 도달할 수 없는 코드 경로에 대한 감지기는 디버깅을 위한 코드 블록을 방해할 수 있습니다. 그러나 코드 검토 중에 개발자는 코드를 완성하기 위해 신중하게 준비하고 있으며 가독성 및 스타일 세부 사항 문제에 대해 더 수용적입니다.
Tricorder는 쉽게 확장 가능하도록 설계되었으며 정적 및 동적 분석 도구를 포함한 다양한 유형의 프로그램 분석 도구를 지원합니다. 컴파일러 오류로 활성화할 수 없는 Tricorder의 일부 오류 발생 가능성 검사기를 보여줍니다. Error Prone은 ClangTidy라는 Tricorder와 통합되는 새로운 C++ 분석 구성 요소 세트도 만들었습니다. Tricorder 분석기의 보고서는 30개 이상의 언어로 결과를 지원하고 스타일 검사기와 같은 간단한 구문 분석을 지원하며 Java, JavaScript 및 C++에 대한 컴파일러 정보를 활용하고 생산 데이터(예: 현재 실행 중인 작업 할당에 대한 정보)와 직접 통합될 수 있습니다. Tricorder는 분석기 작성자를 위한 생태학적 플랫폼을 지원하고, 코드 검토 프로세스 중에 가능한 수정 사항을 강조하고, 분석기를 개선하고 분석기 개발자가 조치를 취할 수 있도록 피드백 채널을 제공하는 플러그인 모델이기 때문에 Google에서 계속 성공하고 있습니다. 긍정적 인 피드백.
사용자가 기여할 수 있도록 합니다. 2018년 1월 현재 Tricorder에는 146개의 분석기가 포함되어 있으며 그 중 125개는 Tricorder 팀 외부에서 제공되었으며 수백 가지 추가 검사(예: ErrorProne 및 ClangTidy 등 2개)를 위한 7개의 플러그인 시스템이 포함되어 있습니다.
검토자는 수정 제안을 제공하기 위해 노력합니다.
Tricorder 검사기는 코드 검토자 및 개발자에게 표시되는 합리적인 복구 제안과 함께 코드 검토 도구를 제공할 수 있습니다. 검토자는 분석 결과에서 "수정해 주세요" 버튼을 클릭하여 개발자에게 결함이 있는 코드를 수정하도록 요청할 수 있습니다. 검토자는 일반적으로 모든 의견(수동 및 자동 검색)이 처리될 때까지 코드 변경 사항 포함을 승인하지 않습니다.
사용자 피드백을 반복합니다. Tricorder는 "수정하세요" 버튼 외에도 검토자나 제안자가 클릭하여 분석 결과에 동의하지 않음을 나타낼 수 있는 "쓸모 없는" 버튼도 제공합니다. 클릭 동작은 자동으로 버그 추적기의 버그를 제출하고 분석기가 속한 팀을 가리킵니다. Tricorder 팀은 이러한 "쓸모 없는" 클릭을 추적하고 "수정해 주십시오"와 "쓸모 없는" 클릭 사이의 클릭 비율을 계산합니다. 분석기의 비율이 10%를 초과하면 Tricorder 팀은 작성자가 이를 개선할 때까지 분석기를 비활성화합니다. Tricorder 팀은 분석기를 영구적으로 비활성화하는 경우가 거의 없지만, 분석기 작성자가 번거롭고 쓸모없는 것으로 판명된 체커를 제거하고 수정할 때까지 일부 분석기를 비활성화했습니다(몇 가지 시나리오에서).
제출된 버그는 종종 분석기 성능을 향상시켜 이러한 분석기에 대한 개발자 만족도를 크게 높입니다. 예를 들어 Error Prone 팀은 2014년에 Guava에서 너무 많은 매개변수가 printf와 같은 함수에 전달될 때 플래그를 지정하는 검사를 개발했습니다. Printf와 유사한 함수는 실제로 모든 printf 지정자를 허용하지 않고 %S만 허용합니다. 일주일에 한 번씩 Error Prone 팀은 분석이 올바르지 않으며 버그 일치 코드의 형식 와일드카드 수가 실제로 전달된 인수 수와 실제로 일치한다고 주장하는 "멍청한" 버그를 받게 됩니다. 사용자가 %s 이외의 와일드카드 자리 표시자를 전달하려고 하면 어떤 경우에도 파서가 실제로 올바르지 않습니다. 그래서 팀은 코드 검사 설명 텍스트를 변경하여 함수가 %s 자리 표시자만 허용하고 해당 검사에 대한 오류가 더 이상 발생하지 않는다는 것을 직접적으로 명시했습니다.
Tricorder 사용 규모. 2018년 1월 현재 Tricorder는 하루에 약 50,000개의 코드 검토 변경 사항을 분석했습니다. 분석은 피크 시간 동안 초당 3회 수행됩니다. 리뷰어들은 하루에 5,000번 이상 "수정해주세요"를 클릭하고, 저자들은 하루에 약 3,000번 정도 자동 복구 솔루션을 적용합니다. Tricorder 분석기는 하루에 250개의 "쓸모 없는" 클릭에 대한 피드백을 받습니다.
코드 검토 분석의 성공은 Google 개발자 워크플로에서 '최적의 위치'를 차지하고 있음을 보여줍니다. 컴파일 시간에 표시되는 분석 결과는 심각한 문제를 계속 식별하기 위해 분석기에 의존하는 방식으로는 충족할 수 없는 상대적인 품질과 정확성을 가져야 합니다. 리뷰와 코드가 병합된 후 개발자는 변경에 대한 거부감이 커집니다. 결과적으로 개발자는 이미 테스트 및 릴리스되었으며 위험도가 낮고 덜 중요한 문제를 해결할 가능성이 낮은 코드를 변경하는 데 어려움을 겪고 있습니다. 소프트웨어 개발 조직의 다른 많은 분석 프로젝트(예: Android/iOS 앱에 대한 Facebook Infer 분석)도 분석 결과 보고를 위한 주요 진입점으로 코드 검토를 강조합니다.
Google 개발자가 Tricorder 분석기의 결과를 승인함에 따라 계속해서 분석기에 대한 추가 확장을 요청합니다. Tricorder는 프로젝트 수준에서 사용자 정의를 허용하고 개발 프로세스의 다른 지점에서 프레젠테이션 분석 결과를 추가하는 두 가지 방법으로 이 문제를 해결합니다. 이 섹션에서는 Google이 아직 더 정교한 분석을 핵심 개발 프로세스로 활용하지 못한 몇 가지 이유에 대해서도 논의합니다.
요청된 모든 분석기가 전체 Google 코드베이스에서 동일한 가치를 갖는 것은 아닙니다. 예를 들어 일부 분석기는 더 높은 오탐률과 관련되어 있으므로 상응하는 오탐률이 높은 검사기가 필요할 수 있습니다. 구성은 다음과 같습니다. 특정 프로젝트에서 활성화된 경우에만 유효합니다. 이러한 분석기는 올바른 팀에만 유용합니다.
이러한 요구 사항을 충족하기 위해 우리의 목표는 Tricorder를 사용자 정의할 수 있도록 만드는 것입니다. FindBugs에 대한 이전 사용자 정의 경험은 덜 효과적이었습니다. 사용자 수준 사용자 정의로 인해 팀 내에서 그리고 팀 간에 차별화가 발생하여 도구 사용이 감소했습니다. 각 사용자는 문제에 대해 서로 다른 관점을 볼 수 있으므로 동일한 프로젝트에 참여하는 모든 사람이 특정 문제를 볼 수 있도록 보장할 수는 없습니다. 개발자가 팀 코드에서 사용하지 않는 가져오기를 모두 제거하면 다른 개발자가 사용하지 않는 가져오기 제거에 대해 일관성이 없더라도 롤백에서 변경 사항이 빠르게 거부됩니다.
이러한 문제를 방지하기 위해 Tricorder는 프로젝트 수준에서만 구성을 허용하므로 특정 프로젝트를 변경하는 사람은 누구나 해당 프로젝트와 관련된 분석 결과에 대한 일관된 보기를 볼 수 있습니다. 결과 보기에서 일관성을 유지하면 여러 유형의 분석기가 다음 작업을 수행할 수 있습니다.
이진 결과 생성. 예를 들어 Tricorder에는 이전 버전과 호환되지 않는 변경 사항을 식별하는 프로토콜 버퍼 정의용 파서가 포함되어 있습니다. 이는 개발자 팀이 프로토콜 버퍼에 직렬화된 형식으로 지속적인 정보를 보장하기 위해 사용하지만, 이 형식으로 데이터를 저장하지 않는 팀에게는 성가신 일입니다. 또 다른 예는 특정 설정이나 코드 내 주석이 필요한 라이브러리나 언어 기능을 사용할 수 없는 프로젝트에 적합하지 않은 Guava 또는 Java 코드 구현에서 사용하도록 권장되는 분석기를 갖는 것입니다. 예를 들어 팀에서는 Checker Framework의 nullness만 사용하여 코드에 주석이 제대로 추가되었는지 분석할 수 있습니다. 적절하게 구성되면 특정 Android 바이너리의 바이너리 크기 및 함수 호출 횟수의 증가를 확인하고 증가가 예상되는지 또는 한계에 도달하는지 개발자에게 경고하는 또 다른 분석기
도메인별 언어 지원; (DSL) ) 및 팀별 코딩 지침을 참조하세요. 일부 Google 소프트웨어 개발 팀은 소규모 DSL을 개발했으며 관련 검사기를 실행하려고 합니다. 다른 팀에서는 가독성 및 유지 관리 측면에서 모범 사례를 구현했으며 리소스를 많이 사용하면서도 이러한 검사를
계속 시행하려고 합니다. 포함된 동적해석 결과를 기반으로 한 하이브리드 해석 사례입니다. 이러한 분석은 일부 팀에게는 높은 가치를 제공하지만 모든 사람에게는 비용이 너무 많이 들고 시간이 많이 걸립니다.
2018년 1월 현재 Google에는 약 70개의 선택적 분석이 있으며, 2,500개의 프로젝트에서 이 중 적어도 하나를 활성화합니다. 회사 전체에 걸쳐 수십 개의 팀이 새로운 분석기를 적극적으로 개발하고 있으며 대부분은 개발 도구 그룹 외부에 소속되어 있습니다.
기타 워크플로 통합 지점
명령줄 지원. Tricorder 팀은 본질적으로 코드 관리자인 개발자를 위한 명령줄 지원을 추가하여 팀의 코드 베이스에서 다양한 경고 분석을 자주 탐색하고 정리합니다. 또한 이러한 개발자는 각 분석기가 생성하는 수정 사항 유형에 대해 매우 잘 알고 있으며 특정 분석기에 대해 높은 수준의 신뢰를 갖고 있습니다. 따라서 개발자는 명령줄 도구를 사용하여 특정 분석의 모든 수정 사항을 자동으로 적용하고 깔끔하게 변경할 수 있습니다.
코드 커밋 임계값. 일부 팀에서는 코드 검토 도구에만 표시되는 대신 특정 분석기가 코드 커밋을 차단하기를 원합니다. 일반적으로 커밋 차단 기능에 대한 요청은 일반적으로 사용자 지정 DSL 또는 라이브러리에서 거짓 긍정을 보장하지 않는 고도로 사용자 지정된 검사기를 사용하는 팀에서 수행됩니다.
코드는 결과를 보여줍니다. 코드 프레젠테이션은 대규모 프로젝트(또는 전체 코드베이스)의 문제 규모를 보여주는 데 가장 적합합니다. 예를 들어, 더 이상 사용되지 않는 API에 대한 코드를 검색할 때 분석 결과는 마이그레이션에 필요한 작업의 양을 보여주거나 일부 보안 및 개인 정보 보호 분석은 전역적이므로 문제가 있는지 확인하기 전에 전문 팀이 결과를 검토해야 합니다. 분석 결과는 기본적으로 표시되지 않기 때문에 코드 브라우저를 사용하면 특정 팀이 분석 보기를 활성화한 다음 전체 코드 베이스를 스캔하고 다른 개발자가 이러한 분석기에 집중하는 데 방해가 되지 않고 결과를 검토할 수 있습니다. 분석 결과에 관련된 수정 사항이 있는 경우 개발자는 코드 탐색 도구를 클릭하기만 하면 수정 사항을 적용할 수 있습니다. 코드 브라우저는 코드가 커밋되고 실행될 때까지 이 데이터를 사용할 수 없기 때문에 생산 데이터 활용에 대한 분석 결과를 표시하는 데도 좋습니다.
Google에서 널리 배포되는 모든 정적 분석은 비교적 간단하지만 일부 팀은 특정 도메인(예: Android 앱)을 대상으로 하는 프로젝트별 분석 프레임워크를 사용하여 절차 간 분석을 수행합니다. Google 규모의 프로세스 분석은 기술적으로 가능합니다. 그러나 그러한 분석은 구현하기가 매우 어렵습니다. 위에서 언급했듯이 모든 Google 코드는 별도의 전체 소스 코드 저장소에 저장되므로 개념적으로 코드 저장소의 모든 코드는 모든 바이너리 파일의 일부가 될 수 있습니다. 따라서 특정 코드 검토의 분석 결과에 전체 코드 저장소에 대한 분석이 필요한 상황을 상상할 수 있습니다. Facebook의 Infer는 절차 간 분석에 중점을 두고 분할 논리 기반 분석기를 수백만 줄의 코드 기반으로 확장하지만 이러한 분석기를 Google의 수십억 줄 코드 저장소로 확장하려면 여전히 상당한 엔지니어링 노력이 필요합니다. 2018년 1월 현재, 보다 정교한 분석 시스템을 구현하는 것은 Google의 우선순위가 아닙니다.
대규모 투자. 초기 인프라 투자는 엄청날 것입니다.
허위 경보 비율을 줄이기 위한 노력이 필요할 것입니다. 분석 팀은 Figureinfer처럼 많은 분석기의 잘못된 긍정 비율을 크게 줄이고 표시되는 오류 메시지를 엄격하게 제한하는 기술을 개발해야 합니다.
구현해야 할 것이 더 많습니다. 분석 팀은 여전히 구현하고 통합할 수 있는 "쉬운" 분석기를 보유하고 있습니다.
높은 초기 비용. 우리는 이 "간단한" 분석기가 매우 비용 효율적이라는 것을 알았고, 이것이 FindBugs의 핵심 동기입니다. 이에 비해 보다 정교한 검사기의 경우 비용 ROI를 결정할 때에도 초기 비용이 높습니다.
이 ROI는 전문 분야(예: 항공우주 및 의료 기기) 또는 특정 프로젝트(예: 장치 드라이버 및 모바일 애플리케이션)에서 일하는 Google 외부 개발자의 경우 크게 다를 수 있습니다.
정적 분석을 Google 워크플로에 통합하려는 경험을 통해 우리는 다음과 같은 귀중한 교훈을 얻었습니다.
버그를 찾는 것은 쉽습니다. 코드 베이스가 충분히 크면 상상할 수 있는 거의 모든 코드 패턴이 포함됩니다. 완전한 테스트 적용 범위와 엄격한 코드 검토 프로세스를 갖춘 성숙한 코드 기반에서도 버그가 크게 나타납니다. 로컬 검사에서 문제가 명확하지 않은 경우도 있고, 무해해 보이는 리팩토링으로 인해 오류가 발생하는 경우도 있습니다. 예를 들어, long 유형의 필드 f를 사용하는 다음 코드 조각을 고려해 보세요.
result =
31 * result
(int) (f ^ (f >>> 32));
개발자가 f의 유형을 int로 변경하면 다음은 어떻게 될까요? 코드는 계속 컴파일되지만 오른쪽 오프셋 32는 무작동 작업이 되고 필드는 자체적으로 XOR되며 변수의 해시 값은 상수 0이 됩니다. 결과적으로 f는 더 이상 생성된 값에 영향을 주지 않습니다. hashCode 메소드. f 유형을 계산할 수 있는 모든 도구는 31보다 큰 올바른 오프셋을 올바르게 감지할 수 있습니다. Google은 이 오류가 있는 Google 코드 베이스에서 31개 코드를 수정했으며 오류 Pone 서버 오류의 컴파일에 검사도 포함했습니다.
오류를 찾아내는 것이 쉽기 때문에 Google은 간단한 도구를 사용하여 오류 유형을 감지합니다. 다음으로 분석 작성자는 Google 코드 실행 결과를 바탕으로 미세 조정을 수행합니다.
대부분의 개발자는 생각만큼 정적 분석 도구를 사용하지 않습니다. 많은 상용 도구 개발과 마찬가지로 Google은 처음에 FindBugs 구현에 의존했습니다. 엔지니어들은 프로젝트에서 발견된 문제를 보기 위해 중앙 집중식 대시보드에 액세스하기로 선택했지만 실제로는 그렇게 생각하는 사람이 거의 없었습니다. 코드에 포함된 버그(사용자가 문제를 인식하지 못한 채 배포 및 실행되었을 수 있음)를 찾기에는 너무 늦었습니다. 대부분 또는 모든 엔지니어가 정적 분석 경고를 볼 수 있도록 하려면 분석 도구를 워크플로우에 통합하고 모든 사람이 기본적으로 활성화해야 합니다. Error Prone과 같은 프로젝트는 오류 대시보드를 제공하지 않지만 추가 검사기로 컴파일러를 확장하고 코드 검토 중에 분석 결과를 표시합니다.
개발자의 감정이 중요합니다. 우리의 경험과 자료 축적에 따르면 정적 분석을 소프트웨어 개발 조직에 통합하려는 많은 시도가 실패했습니다. 엔지니어는 일반적으로 Google 경영진으로부터 정적 분석 도구를 사용할 권한을 부여받지 않습니다. 정적 분석 작업을 수행하는 엔지니어는 유효한 실제 데이터를 사용하여 자신의 영향을 입증해야 합니다. 성공적인 정적 분석 프로젝트를 위해서는 개발자가 프로젝트로부터 이익을 얻고 이를 사용하는 가치를 누려야 한다는 것을 인식해야 합니다.
성공적인 분석 플랫폼을 구축하기 위해 우리는 개발자에게 높은 가치를 제공하는 도구를 구축합니다. Tricorder 팀은 수정된 문제를 주의 깊게 검토하고, 실제 설문조사를 실시하여 개발자의 기분을 이해하고, 분석 도구를 통해 버그를 더 쉽게 제출하고, 이 모든 데이터를 활용하여 지속적으로 개선할 것입니다. 개발자는 분석 도구에 대한 신뢰를 구축해야 합니다. 도구가 낮은 수준의 문제에 대한 잘못된 긍정과 피드백으로 개발자의 시간을 낭비한다면 개발자는 자신감을 잃고 결과를 무시하게 됩니다.
버그만 찾지 말고 수정하세요. 정적 분석 도구를 홍보하는 일반적인 접근 방식은 코드 베이스에 많은 문제를 나열하는 것입니다. 그 목적은 수정해야 할 잠재적인 오류를 지적하여 조치에 영향을 미치거나 앞으로 버그가 발생하는 것을 방지하는 것입니다. 그러나 개발자가 조치를 취하도록 인센티브를 받지 못하면 잠재적으로 원하는 결과는 실현되지 않을 것입니다. 이는 근본적인 결함입니다. 분석 도구는 식별된 문제의 수를 기준으로 유용성을 측정하는 반면 소수의 버그 수정만으로 프로세스 통합이 실패합니다. 반대로 Google 정적 분석팀은 이를 성공적인 폐쇄 루프의 기준으로 삼아 해당 수리 작업과 버그 발견을 담당하게 됩니다. 오류 수정에 초점을 맞추면 도구가 실행 가능한 권장 사항을 제공하고 오탐지를 최소화할 수 있습니다. 많은 경우 오류를 수정하는 것은 자동화된 도구를 통해 오류를 찾는 것만큼 쉽습니다. 해결하기 어려운 문제라도 지난 5년간의 연구에서는 정적 분석 문제에 대한 수정 사항을 자동으로 생성하는 새로운 기술이 강조되었습니다.
분석기 개발에는 공동의 노력이 필요합니다. 특정 정적 분석 도구에서는 전문 개발자가 분석을 작성해야 하지만 실제로 어떤 검사가 더 큰 영향 요인을 생성하는지 아는 전문가는 거의 없습니다. 또한 분석기 전문가는 도메인 전문가(예: API, 언어 및 보안 작업)가 아닌 경우가 많습니다. FindBugs를 통한 통합 소수의 Google 직원만이 새 검사기를 작성하는 방법을 알고 있었기 때문에 소규모 BugBot 팀이 모든 작업을 직접 수행해야 했습니다. 이는 새로운 검사를 추가할 수 있는 속도를 제한하고 다른 사람이 도메인 지식 기여로부터 혜택을 받는 것을 효과적으로 방지합니다. Tricorder와 같은 팀은 이제 사전 정적 분석 경험 없이도 개발자가 제공하는 검사에 대한 표준을 낮추는 데 중점을 두고 있습니다. 예를 들어 Google 도구인 Reaster를 사용하면 개발자는 코드 조각 앞뒤에 예제를 지정하여 체커를 작성할 수 있습니다. 기여자는 잘못된 코드를 직접 디버깅한 후 기여하려는 동기를 갖는 경우가 많기 때문에 새로운 검사는 시간이 지남에 따라 개발자 시간을 절약해 줍니다.
우리의 경험에 따르면 개발 프로세스에 통합하는 것이 정적 분석 도구 구현의 핵심입니다. 검사기 도구 작성자는 개발자가 자신이 작성한 코드의 결함 목록을 보고 기뻐해야 한다고 믿을 수 있지만, 실제로 그러한 목록이 개발자가 결함을 수정하도록 동기를 부여하지는 않습니다. 분석 도구 개발자로서 우리는 개발자에게 숫자를 제공하기보다는 실제로 수정된 결함 측면에서 측정 효과를 정의해야 합니다. 이는 우리의 책임이 분석 도구 자체를 훨씬 넘어서는 것을 의미합니다.
우리는 가능한 한 빨리 워크플로 통합을 추진하는 데 초점을 맞춘 시스템을 옹호합니다. 가능할 때마다 검사기를 컴파일러 오류로 활성화하십시오. 방해가 되는 빌드 도구 작성자가 코드베이스의 모든 기존 문제를 먼저 해결해야 하는 일을 방지하여 Google 코드베이스의 품질을 한 번에 한 단계씩 지속적으로 개선할 수 있습니다. 컴파일러에 오류 경고가 표시되므로 개발자는 코드를 작성한 후 즉시 이를 처리하여 적시에 변경할 수 있습니다. 이를 달성하기 위해 우리는 방대한 Google 코드 베이스 전반에 걸쳐 분석을 실행하고 수정 사항을 생성하는 인프라를 개발했습니다. 또한 수백 개의 파일을 변경할 수 있는 코드 검토 및 커밋 자동화의 이점과 물론 코드 개선이 수정 위험에 대한 혐오보다 더 크기 때문에 레거시 코드에 통합된 변경을 종종 용인하는 엔지니어링 문화의 이점도 있습니다.
코드 검토는 코드를 커밋하기 전에 분석 경고를 표시하는 가장 좋은 진입점입니다. 개발자가 분석 결과를 수락하도록 하기 위해 Tricorder는 변경 사항을 커밋하기 전 개발자의 코드 수정 단계에서만 문제를 표시하며 Tricorder 팀은 표시할 경고를 선택하기 위해 일련의 기준을 적용합니다. Tricorder는 분석기가 다수의 유효하지 않은 경고를 생성하는 근본 원인을 탐지하는 데 사용되는 코드 검토 도구에서 통계를 추가로 수집합니다.
알람 무시를 극복하기 위해 우리는 Google 엔지니어의 신뢰를 되찾기 위해 열심히 노력했으며 Google 개발자는 정적 분석을 무시하는 강한 편견을 가지고 있으며 만족스럽지 못한 오탐률이 있는 보고서는 그럴 이유가 있다는 것을 발견했습니다. 아무것도 아님. 분석 팀은 설명적 객관적 기준에 따라 검사 결과를 검토한 후에만 검사 결과를 오류나 경고로 표시하는 것에 대해 매우 신중하므로 개발자가 분석 결과에 압도당하거나 혼란스럽거나 짜증나는 일이 거의 없습니다. 설문조사와 피드백 채널은 이 프로세스의 중요한 품질 관리 방법입니다. 이제 개발자들이 분석 결과에 대한 신뢰를 되찾았으므로 Tricorder 팀은 Google 개발자 워크플로에 더 많은 분석이 더 많이 참여해야 한다는 요구를 해결하고 있습니다.
우리는 컴파일 시간과 코드 검토 중에 매일 수백 개의 버그가 Google 코드 베이스에 유입되는 것을 방지하는 성공적인 정적 분석 인프라를 Google에 구축했습니다. 우리는 다른 사람들이 우리의 경험을 활용하여 정적 분석을 자신의 워크플로에 성공적으로 통합할 수 있기를 바랍니다.
위 내용은 정적 코드 분석 도구 구축에 관한 Google의 사례 연구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
