标签: software-quality

有一天,一位朋友告诉我,在软件开发生命周期中修复问题的成本存在一个金字塔.我在哪里可以找到这个？

他指的是解决问题的成本.

例如,

在需求阶段解决问题成本1.

在开发阶段解决问题成本为10.

在测试阶段解决问题成本为100

在生产阶段解决问题成本为1000.

(这些数字只是例子)

如果有人参考,我会有兴趣看到更多相关信息.

我目前使用Managed Binary Analysis,看起来nuget添加了相同的规则(可能更少).

我也使用这个SonarQube插件:https://github.com/SonarQubeCommunity/sonar-fxcop.

准确的是什么？

这当然预示着单元测试是一件好事.我们的项目有一定程度的单元测试,但它最多不一致.

您使用过或曾经使用过哪些最有说服力的方法来说服每个人,正式的单元测试是一件好事,并且需要它才能真正符合我们工作的"大型"项目的最佳利益.我不是开发人员,但我在质量保证方面,并希望提高所提供工作的质量,以确保其准备好进行测试.

通过正式的单元测试,我只是在谈论

• 确定要编写的单元测试
• 识别测试数据(或描述)
• 写这些测试
• 跟踪这些测试(并根据需要重新使用)
• 使结果可用

在实践中,软件质量对于Application Developer来说真的很重要吗？

我知道这个问题似乎是最愚蠢的问题.但请看下面为什么我问这个问题.

我喜欢这样的工程原理,模式,并且到目前为止一直在实施和享受.但是现在我意识到这些原则对于Application Developer来说真的无关紧要,但重要的是"开发时间","应用程序按预期工作 "和" 完成时间不多但是没关系".

我现在真的很困惑,关于应用程序开发人员的软件质量和原则的实际重要性.因此,在我的所有时间指南之后寻找实际答案无法给出软件质量影响组织的答案和[设计代码质量的重要性] [2]

有关软件质量和软件工程的信息很多,但实际上它们是在应用程序开发中实施的吗？

我问这个问题是一个应用程序开发人员,而不是谈论操作系统,语言或编译器开发/创新.

谢谢大家的回复.让我更多地说明为什么我在第一时间提出这个问题.

我也相信并认为在考虑这些原则时应该毫不犹豫.我相信这是一种艺术,策略不能根据某些东西切换.

但是如果你看到关于这个主题的任何内容或者说这篇文章,请注意诸如"取决于什么"之类的短语.现在的实际问题是谁能直接受益于这样的质量代码,除了你自己,这也是你的成圣,道德,道德.

让我们举一个很常见的例子; 一个拥有数百万次点击的网站.最终用户很高兴,因为网站看起来很有吸引力,他们得到了订单 管理层很高兴,因为开发/改进是在预算范围内完成的,所有功能都已实施.PM很高兴,因为不知何故,团队及时交付了它.Tech Lead很高兴,因为所有异构子系统都按预期进行通信,并且满足基础设施约束.由25名开发人员组成的团队感到高兴,因为所有错误都已修复,现在他们的代码正在运行; 当然,他们有信心,因为他们使用类型安全的语言,伟大的IDE,他们会发现任何运行时错误的行号,因为尝试catch块无处不在.

在这里,让我们说,他们没有遵循任何模式或最佳实践.因此代码不可重用或逻辑层依赖于数据格式或......但对于下一个开发,会有新的预算,新的开发计划和开发人员获得可能不符合过去任务的新任务.

因此,通过遵循某些原则直接受益或必须强制执行消除这些原则的人可能需要在时间和预算方面支付一些额外费用吗？

然后谁在乎实际关注这些？每个人都知道它的理论重要性,但在实践中,它是"金色触摸"还是"有好处"特征或"必须具备"要求？如果它真的重要,那么正如许多人所说,为什么预算或时间被赋予最重要的意义,质量是第二重要.

我正在做一个相当大的项目,几年的制作,在一家大公司,我正在承担推动更好的整体代码质量的任务.

我想知道在这种情况下您将使用什么样的指标来衡量质量和复杂性.我不是在寻找绝对的措施,而是一系列可以随着时间的推移而改进的项目.鉴于这是一个跨越数百个项目的宏观操作(我已经看到一些问题涉及更小的项目),我正在寻找更自动化和整体性的东西.

到目前为止,我有一个如下所示的列表:

