软件质量指南

     

干净代码的几个特点 -Xebia

2254 1 2K

干净Clean代码特点:易于他人使用(直截了当,意图清晰,抽象性好,毫不意外,好名声)-这是最受关注的问题。 它是针对现实世界制作的,即具有清晰的错误处理策略。 它是最小的(做一件事,具有最小的依赖性.

软件质量的认识论:每晚有多少睡眠?你工作愉快吗?这些是最影响软件质量的问题。 - increment

1646 2 2K

研究表明,人为因素最影响我们的工作质量,可是为什么我们会投入更多精力希望通过技术性解决方案解决软件质量呢?假设您经营一个新团队。您可以一刀切地实施任何您想提高人员生产力和减少代码错误的策略。你会做什么.

敏捷大师:衡量程序员好不好的标准是代码越少越好 - Allen Holub

2002 2

大多数KPI指标毫无价值。绝对最佳的程序员所编写的代码少于能力较弱的程序员。最好的衡量标准是编写的代码少,代码越少越好。实际上,删除代码是您可以执行的最有效的操作之一。负生产力反而是一个加号。测量代码.

鲍勃大爷调查提问:两者哪个更昂贵?A.在代码中添加难以更改的功能。B.保持代码足够灵活性以轻松添加新功能。

2005 1

众说纷纭:灵活性可能导致更多的设计时间和复杂性。这个词本身看起来不错,但没那么简单。我现在正在(艰难地)学习到,随着复杂性的增加,维持软件项目中的变化速率变得越来越困难。如果我可以回去一年,我肯定会在.

需求审查的挑战 - modernanalyst

2317 1 2K

如果有人说您只能对一个软件项目执行一次质量实践,您会选择什么?我会选择对需求进行同行评审,我认为这是我们今天可用的最高杠杆质量实践。在同行评审中,工作产品的作者以外的其他人检查产品的质量问题和改进机会.

幽默:一天写了36行代码就很了不起吗? - Coraline Ada Ehmke

2478 5

我:“今天我写了36行非常不错的代码。”兰多:“只有36行?我以为你是个了不起的开发人员。”我:“我写的是正确的36行。众说纷纭:我今天坐在那里想了四个小时。我认为这为我节省了大约6个星期的代码编写时.

可确保项目的质量和安全性的三个Maven插件 - rieckpil

2421 9K

检测依赖项内部的漏洞对于创建安全的应用程序至关重要。除此之外,静态代码分析工具和预定义规则可以帮助您确保质量。幸运的是,有Maven插件可用于在您的构建中自动执行此操作。通过此博客文章,我将向您展示我.

KentBeck:“改善架构”比“还清技术债务”可以带来更好的感觉,决定和结果。

2253 1 2K

比尔盖茨说过:人们不会为修复bug付费,只为新功能付钱。技术债务作为Bug产生的根源,技术债务只是针对开发人员而言,如何能做到向最终用户收费?创造新的商业价值?KentBeck提出投资改善体系结构或架.

谷歌代码评审指南已经开源

1494

基于长期经验,本节中的页面包含有关进行代码评审的最佳方式的建议。它们共同代表了一个完整的文档,分为许多单独的部分。你不必全部阅读它们,但很多人发现它对自己和他们的团队阅读整套都很有帮助。 代码评审标准.

鲍勃大叔:走得快的唯一方法就是好好地走

1661 1

鲍勃大叔:软件中没有质量与速度的权衡,从来没有。低质量意味着低速。走得快的唯一方法就是好好地走。众说纷纭:1. 我最喜欢的版本是“没有快速和脏,只有脏。”2. 那就是你的思维方式。当您需要的预算有限且.

最好的语言也敌不过人类愚蠢:使用PHPStan通过静态分析尽早捕获PHP错误 - madewithlove

4134

PHP是一种动态语言,虽然这肯定有它的好处,但它也意味着在日志中看到调用未定义方法或无效参数计数的错误并不罕见。更糟糕的是,当发生这些类型的错误时,应用程序将简单地崩溃,从而导致糟糕的用户体验和沮丧的.

Google代码评审介绍 - Michaela Greiler

1753 5K

Google的代码评审在工程实践中发挥着重要作用,并且早在谷歌就已经采用。直到今天,它们仍然用于保持代码库的清洁,连贯并确保不提交任意代码。尽管代码评审过程与Microsoft的代码评审类似,但有一些.

代码审查或评审的最佳实践 - FogBugz

2277 1 3K

作为开发人员,我们都知道代码审查在理论上是一件好事。他们应该帮助我们: 尽早发现错误和安全问题 提高代码的可读性 提供安全网以确保所有任务完全完成 现实情况是,代码审查对于每个参与者来说经常是一种令人.

软件设计是隐形设计,主要受众是其他设计师 - Mathias Verraes

927

决策者一般习惯于设计能够产生可见结果的东西:事物外形,用户界面,功能,体验,但是他们很难理解为什么他们应该关心软件设计。(这是说给甲方 或老板听的)软件设计也会对用户产生影响。如果软件的模型与业务领域.

高质量的软件是否能赚回成本? - Martin Fowler

1958 2 4K

软件开发项目中的一个常见争论是:该不该花时间提高软件质量,还是把时间专注于不断发布更有价值的新功能。通常,倡导把时间用于提供新功能的交付派别会赢得这场讨论胜利,导致许多开发人员抱怨他们没有时间研究架构.

权威解读什么是技术负债? - martinfowler.com

1614 2 3K

软件系统是容易的积聚一些累赘cruft  : 内部质量不高,导致其比预想更难进行修改和进一步扩展系统。技术债务是沃德坎宁安(Ward Cunningham)创造的一个比喻,它描述了如何考虑处理这种问题.

关于你的代码请问自己七个问题 - Bozho

799

质量软件取决于许多因素,但开发人员是最重要的因素之一。糟糕的软件往往是我们的错,通过问自己正确的问题,我们也可以为好的软件做出贡献。 这是对的吗? - 代码是否实现了规范。如果没有明确的规范,你是否做.

使用Mob编程开发的经验教训 - Jasmin Fluri

2154 2K

我一直想在一个真实的项目中进行Mob编程,直到在一年前的一个为期三天的黑客马拉松中进行了实验 - 它的表现非常出色。几周前,我终于有机会与我的工程团队一起开发新的Kotlin / SpringBoot.

针对编码和系统的高效之心智模型

1062 5K

这是一篇从心理模型也就是心智模型角度分析编码的文章,比较晦涩难懂,实际上中心意思是,每段代码其实只是人在编写这段代码时的心智模型投射,我们不能把代码看成是客观的存在,而是主观的产物,甚至参合了当时心理.

四个必不可少的Java圈复杂度测试工具

7040 1 2K

在测试代​​码时,仅为每种方法编写一个或两个单元测试是不够的。编写单元测试时,目标不是测试每个方法,而是测试方法可能执行的每条指令。并且由于方法在复杂性方面可能有很大差异,因此对于开发人员来说,编写单.

Redis作者谈如何编写系统软件的代码注释

1348 2 8K

顶顶大名的Redis作者谈如何在Redis这样系统软件上进行代码文档注释,以下是九种注释类型的大意说明:很长一段时间以来,我一直想在YouTube上发布一段“如何对系统软件文档注释”的新视频,讨论如何.

只有不容忍才能提升软件质量

1 1025

虽然称为不容忍,但其实有认真的含义,属于偏执狂才能生存的逻辑。该文认为:无论是软件开发团队的一员还是“软件开发协会”:对质量的最大影响并不是通过达成共识、投票或者容忍他人的观点或编码方式来实现的。对软.

要性能,还是要设计?

33 4455

今天到新公司上班,写了一段非常简单的代码,负责把数据库一个表的log逐条显示出来,我写了一个XXLog类,用一个静态方法得到一个Iterator,里面容纳查询到的XXLog:public class .

如何看源码?请大家讨论

32 4438

1、类图肯定要生成,但是跨package就麻烦,如何解决。2、先模拟client 运行一个例子,调试进入source,好像会太琐碎,没有大局观。3、文档肯定要看的,但是好像一般没有设计文档。希望大家讨.