非功能性需求：质量

搭建你的项目
开发部门经常被低估的一个方面是项目结构缺少标准。文件放置位置的固定定义有助于团队成员快速找到兴趣点。Java 项目的这种元结构由构建工具Maven定义。十多年前，公司对 Maven 进行了测试，并很乐意将该工具应用于他们在项目中使用的既定文件夹结构。鉴于越来越多的软件开发基础设施工具被使用，这导致了繁重的维护任务。这些工具按照 Maven 定义的标准运行，这意味着每个定制都会影响集成新工具或将现有工具更换为另一个工具的成功。

另一个需要关注的方面是公司范围内定义的 META 架构。如果可能，每个项目都应该遵循相同的 META 架构。这将减少新开发人员加入现有团队并赶上其生产力所需的时间。这个 META 架构必须是开放的，可以通过两个简单的步骤实现：

不要在意太多细节； 
遵循KISS（保持简单，愚蠢。）原则。 
违反 KISS 原则的经典模式是标准被大量定制。George Schlossnagle 在他的“高级 PHP 编程”一书中描述了一个很好的例子来说明强定制的效果。在第 21 章中，他解释了在采用原始 PHP 核心而不遵循推荐的扩展方式时为团队带来的问题。这导致 PHP 版本的每次更新都必须手动操作，以将其自己的开发适应性包含到核心中。结合起来，结构、体系结构和 KISS 已经定义了三个易于实施的质量门。

托管在GitHub 上的开源项目 TP-CORE关注上述结构、体系结构和 KISS。在那里你可以找到他们如何将其付诸实践的方法。这个小型 Java 库严格定义了目录结构的 Maven 约定。为了快速兼容性检测，版本由语义版本控制定义。选择层结构作为其体系结构。对其主要架构决策的检查得出如下结论：

每一层都由自己的包定义，文件也遵循严格的规则。没有使用特殊的 PRE 或 POST-fix。例如，功能 Logger 由 称为Logger的接口 和相应的实现  声明。API接口可以在包“ business”中检测到位于包“ application ”中的实现类。 LogbackLogger应该避免像 ILogger 和 LoggerImpl 这样的命名。想象一个 10 年前开始的项目，LoggerImpl 基于 Log4J。现在出现了一个新的需求，需要在运行时更新日志级别。为了解决这个挑战，可以用 Logback 替换 Log4J 库。现在可以理解为什么像接口一样命名实现类是个好主意，结合实现细节：它使维护更容易！在 Java 标准 API 中也可以找到相同的约定。该接口  List 由  ArrayList. 显然，接口没有被标记为 IList 之类的东西，实现也没有被标记为  ListImpl .

总结这个简短的段落，定义了一个完整的测量规则集来描述我们对结构质量的理解。根据经验，这个描述应该很短。如果其他人能够很容易地理解你的意图，他们就会愿意接受你的指导，尊重你的知识。此外，架构师将更快地检测到违反规则的情况。

衡量你的成功
最困难的部分是保持干净的代码。有些建议本身并不错，但在您的项目上下文中，可能证明没有用。在我看来，最重要的规则是始终激活编译器警告，无论您使用哪种编程语言！准备发布时，必须解决所有编译器警告。处理关键软件的公司，如 NASA，在他们的项目中严格应用这条规则，从而取得了巨大的成功。

关于命名、行长度和 API 文档（如 JavaDoc）的编码约定可以通过 Checkstyle 等工具简单地定义和遵守。此过程可以在构建期间完全自动运行。当心; 即使代码检查器在没有警告的情况下通过，也不意味着一切都在最佳状态。例如，JavaDoc 是有问题的。使用自动 Checkstyle，可以确保此 API 文档存在，尽管我们不知道这些描述的质量。

在这种情况下应该没有必要讨论测试的好处；让我们来看看测试覆盖率。应遵循测试用例中 85% 覆盖代码的行业标准，因为低于 85% 的覆盖率将无法覆盖应用程序的复杂部分。100% 的覆盖率只会快速消耗您的预算，而不会带来更高的收益。一个典型的例子是 TP-CORE 项目，其测试覆盖率大多在 92% 到 95% 之间。这样做是为了看到真正的可能性。

如前所述，业务层仅包含定义 API 的接口。该层明确排除在覆盖检查之外。另一个包称为内部包，它包含隐藏的实现，如 SAX   DocumentHandler。由于  DocumentHandler绑定到的依赖项，即使使用 Mocks 也很难直接测试此类。鉴于此类的目的仅供内部使用，这是没有问题的。此外，该类由使用  DocumentHandler. 为了达到更高的覆盖率，也可以选择将所有内部实现排除在检查之外。但是观察这些类的隐式覆盖以检测您可能没有意识到的方面始终是一个好主意。

除了低级单元测试外，还应该运行自动化验收测试。密切注意这些要点可能会避免各种问题。但千万不要盲目相信那些全自动支票！定期重复手动代码检查将始终是强制性的，尤其是在与外部供应商合作时。在 JCON 2019 的演讲中，我们展示了如何简单地伪造测试覆盖率。要检测其他漏洞，您还可以运行 SpotBugs 等检查程序。

测试并不表示应用程序没有故障，但它们表示已实现功能的定义行为。
一段时间以来，GitLab 或 Microsoft Azure 等 SCM 套件支持很久以前在 GitHub 中引入的拉取请求。这些工作流程并不是什么新鲜事；IBM Synergy 曾经应用过相同的技术。构建经理负责将开发人员的更改合并到代码库中。以快速的方式，开发人员执行的所有修订都只是由构建经理添加到存储库中，构建经理没有足够深厚的知识来决定实施质量。通常的做法是简单地确保构建没有被破坏，并且编译总是产生一个工件。 

企业发现这是处理拉取请求的新策略。现在，经理们经常决定使用拉取请求作为质量门。根据我个人的经验，这会降低生产力，因为在代码库中提供更改之前需要时间。了解分支和合并机制可以帮助您决定更简单的分支模型，例如发布分支线。在这些分支上，诸如SonarQube之类的工具运行以观察总体质量目标。

如果一个项目需要一个精心编排的构建，并定义了如何创建工件的顺序，那么您就有一个强烈的重构提示。
类和模块之间的耦合经常被低估。很难对模块的绑定进行自动可视化。当由于构建逻辑的复杂性增加而违反光耦合时，您会很快发现它所产生的影响。

重复你的成功

放心，改变会发生的！让您的应用程序保持开放以进行调整是一项挑战。之前的一些建议对未来的维护有隐含的影响。良好的源质量简化了准备工作。但不能保证。在最坏的情况下，产品生命周期结束，即达到 EOL，例如，由于代码库受到侵蚀而无法再实现强制性改进或更改。

如前所述，光耦合在维护和再利用方面带来了许多好处。实现这个目标并不像看起来那么困难。首先，尽量避免包含第三方库。只是为了检查 String 是否为空或 NULL，不需要依赖外部库。这几行自己很快就搞定了。与外部库相关的第二个要点是：“只有一个库可以解决问题。” 如果您的项目处理 JSON，则决定采用一种实现方式，不要合并各种工件。这两点严重影响安全性：我们可以避免使用的第三方工件将不会导致任何安全漏洞。

在决定外部实现后，尝试通过应用代理、外观或包装器等设计模式来覆盖项目中的使用。这允许更轻松地进行替换，因为代码更改不会散布在整个代码库中。如果您遵循有关如何命名实现类和提供接口的建议，则无需立即更改所有内容。尽管 SCM 是为协作而设计的，但当多人编辑同一个文件时存在局限性。使用设计模式来隐藏信息允许您迭代更新您的更改。