Google 如何建立程序分析生态系统_第1页
Google 如何建立程序分析生态系统_第2页
Google 如何建立程序分析生态系统_第3页
Google 如何建立程序分析生态系统_第4页
Google 如何建立程序分析生态系统_第5页
已阅读5页,还剩35页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

Google如何

建立程序分析生态系统2023/2/5Agenda程序分析存在的问题项目的目标Google的背景Google的程序分析理论项目的实施思考ReferenceTricorder:BuildingaProgramAnalysisEcosystemPage2程序员已经很忙了工具必须非常重视是否让开发人员花费更多额外的时间来处理工具的结果;任何自动工具的输出都会使开发人员从原来的开发思考停顿下来;好的工具应该给尽量少的打扰开发人员,并为开发人员带来更多的附加值;工具的问题Highfalsepositive

rates(高误报率)Confusingoutput(令人费解的输出报告)Poorintegrationintothedevelopers’workflow(不能很好的融合到程序员的日常的开发流程中)平台扩展的问题Google存在不同的框架和开发语言;一个理想的平台能够适应这些需求能够让各领域的专家来编写自己的检查工具,而不需要额外的应用成本;Google的业务需求不能满足google巨大代码量的需求,一个完整的编译过程是无法用一台机器完成的;分析必须能够被拆分(shared),并且能够分析拆分的信息,得到这部分的结果。分块的分析必须能够在极短的时间内完成,在几分钟内得到结果;静态分析存在的问题Page3能够普遍地、积极地、主动地被程序员用来修复程序中存在的问题(bewidelyandactivelyusedbydeveloperstofixproblemsintheircode,withoutpromptingfromasmallgroupofadvocatesormanagement);无缝地整合到现有的开发流程中(integratesmoothlyintotheexistingdeveloperworkflow);能够度量所有的代码(scaletothesizeofanindustrialcodebase);授权给开发者(甚至他们不是分析专家),让他们自己能够编写他们自己的检查规则(empowerdevelopers,evennon-analysisexperts,towriteanddeploytheirownstaticanalyses).理想的静态分析平台Page4Agenda程序分析存在的问题项目的目标Google的背景Google的程序分析理论项目的实施思考ReferenceTricorder:BuildingaProgramAnalysisEcosystemPage5项目目标WepresentTRICORDER,aprogramanalysisplatformaimedatbuildingadata-driven

ecosystemaroundprogramanalysis.Wepresentasetofguiding

principlesforourprogramanalysistoolsandascalablearchitecture

forananalysisplatformimplementingtheseprinciples.

Weincludeanempirical,in-situevaluationofthetoolasitis

usedbydevelopersacross

Googlethatshowstheusefulnessand

impactoftheplatform.TRICORDER构建一个围绕程序分析,以数据驱动的程序分析平台;建立一套程序分析工具的应用规则;平台通过度量(使用、效果)方式实施这些规则,并与开发流程融合。通过建立一个在开发程序员和规则开发者之间的闭环的反馈系统,来完成问题的反馈、自动修复(部分);一个建立在程序员在开发流程中应用工具的具体信息数据来度量的平台;一个以微服务构建的适用google的代码项目规模的平台。每天会产生9,3000的扫描报告,但仅由2-3人维护的系统;Page6Page7息处理类:

可以无线下载目标终端的数据。包括非星联系统,并且可以处理和分析数据。三录仪也可以作为一个数据终端,多台可以联网处理数据。扫描器类:

通过扫描波束来确定目标的介质,化学成分等,也可以扫描周围的空间组成,探测此范围内的生命信号,以及对目标物体成像,医用的CT等。工程技术类:

可以通过扫描来诊断设备的故障。并且优化显示故障排除方法。TRICORDER是一种手持式的多用途仪器。它是星际旅行里经常要用到的一种必备仪器。/operations/tricorder.htmlThetricorderof2266wasacompactinstrumentthatfeaturedscanning,recording,andcomputingtechnology.

Star

