识别应用程序中的"敏感"代码

Question

希望提高相当大的Python项目的质量.我对PyLint给我的警告类型感到满意.但是,它们太多而且难以在大型组织中执行.此外,我认为某些代码在下一个bug可能出现的地方比其他代码更具关键性/敏感性.例如,我想花更多的时间验证100个模块使用的库方法,而不是2年前最后一次触及的脚本,可能不会用于生产.了解经常更新的模块也很有趣.

是否有人熟悉Python工具或其他有助于此类分析的工具？

Answer 1

您的问题类似于我在SQA https://sqa.stackexchange.com/a/3082上回答的问题.这个问题与Java有关,这使得工具更容易,但我在下面提出了许多建议.

许多其他答案表明Python没有好的运行时工具.我在几个方面对此持不同意见:

1. 覆盖工具非常有效
2. 根据我在Java工具方面的经验,Python中的静态和动态分析工具比强类型的动态性较弱的语言弱,但在这里工作得非常好,可以为您提供良好的启发式方法.除非您使用异常大的病理数量的动态功能(包括添加和删除方法,拦截方法和属性调用,使用导入,手动修改命名空间) - 在这种情况下,您遇到的任何问题都可能与此动态相关联. .
3. Pylint会发现更简单的问题,并且不会检测动态类/实例修改和装饰器的问题 - 因此公制工具不会测量这些问题并不重要
4. 在任何情况下,您可以通过依赖图来确定有用的焦点.

用于选择代码的启发式方法

我发现选择改进代码有许多不同的考虑因素,它们既可以单独使用,也可以一起使用.请记住,首先,您需要做的就是找到一个高效的工作方式 - 在开始之前,您不需要找到绝对最差的代码.

用你的判断.

经过代码库几个周期后,您将获得大量信息,并且可以更好地继续工作 - 如果确实需要做更多的事情.

那就是说,这是我的建议:

对业务的高价值:例如任何可能使公司损失很多钱的代码.其中许多可能是显而易见的或广为人知(因为它们很重要),或者可以通过在启用了运行时分析器的系统上运行重要用例来检测它们.我使用Coverage.

静态代码指标:有很多指标,但与我们有关的指标是:

