软件质量指南

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

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

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

如果有人说您只能对一个软件项目执行一次质量实践，您会选择什么？我会选择对需求进行同行评审，我认为这是我们今天可用的最高杠杆质量实践。在同行评审中，工作产品的作者以外的其他人检查产品的质量问题和改进机会。审查需求是一项强大的技术。使用它们来识别模棱两可或不可验证的需求，查找尚未足够详细

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

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

比尔盖茨说过：人们不会为修复bug付费，只为新功能付钱。技术债务作为Bug产生的根源，技术债务只是针对开发人员而言，如何能做到向最终用户收费？创造新的商业价值？KentBeck提出投资改善体系结构或架构，这样比单纯去修复bug、重构等还请技术债务的方式会更好吗？

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

作为开发人员，我们都知道代码审查在理论上是一件好事。他们应该帮助我们： 尽早发现错误和安全问题 提高代码的可读性 提供安全网以确保所有任务完全完成 现实情况是，代码审查对于每个参与者来说经常是一种令人不舒服的体验，导致审查变得好斗，无效甚至更糟，根本

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

软件系统是容易的积聚一些累赘cruft  : 内部质量不高，导致其比预想更难进行修改和进一步扩展系统。技术债务是沃德坎宁安（Ward Cunningham）创造的一个比喻，它描述了如何考虑处理这种问题，将其视为金融债务，增加新功能所需的额外成本是债务利息。<

质量软件取决于许多因素，但开发人员是最重要的因素之一。糟糕的软件往往是我们的错，通过问自己正确的问题，我们也可以为好的软件做出贡献。 这是对的吗？ - 代码是否实现了规范。如果没有明确的规范，你是否做了足够的努力来找出预期的行为。并且这种行为是以某种方式测试的 - 最好通过自

我一直想在一个真实的项目中进行Mob编程，直到在一年前的一个为期三天的黑客马拉松中进行了实验 - 它的表现非常出色。几周前，我终于有机会与我的工程团队一起开发新的Kotlin / SpringBoot应用程序。这是我在前几届会议后的想法和经验教训。

这是一篇从心理模型也就是心智模型角度分析编码的文章，比较晦涩难懂，实际上中心意思是，每段代码其实只是人在编写这段代码时的心智模型投射，我们不能把代码看成是客观的存在，而是主观的产物，甚至参合了当时心理活动或各种直觉感知，因此，当我们修改这段代码时，一般也需要将自己的心智模型接近到当时编写这段

在测试代​​码时，仅为每种方法编写一个或两个单元测试是不够的。编写单元测试时，目标不

顶顶大名的Redis作者谈如何在Redis这样系统软件上进行代码文档注释，以下是九种注释类型的大意说明： 很长一段时间以来，我一直想在YouTube上发布一段“如何对系统软件文档注释”的新视频，讨论如何进行代码注释，然而，经过一番思考后，我意识到这个主题更