trek–星际迷航星际迷航中的科技:平板电脑(PAAD)、GPS、大显示屏、宇宙翻译机、自动门、手机、传送器、复制机、全息技术、曲速旅行、视屏会议等等。。。史蒂芬·霍金2002年《果壳中的宇宙》--即使把我关在果壳之中,仍然自以为无限宇宙之王Agenda程序分析存在的问题项目的目标Google的背景Google的程序分析理论项目的实施思考ReferenceTricorder:BuildingaProgramAnalysisEcosystemPage8许多工程师都是在一个很大的代码库上进行开发的performmorethan800kbuilds,run100Mtestcases,produce2PBofbuildoutputs,andsend30kchangelistsnapshots(patchdiffs)forreview大代码库使代码重用和重构变得非常容易和普遍;Google有极强的整合测试的测试文化(Googlehasastrongtestingculture

backedbycontinuoustestinginfrastructure)Google采用一套统一的标准的构建和发布系统(Googleengineersuseastandardized,distributedbuildsystemtoproducehermeticbuildsfromsourcecode);统一的构建系统为代码分析提供了统一的接入点Google有极强的代码审视文化每一个Changelist都会被在checked-in之前被审视Google的开发特点Page9要求开发人员能够方便的运行分析工具,能够快速地得到结果Google的Codereview工具类似gerritPage10/p/gerrit/issues/listprovidestheabilitytocommentonlinesofcode,replytoexistingcomments,uploadnewsnapshotsofthecodebeingreviewed(author),approvethechangelist(reviewer).Google曾经尝试过将以下工具整合到开发流程中Find-Bugs,Coverity,Klocwork,缺陷预测理论(faultprediction)这些工具存在的问题与工作流程的整合太晚:只有在提交代码之后才能得到结果太早:开发人员还在调试代码的时候就出现了几乎都需要运行单独的命令,不能与编译器整合在一起扫描的规模。这个问题在桌面工具有为突出高误报率结论当工具有单独的命令或即使通过仪表盘来运行的时候,使用量会慢慢减少Google的程序分析Page11Agenda程序分析存在的问题项目的目标Google的背景Google的程序分析理论项目的实施思考ReferenceTricorder:BuildingaProgramAnalysisEcosystemPage12没有误报(Nofalsepositives)研究表明误报是程序员不愿意采用分析工具去发现bug的主要原因之一Google理解为有效的误报率(effectivefalsepositive)标示工具不确定的告警(这类问题往往是因为工具得到的信息不足)能提高代码可读性的缺陷,不被认为是误报;不过度分析,不考虑实际中不会出现的情景(theoreticalfalsepositives)Google的程序分析理论—没有误报Page13让开发人员来决定工具的作用和误报率developerswilldecidewhetherananalysistoolhashighimpact,andwhatafalsepositiveis.Google的程序分析理论—用户参与Page14用户参与(Empoweruserstocontribute)只有用户自己最了解自己的项目,让他们自己来写规则,并对结果负责;这些领域的专业人员并不了解如何和流程的整合,这也是平台的作用;为了保证质量我们和开发规则人员约定规则下线条款:没有人使用这个检查(Nooneisfixingbugsfiledagainsttheanalyzer.)资源的使用影响了系统(Resourceusage(e.g.CPU/disk/memory)isaffectingTRICORDERperformance)分析报告让开发人员困惑(Theanalyzerresultsareannoyingdevelopers)经验表明自豪感会让规则的开发者有着强烈的主动性去避免规则下线。Google的程序分析理论—数据提高可用性Page15数据提高可用性(Makedata-drivenusabilityimprovements)问题响应非常重要。程序员和工具建立信任关系,这种信任会因为对报告的不理解迅速减低;一款工具的bug在改进了用词或连接到了帮助文档后,75%被修复;建立一个反馈系统能很好的提升工具的可用性;Google的程序分析理论—工作流整合是关键Page16工作流整合是关键(Workflowintegrationiskey)与工作流整合是提高工具的效果的关键因素;工具的触发最好由:编辑代码editingcode,运行编译runningabuild,创建或更新修改表creating/updatingachangelist,提交一个更新表submittingachangelist.扫描的报告最好在提交代码之前得到一个调查表明程序员期望在编译时就得到检查报告的人数是在提交修改列表时的两倍;在编译时检查,就要求有效的误报率要几乎等于0,最高不超过5%Tricorder与工作流的整合Page17编译器分析工具与编译告警一起送给开发者提交代码审核分析工具一起送给代码审计者要求:速度快,误报<5%要求:5-10分钟,误报<10%开发流程审计流程修改代码IDE本地分析工具远端分析工具每日构建分析工具分析报告专职团对专职处理TricorderGoogle的程序分析理论—根据项目定制Page18根据项目定制(Projectcustomization,notusercustomization)Google的经验表明,用户的自定义(对告警的标准不一),将导致团队内部的混乱;不采用告警处理优先级和严重等级的设定,只显示严重等级的问题;我们能够取消或改善低优先级、收益小的检查由结果过滤器改为自定义分析器;我们大大减少了,为什么有些结果会出现,为什么结果的看法不一致等问题。给项目组一定的定制权,让项目组来决定是否采用可选分析器没有误报(Nofalsepositives)用户参与(Empoweruserstocontribute)数据提高可用性(Makedata-drivenusabilityimprovements)根据项目定制(Projectcustomization,notusercustomization)Google的程序分析理论--小结Page19Agenda程序分析存在的问题项目的目标Google的背景Google的程序分析理论项目的实施思考ReferenceTricorder:BuildingaProgramAnalysisEcosystemPage20Tricorder的架构Page21Google-specificRPClibraryJavaAnalyzerC++AnalyzerPythonAnalyzerGoAnalyzerlanguage-specificinterfaceLanguageanalyzerservicesCommonlanguage-agnosticprotocolbufferAPICompileranalyzerservicesClangPlugInjavacjscompilerLinterworkserviceslanguage-specificinterfaceGetCategoryGetStageAnalyzeThecategory(andoptionallysubcategory)oftheanalysisresult.Thelocationoftheanalysisresultinthecode,e.g.fileandrange(line/column)withinthatfile.Theerrormessage.AURLwithmoredetailedinformationabouttheanalyzerand/orthemessage.Anorderedlistoffixes./google/shipshapeTricorder的三个阶段Page22文件阶段(FILES)处理修改的文件依赖阶段(DEPS)处理修改文件的依赖文件编译阶段(COMPILATION)处理编译的文件分阶段的优点能够在更快的提供报告,而不需要等到构建完成可以降低成本高的资源的使用不影响在更早的时候开发分析Tricorder的AnalyzerPage2316of30analyzersruninTRICORDER大约9,7000与目标总数9,3000相当35Linter7analyzer告警必须简单、容易理解,能够明确修复(Thewarningshouldbeeasytounderstandandthe

fixshouldbeclear);告警应该有非常小的误报率(<10%)(Thewarningshouldhaveveryfewfalsepositives.),同样的标准也用于Coverity等其他工具告警应该有足够的严重程度(Thewarningshouldbeforsomethingthathasthepotentialforsignificantimpact.)告警应该是发生次数少但经常被注意的问题(Thewarningshouldoccurwithasmallbutnoticeablefrequency.)如果这个问题经常出现,意味着它的危害不大,不应该给出过多的告警。Tricorder的Analyzer规则评定标准Page24存在争议的问题:检测工具已经检测出问题来了,还让很忙的程序员自己来处理问题?Google鼓励这么做,通过代码review工具。Tricorder问题的修复Page25这样做的好处是:让程序员方便修复更好地解释报告修复不是直接修改代码,而是提供修改的按钮。为了快速提供反馈信息,Tricorder和代码审计工具连通(robocomment)。在每个问题上有四个连接:NOTUSEFULPLEASEFIXPREVIEWFIX(Show)APPLYFIX(Apply)not-usefulrate=NOTUSEFUL/(NOTUSEFUL+PLEASEFIX+APPLYFIX)>=10%进入观察区>25%考虑立刻下线很多时候是和Analyzer的编制者一起来看问题的发生原因不适合的项目不在意一时的波动Tricorder反馈系统Page26可用性(Usability)用无用率(Not-usefulrate)来衡量工具的可用性。目前<5%Tricorder运行结果–可用性Page27Tricorder运行结果–可用性Page28Privew_fix和Please_fix相关点击率统计结果的一些思考许多开发人员在审核人员查看之前完成问题修复,所以PLEASE_FIX数量低;许多开发人员在IDE里修复问题,所以APPLY_FIX数量低;开发人员会忽略他们不打算修复问题,而不是点击NOT_USEFUL,这暗示他们对这些问题看法的强烈程度;开发人员可能错误地点击了NOT_USEFUL好的Analyzer的NOT_USEFUL率在0-3%随着时间推移,减少了问题代码的入库;开发人员通过问题的学习,相同的问题数量减少了;Tricorder运行结果–代码库的影响Page29平均一天发现30个分类的9,3000问题;运行5,000次构建;审核人平均点PLEASE_FIX716次,其中416次属于Linters),48次NOT_USEFUL.Tricorder运行结果–运营能力Page30平均每个CL有两个PLEASE_FIX,无NOT_USEFUL通过数据驱动可用性的提高;开发人员不喜欢误报,所以需要建立一个快速反馈系统来听取他们的意见;让用户自己来建立自己的检查规则;检查工具和工作流程融合非常重要,实践表明最好的融合点是代码审视阶段;检查工具的定制是项目定制,而不是用户定制;简单的规则会起到很大的作用(Google并未采用复杂技术的检查工具);工具的目的是修复bug,而不是发现bug;Tricorder实施经验回顾Page31Agenda程序分析存在的问题项目的目标Google的背景Google的程序分析理论项目的实施思考ReferenceTricorder:BuildingaProgramAnalysisEcosystemPage32检查工具的结果要和IDE/代码审视工具融合;检查工具需要给出清晰的解释,提供修复的方法建立信息的反馈系统,听取开发人员对工具的看法,及时作出反应;考虑建立编译器的插件,完成编译时的检查;在扫描报告中加入更多的错误修改方法的说明,以及相关知识库的连接信息;思考Page33工具最好与工作流整合,减少对程序员的干扰。最好通过编译与代码审视工具整合在一起;通过代码审视工具收集工具的效果信息;收集的信息,评估工具的效果;工具需要给出尽可能详细的帮助信息,甚至能够辅助开发人员完成修改;Google的代码检查理念Page34Tricorder与工作流的整合Page35编译器分析工具与编译告警一起送给开发者提交代码审核分析工具一起送给代码审计者要求:速度快,误报<5%要求:5-10分钟,误报<10%开发流程审计流程修改代码IDE本地分析工具远端分析工具每日构建分析工具分析报告专职团对专职处理Tricorder通过代码审视工具收集工具的使用效果Page36Not-usefulrate=NOTUSEFUL/(NOTUSEFUL+PLEASEFIX+APPLYFIX)NOTUSEFULPLEASEFIXPREVIEWFIX(Show)APPLYFIX(Apply)Tricorder:BuildingaProgramAnalysisEcosystemmicroservices/articles/microservices.htmlReferencePage37AddressSanitizerisafastmemoryerrordetector.Itconsistsofacompilerinstrumentationmoduleandarun-timelibrary.Thetoolcandetectthefollowingtypesofbugs:Out-of-boundsaccessestoheap,stackandglobalsUse-after-freeUse-after-return(runtimeflag

ASAN_OPTIONS=detect_stack_use_after_return=1)Use-after-scope(clangflag

-fsanitize-address-use-after-scope)Double-free,invalidfreeMemoryleaks(experimental)AddressSanitizerPage38/docs/AddressSanitizer.htmlErrorProneisastaticanalysistoolforJavathatcatchescommonprogrammingmistakesatcompile-time.ErrorPronePage39/google/error-prone/bugpatternsArgumentParameterSwap

