随时间推移跟踪方法"bloat" nDepend的情况

Question

我们正在考虑使用nDepend来开始跟踪我们的一些技术债务，特别是围绕难以维护的方法和圈复杂性。

我相信这可能是通过获取基线报告，然后运行新的分析来提供增量。下面是我整理的一个非常基本的Powershell，可以做到这一点。

$nDepend = "C:_DEVELOPMENTnDependNDepend.Console.exe"
$targetFile = "C:_DEVELOPMENTAssemblyToTestCodeChallenge.Domain.ndproj"
$projectFolder = Split-Path -Path $targetFile
$outputFolder = "nDepend.Reports"
$previous = ""
Clear-Host
# See if we already have a .ndar file in the output folder, if we do back it up so we can do a comparison
if (Test-Path $projectFolder$outputFolder*.ndar)
{
Write-Output "Backing up previous NDAR report"
Copy-Item $projectFolder$outputFolder*.ndar $projectFolderprevious.ndar
$previous = ".previous.ndar"
}
#The output path appears to be relative to the .ndproj file
& $nDepend $targetFile /Silent /OutDir .$outputFolder /AnalysisResultToCompareWith .previous.ndar

这是我在nDepend中配置的规则：-

failif count > 1 bobs
from  m in Methods
where m.NbLinesOfCode > 10
where m.WasChanged()
select new { m, m.NbLinesOfCode }

这样做的目标不是如果我们的方法超过 10 行，则破坏构建，而是如果有人编辑的现有方法太大并且没有改进它(或使其更糟)，则破坏构建。但是，无论我添加多少代码，都不会触发规则的where m.WasChanged()部分。如果我将其注释掉，它会提醒我有很多超过 10 行的方法，但我只想知道最近更改的方法。

我用错了规则吗？或者我的powershell错误地使用了/AnalysisResultToCompareWith参数？

Answer 1

有一些默认规则，例如避免在规则组中使复杂方法更加复杂 代码气味回归接近您想要实现的目标。您可以从他们的源代码中获得灵感。

关键是检索更改的方法...

m.IsPresentInBothBuilds() && 
m.CodeWasChanged() &&

然后通过访问m.OlderVersion()比较自基线以来的指标演变。

ICompareContext 引用两个代码库快照较新版本和旧版本。在这种情况下，OlderVersion() 扩展方法实际上从文档中调用ICompareContext.OlderVersion(codeElement)：

• 返回旧版本的codeElement对象。
• 如果codeElement已经是旧版本，则返回codeElement对象。
• 如果已添加codeElement并且没有相应的旧版本，则返回null。
• 此方法具有恒定的时间复杂度。