正确的非功能性需求

写在文章开头

软件的质量涵盖了功能性、性能、可靠性、可维护性、可移植性等多个方面。工程师编写的代码，首要满足的是功能性需求，即满足基本的业务需求。除此之外，还需要满足其他质量方面的要求。在实际编码过程中，功能性的质量交付通常是完整且经过充分验证的，而其他非功能质量的交付结果却常常存在不确定性。这主要是由于以下几个方面的原因：

1. 需求中并未明确包含非功能质量要求，或者因为非功能性质量不会直接影响功能性能质量，所以在分析、设计、交付和验收过程中未对其投入足够的关注。

2. 系统架构原则在交付过程中的约束较弱，无法充分识别或保证非功能质量需求的交付。

3. 团队的研发规范和机制未强调或约束对非功能质量的关注和交付。

4. 个体的非功能质量交付行为受个体研发能力的影响较大，质量参差不齐。

5. 功能性质量可以通过有无来直接界定，而非功能质量大多数情况下只能用程度指标来度量，因此为交付非功能质量而做的投入容易被权衡。

6. 非功能需求的交付一般是借助研发平台的能力，遵循一些优秀实践来落实；但由于优秀实践的约束一般比较弱，具体实践时受个体的认知差异影响比较大。

本文将以Java语言为基础，解读与非功能性质量交付相关的几个概念或实践。这些概念或实践在实际应用中经常被混用或误用，从而影响非功能质量的交付水平。通过解释并比较这些概念或实践，帮助大家理解它们的本质，并给出实践建议以提升非功能性质量的交付水平。对于互联网平台这样的应用来说，非功能性质量很多时候是研发人员为自己交付的。作为工程师，我们应该充分理解这些相似概念，并在实际编码中加以应用。

下面，我们来谈谈几对概念：

一、注释、Javadoc与代码自注释

注释、Javadoc和代码自注释都是为了让代码的维护者或使用者更好地理解代码而存在的。在Java编程中，注释是程序员在代码中添加的文本，用于解释代码的逻辑或记录开发过程中的思考过程。Javadoc则提供更详细的类、接口、方法和字段的说明，描述代码的业务语义和业务能力。而代码自注释则是一种编写代码的实践，旨在通过清晰、简洁的代码结构和命名来传达代码的意图，使代码本身就像文档一样易于理解。正确区分和使用这三者，可以显著提高代码的可读性和质量，降低维护成本，提高团队协作效率。

二、异常信息与异常日志

在Java编码中，当需要处理异常时，我们会异常信息并将之向上抛出，同时打印异常日志。这两者以不同的方式反馈系统异常情况，帮助理解和解决问题。在实际编码中，我们需要充分考虑异常信息和异常日志在维护中的不同作用，避免处理异常但不打印日志、随意输出异常信息等情冠发生。正确的处理方式可以极大地降低系统维护的难度和成本。

三、程序异常与业务错误

程序执行时可能会得到正确、错误和异常三种结果。错误属于程序正常执行的范畴，而异常则是程序运行时出现的不正常情况。以用户登录场景为例，用户输入用户名和密码后可能得到三种结果：正确登录、业务错误（如用户不存在、密码错误等）和程序异常（如登录服务不可用）。正确处理业务错误和程序异常是提升系统可维护性和可用性的关键。

四、标准化与特例化

在软件架构和代码设计中，标准化是一种常见策略，通过构建标准层来隔离上层和下层应用，实现模块化和低耦合。标准化有助于提高系统的可维护性、可移植性和灵活性。然而在实际开发中，有时为了满足特定需求（如性能优化），上层应用可能需要利用下层实现的特性，导致对标准接口的偏离。这时需要权衡标准化和特例化的利弊。同时还需要注意标准接口仅仅是标准化范式的一种表现形式，其他的还包括标准规范、优秀实践等。标准化能够消除依赖方变化带来的不稳定性；而特例化可能会标准化的收益甚至带来负面影响。因此在实际应用中要根据具体情况进行选择和应用。