软件质量指南

Defect和Bug翻译成中文都是缺陷的意思，两者有什么区别？Bug是编程错误的结果，Defact缺陷是与需求的偏离。Defect缺陷不一定表示代码中存在bug，它可能是尚未实现但在软件需求中定义了的功能。测试是识别缺陷defact的过程，Defect缺陷是实际结果与预期结果

研究表明，人为因素最影响我们的工作质量，可是为什么我们会投入更多精力希望通过技术性解决方案解决软件质量呢？假设您经营一个新团队。您可以一刀切地实施任何您想提高人员生产力和减少代码错误的策略。你会做什么？进行配对编程！切换到Haskell！使用UML进行所有操作！这些技术都有自

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

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

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

为什么我们不同意罗伯特·马丁的

在过去的三年中，我已经审查了1000多个拉（合并）请求。在那段时间里，我学到了很多东西–主要是关于如何不审阅代码，如何减轻过程的痛苦，使高质量的代码产生什么等等。 拉取请求只需要做一件事最好的办法是将请求合

在本文中，我将探讨2007年Windows Vista发行失败后Microsoft Research的发现。Microsoft决定深入研究并找出问题出在哪里。Microsoft Research提出了一个AI模型来预测代码库中的错误数量，而按准确性排序的主要预测指标是:

我的代码不是固体SOLID，而是液体LIQUID：Low In Quality, Unrivaled In Despair（品质低劣，绝望无可匹敌） 众说纷纭：我的代码是KISSNUWYD：Keep it so stupid nob

牢记业务上下文的技术决策建议，业务上下文是唯一的衡量软件质量的关键指标。如果有事情不对劲，软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地，我们对更高层次的抽象感到不安：我们不再会像当初因缺乏理解而烦恼，而是知道系统确实属于有害反模式时，会更加不安。

在过去的几十年中，西方的正念冥想已经从边缘练习变成了主流现象。它的诺言，随着它在无数书籍和应用程序中出售给我们，令人着迷：这是一种使自己冷静下来并展现在自己面前的简单技术。它被视为我们紧张生活的灵丹妙药。如今大多数员工的压力很大。盖洛普民意测验大约在四，五年前进行，民意调查显示，企业

熟悉TDD的三个定律这些规则是在实践中使用TDD的基础。它们限制我们一次只更改一件事。他们迫使我们采取步伐！记住并严格遵守这些规则，以便有效地使用TDD！在代码没有通过失败的单元测试之前不要编写任何生产代码。没有遭遇更多失败还有编译错误之前不允许编写更多的单

编程中不断调整改变各个地方，直至让其能够正常运行，这种方式称为黑客式编程，是一种坏的代码最佳实践；如果你这样做得足够快，它就是“机器学习”了，而且会付给你比当前高四倍的薪酬。 

本文指出了所有开发人员在审查其代码或提交拉取请求时可能遇到的特定反模式，并对此进行了谴责。代码作者花了数小时甚至数天的时间来创建他们认为最有效的解决方案。他们考虑了多种设计方案，并采取了最相关的道路。他们考虑了现有应用程序架构，并在适当的位置进行了更改。然后他们将其解决方案作为请求请