• 全功能测试期间的代码覆盖百分比
• BVT故障的反复出现
• 依赖图/分数,基于nDepend等工具
• 构建警告的数量
• 发现/抑制的FxCop/StyleCop警告的数量
• "catch"语句的数量
• 手动部署步骤数
• 项目数量
• 代码/项目的百分比"死",如在任何地方都没有引用
• 代码审查期间的WTF数量
• 总代码行,可以按层分类

Jenkins 警告下一代插件的管道文档指定了三个步骤变体：

• publishIssues：发布静态分析扫描创建的问题
• recordIssues：记录编译器警告和静态分析结果
• scanForIssues：扫描文件或控制台日志中是否有警告或问题

我刚刚尝试过这个简单的片段：

stage('QA checks') {
    steps {
        recordIssues([
            enabledForFailure: true,
            tools: [php()]
        ])
    }
}

并在构建页面上显示结果（“PHP 运行时：无警告”）。那么另外两步又有什么意义呢？

配置插件的正确方法是什么？应该像这样使用这三个部分吗？

stage('QA checks') {
    steps {
        scanForIssues([...])
        recordIssues([...])
        publishIssues([...])
    }
}

我想写一些高质量的C代码.有人能指点我一些文章,网站......无论我需要什么样的东西都有例子.我已经看过并阅读过K&R C书.

但时代已经改变,有些人必须对质量C代码有更多的说法.另一个重要的事情是你如何确保你作为程序员有书面质量的C代码？

我们接受了一些采访,我们正在招聘一名质量保证人员.开发人员参与的目的是了解他是否能够与开发团队合作.

开发人员应该向质量保证人员询问最重要的问题是什么？我正在寻找实际问题,而不是蓬松的开放式问题,你的想法？

我正在开发一个在线文件管理项目.我们在数据库(sql server)上存储引用,并在文件系统上存储文件数据.

当我们上传文件时以及删除文件时,我们正面临文件系统和数据库之间的协调问题.首先,我们在数据库中创建引用或在文件系统上存储文件.

问题是如果我先在数据库中创建一个引用然后将文件存储在文件系统上,但是在文件系统上存储文件时会发生任何类型的错误,那么该文件的引用是在数据库中创建的但没有文件数据存在于文件系统中.

请给我一些解决方案如何处理这种情况.我非常需要它.

我们删除文件时也会发生这种情况？

我们正在使用SonarQube 5.5(迄今为止最新).

我们的项目包含许多遗留代码,这些代码无法通过我们所需的质量门,因此我们决定忽略已经存在的技术债务,但要严格对待新的变更.

因此,我们正在享受泄漏概念和默认质量门,仅考虑新的变化.

我们使用持续集成和持续交付,因此我们为每个CI构建运行SonarQube分析,以便能够立即向开发人员反馈他们的更改是否未通过质量门,因此问题不会留到sprint结束或累积新的技术债务.

我们将Leak Period设置为previous_version,因为我们每次运行都会增加版本号,但据我所知,在我们的情况下,它可以设置为previous_analysis并具有相同的效果.

这种方法的问题在于下一个好的提交将清除项目的状态(绿色,是红色),因为对最后一次提交的分析将通过质量门.虽然代码已包含先前提交中引入的问题.

如果将"泄漏期间"设置为固定日期\版本(自定义日期或A版本选项),则将对累积提交进行分析,并且单个"错误"提交可能会被忽视,从而导致周期后期出现问题.所以它不满足"直接"要求.想象一下,在一个固定的日期\版本之后,有5个相同大小的提交 - 4个来自"好"的开发人员跟随TDD所以100%覆盖率,1个来自"坏"的人,其变化覆盖率为0%.平均而言,它将通过默认条件"新代码的覆盖率不低于80%",但实际上我们希望尽快向这些"坏"人提供反馈,以便他们改进他们的实践.

如果将"泄漏期间"设置为滚动分析前的天数,则自上次"错误"提交后经过此天数后,门的状态将立即清除,而代码中仍可能存在问题.

我们需要能够分析单个提交(类似于SQ中的"previous_version"泄漏期选项).但是如果最后一次提交通过QG而前一次提交失败,我们应该一起分析它们以查看最后一次提交是否实际修复了前一次提交的问题,以便整个项目可以被视为已通过.

因此,实质上我们应该分析自上次成功分析以来的所有提交

泄漏期没有这样的选择.有没有其他方法来实现这一目标？