软件质量指南

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

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

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

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

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

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

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

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

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

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

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