Theargumentandparameternamesdonotmatchexactly.ArrayEquals

ReferenceequalityusedtocomparearraysArrayHashCode

hashcodemethodonarraydoesnothasharraycontentsArrayToString

CallingtoStringonanarraydoesnotprovideusefulinformationArraysAsListPrimitiveArray

Arrays.asListdoesnotautoboxprimitivearrays,asonemightexpect.AsyncFunctionReturnsNull

AsyncFunctionshouldnotreturnanullFuture,onlyaFuturewhoseresultisnull.BadShiftAmount

ShiftbyanamountthatisoutofrangeChainingConstructorIgnoresParameter

Thecalledconstructoracceptsaparameterwiththesamenameandtypeasoneofitscaller'sparameters,butitscallerdoesn'tpassthatparametertoit.It'slikelythatitwasintendedto.CheckReturnValue

Ignoredreturnvalueofmethodthatisannotatedwith@CheckReturnValueClassName

Thesourcefilenameshouldmatchthenameofthetop-levelclassitcontainsComparisonOutOfRange

ComparisontovaluethatisoutofrangeforthecomparedtypeCompileTimeConstant

Non-compile-timeconstantexpressionpassedtoparameterwith@CompileTimeConstanttypeannotation.ConstantOverflow

Compile-timeconstantexpressionoverflowsDaggerProvidesNull