• 高传入耦合.这是许多其他文件所依赖的代码.虽然我没有直接输出这个的工具,但snakefood是将依赖项直接转储到文件的好方法,每个依赖项一行,每个都是传入和传出文件的元组.我不想这么说,但是从这个文件计算传入耦合值是一个简单的练习留给读者.
• 高McCabe(圈复)复杂性:这是更复杂的代码.虽然我没有使用过这个工具,PyMetrics似乎也会产生这种测量.
• 大小:通过使用可视化工具查看项目大小,您可以获得大量信息(例如https://superuser.com/questions/8248/how-can-i-visualize-the-file-system-usage- on-windows或https://superuser.com/questions/86194/good-program-to-visualize-file-system-usage-on-mac?lq=1.Linux在Filelight上有KDirStat.大文件是一个很好的起点,因为修复一个文件修复了许多警告.

请注意,这些工具是基于文件的.这可能是足够精确的分辨率,因为你提到项目本身就有数百个模块(文件).

频繁更改:经常更改的代码非常可疑.代码可以:

• 历史上有许多缺陷,并且在经验上可能会继续这样做
• 正在进行功能开发的更改(VCS中的大量修订)

使用VCS可视化工具查找更改区域,例如本答案后面讨论的那些.

未覆盖的代码:测试未涵盖的代码.

如果你运行(或可以运行)你的单元测试,你的其他自动测试和覆盖范围的典型用户测试,看看没有覆盖的旁边的包和文件.没有报道的原因有两个:

• 代码是必需的(并且很重要)但根本没有测试(至少自动).这些地区的风险极高
• 代码可能未使用,是删除的候选者.

问其他开发者

您可能会对与长期服务的开发人员喝咖啡而收集的"气味"指标感到惊讶.我敢打赌,如果有人清理代码库的一个肮脏区域,只有最勇敢的灵魂才会冒险,他们会非常高兴.

可见性 - 检测随时间的变化

我假设您的环境有DVCS(例如Git或Mercurial)或至少有VCS(例如SVN).我希望您也使用某种问题或错误跟踪器.如果是这样,那么可获得大量信息.如果开发人员可靠地签入评论和发布号码,那就更好了.但是你如何形象化并使用它呢？

虽然您可以在单个桌面上解决问题,但建立持续集成(CI)环境可能是个好主意,可能使用像Jenkins这样的工具.为了简短回答,我将从现在开始假设詹金斯.Jenkins附带了大量的插件,可以帮助进行代码分析.我用:

• 带有JUnit测试输出的py.test由JUnit测试报告Jenkins插件获取
• 覆盖与的Cobertura插件
• SLOCCount和SLOCCount插件
• Pylint和Violations插件
• 显然,Python的McCabe(循环测量)复杂性有一个插件,虽然我还没有使用它.它看起来很有趣.

这让我可以看到随时间变化的变化,我可以从那里钻取.例如,假设PyLint违规在模块中开始增加 - 我有增加的证据,我知道发生这种情况的包或文件,因此我可以找出谁参与并与他们交谈.

如果您需要历史数据并且刚刚安装了Jenkins,请查看是否可以运行一些从项目开始时开始的手动构建,并在当前向前进行一系列跳转.您可以从VCS中选择里程碑版本标记(或日期).

如上所述,另一个重要领域是检测代码库中的变化轨迹.我真的很喜欢Atlassian Fisheye.除了非常擅长在任何时间点搜索提交消息(例如bug id)或文件内容外,它还允许我轻松查看指标:

• 按目录和子目录计划的行数
• 任何时间点或特定目录和/或文件中的提交者
• 提交的模式,包括时间和源代码中的位置

Answer 2

我担心你大多是靠自己.

如果您有一套不错的测试,请查看代码覆盖率和死代码.

如果你有一个不错的分析设置,使用它来瞥见更多的使用.

最后,你似乎对扇入/扇出分析更感兴趣,我不知道有什么好的Python工具,主要是因为静态分析对于动态语言是非常不可靠的,到目前为止我还没有看到任何统计分析工具.

我认为这些信息在JIT编译器中是可用的 - 无论(函数,参数类型)在缓存(编译)中是哪些都是最常用的.你是否可以从PyPy中获取这些数据我真的没有线索.

Answer 3

源控制工具可以很好地指示经常更新的模块 - 通常指示故障点.

如果您没有源代码管理但项目是从共享位置运行,请删除所有pycache文件夹或.pyc文件.随着时间的推移/在使用中观察哪些文件被重新创建以指示其使用.

分析从特定入口点运行时打印的Python导入

python -v entry_point

可以深入了解正在使用哪些模块.虽然如果您已知接入点,则应尝试覆盖模块.

要获得更具侵入性的解决方案,请考虑设置项目范围的日志记录.您甚至可以通过分布式程序轻松地记录度量标准.

Answer 4

我同意其他人的观点,因为我还没有遇到过一个很好的Python运行时分析工具.有一些方法可以解决它,但没有一个是微不足道的.

我认为最强大的是获取Python源代码并使用某种内置的运行时日志记录重新编译二进制文件.这样您就可以将其滑入现有环境,而无需对项目进行任何代码更改.当然,这并不是一件容易的事情,但它有一个额外的好处,你可能有一天能够将它合并回后代,而不是后代.

对于非重新编译方法,我首先看的是配置文件库的确定性分析部分.

如何实现它将在很大程度上取决于您的环境的设置方式.您是否有许多单独的脚本和项目彼此独立运行,或者只是一个主要脚本或模块或包被其他人使用,您只是想知道它的哪些部分可以修剪以使维护更容易？它是一次加载,永远运行的设置,还是你只是在某种程度上以原子方式运行脚本的情况？

您可以实现项目范围的日志记录(如@ Hardbyte的答案中所述),但这需要通过项目并将日志记录行添加到您的所有代码中.如果你这样做,你可以使用内置功能profiler,我认为.