我们大多数人都对著名的马克·扎克伯格宣言“快速行动并打破事物”非常熟悉。 在2014年,这是一个非常大胆的声明,正如扎克伯格很快意识到的那样,可能太过大胆了。 后来他撤回了它,表明了他想要快速行动但保持稳定的新愿望。
为了更好地解决代码质量(不影响速度),许多组织都在“左移”计划上投入大量资金,强调在自动化过程中使用自动化技术来更早地检测和解决预生产中的代码缺陷。 静态和动态代码分析已成为任何软件质量策略所需的两个关键工具。 那么,它们是什么?它们如何一起工作?
引用OverOps的解决方案工程师之一 ,让我们使用一个熟悉的类比来阐明静态和动态分析工具之间的差异:
静态代码分析类似于使用练习网和投球机练习棒球挥杆。 几乎没有什么惊喜。 经过几次挥杆后,您确切地知道每次球都在哪里。 这有助于基础知识的工作,并确保您具有良好的状态。 虽然这有助于改善您的游戏,但它只能使您步入正轨。
“动态代码分析更像是在带电投手的情况下练习挥杆动作,每个投球的类型和位置都会发生变化。 它不仅测试您的基础知识,还测试您对不同的意外情况做出反应的能力。 在生产中完成后,就好比在第9根底部装满底座的时候完善挥杆动作。 我是否提到分数与2局并列? 赌注很高。”
现在用软件的术语来说,静态分析工具在运行程序之前根据给定的一组规则或编码标准检查应用程序的源代码。 用户能够检测代码漏洞和代码气味(即,源代码中的任何特征可能表明存在更深层的问题),并确保遵守公认的编码标准。 他们还提供“测试覆盖率”报告,这些报告描述了代码执行的程度。 然后,这些工具通过质量门执行这些规则。
尽管静态分析在解决许多问题上做得很好,但是这些工具因其对远见的依赖而受到限制。 您只能检测到构建测试用例的目的,而错过了在后台发生的所有运行时活动。 这意味着即使测试表明100%的代码覆盖率,也并不意味着已识别出100%的关键问题。
诸如OverOps之类的动态代码分析工具可在执行代码时检测到严重的运行时错误,从而分析静态运行时错误,从而弥补这一空白,而这一切都无需依靠任何先见之明。 这使用户能够在任何问题投入生产之前就确定可能的故障点。 静态和动态分析一起提供了一种万无一失的方法,以确保发行版可用于生产。
观看最近的网络研讨会 ,了解动态和静态分析在实际中的结合使用,并了解如何利用这两个工具来交付更高质量的代码。
翻译自: https://www.javacodegeeks.com/2020/04/how-to-add-dynamic-code-analysis-to-your-pipeline.html