Dagger@Providesmethodsmaynotreturnnullunlessannotatedwith@NullableDeadException

ExceptioncreatedbutnotthrownDepAnn

Deprecateditemisnotannotatedwith@DeprecatedEqualsNaN

==NaNalwaysreturnsfalse;usetheisNaNmethodsinsteadForOverride

Methodannotated@ForOverridemustbeprotectedorpackage-privateandonlyinvokedfromdeclaringclassFuturesGetCheckedIllegalExceptionType

Futures.getCheckedrequiresacheckedexceptiontypewithastandardconstructor.GetClassOnAnnotation

CallinggetClass()onanannotationmayreturnaproxyclassGetClassOnClass

CallinggetClass()onanobjectoftypeClassreturnstheClassobjectforjava.lang.Class;youprobablymeanttooperateontheobjectdirectlyGuardedByChecker

Checksforunguardedaccessestofieldsandmethodswith@GuardedByannotationsGuavaSelfEquals

AnobjectistestedforequalitytoitselfusingGuavaLibrariesGuiceAssistedInjectScoping

ScopeannotationonimplementationclassofAssistedInjectfactoryisnotallowedGuiceAssistedParameters

Aconstructorcannothavetwo@Assistedparametersofthesametypeunlesstheyaredisambiguatedwithnamed@Assistedannotations.GuiceInjectOnFinalField

