软件质量指南

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

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

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

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

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

PHP是一种动态语言，虽然这肯定有它的好处，但它也意味着在日志中看到调用未定义方法或无效参数计数的错误并不罕见。更糟糕的是，当发生这些类型的错误时，应用程序将简单地崩溃，从而导致糟糕的用户体验和沮丧的客户。这个问题的解决方案是静态分析。对于像Java和C＃这样的语言，这不是什么新东西

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

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

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

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

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

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

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

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