AlthoughGuiceallowsinjectingfinalfields,doingsoisdisallowedbecausetheinjectedvaluemaynotbevisibletootherthreads.HashtableContains

contains()isalegacymethodthatisequivalenttocontainsValue()IdentityBinaryExpression

Writing"a&&a","a||a","a&a",or"a|a"isequivalentto"a".InfiniteRecursion

Thismethodalwaysrecurses,andwillcauseaStackOverflowErrorInjectMoreThanOneScopeAnnotationOnClass

Aclasscanbeannotatedwithatmostonescopeannotation.InsecureCipherMode

Cipher.getInstance()isinvokedusingeitherthedefaultsettingsorECBmodeInvalidPatternSyntax

InvalidsyntaxusedforaregularexpressionIsInstanceOfClass

TheargumenttoClass#isInstance(Object)shouldnotbeaClassJUnit3TestNotRun

Testmethodwillnotberun;pleaseprefixnamewith"test"JUnit4SetUpNotRun

setUp()methodwillnotberun;Pleaseadda@BeforeannotationJUnit4TearDownNotRun

tearDown()methodwillnotberun;Pleaseaddan@AfterannotationJUnit4TestNotRun

Testmethodwillnotberun;pleaseadd@TestannotationJavaxInjectOnAbstractMethod

Abstractanddefaultmethodsarenotinjectablewithjavax.inject.InjectLongLiteralLowerCaseSuffix

Prefer'L'to'l'forthesuffixtolongliteralsMislabeledAndroidString

Certainresourcesin

android.R.string

havenamesthatdonotmatchtheircontentMisusedWeekYear

Useof"YYYY"(weekyear)inadatepatternwithout"ww"(weekinyear).Youprobablymeanttouse"yyyy"(year)instead.MockitoCast

AbuginMockitowillcausethistesttofailatruntimewithaClassCastExceptionMockitoUsage

Missingmethodcallforverify(mock)hereModifyingCollectionWithItself

Usingacollectionfunctionwithitselfastheargument.MoreThanOneInjectableConstructor

Thisclasshasmorethanone@Inject-annotatedconstructor.Pleaseremovethe@Injectannotationfromallbutoneofthem.NonCanonicalStaticImport

Staticimportoftypeusesnon-canonicalnameNonFinalCompileTimeConstant

@CompileTimeConstantparametersshouldbefinalOptionalEquality

ComparisonusingreferenceequalityinsteadofvalueequalityOverlappingQualifierAndScopeAnnotation

AnnotationscannotbebothScopeannotationsandQualifierannotations:thiscausesconfusionwhentryingtousethem.Overrides

Varargsdoesn'tagreeforoverriddenmethodOverridesJavaxInjectableMethod

Thismethodisnotannotatedwith@Inject,butito

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论