大数据项目管理：从规划到实现

接口设计

｜

67

有一个笑话：命名是软件开发中最困难的事情之一。我们发现，减少命名时间的最佳做法

是重用同一生态系统中其他优秀项目的命名风格。这样做有以下优势。

•

提供了可遵循的指南。

•

提供了客观的外部参考来支持决策。

最后，无论曾多么努力地设计，一两年后回顾时，都会希望自己当时能够做得更好。这就

是这个世界的本质。以简单和可重复为目标可能是最好的选择。

4.3

　非功能性考虑因素

前文提到，在设计接口时需要考虑一些次要的非功能性因素，包括系统的可用性、响应时

间和负载容量。本节将探讨这些考虑因素。

4.3.1

　可用性

所有接口都需要指定功能性合约，用于定义服务访问或与外部系统交互的接口还需要指定

可用性合约。如果是为本地程序库定义合约，那么定义可用性就无关紧要了。但是，如果

接口涉及外部服务，那么就要提供明确的服务可用时间和服务可用性保证级别。

可以将此视为给定服务的营业时间，以及为客户承诺营业时间的保证级别。在现实世界

中，超市和影院都有规定的营业时间：假设超市是从早上

6

点营业到晚上

10

点，影院是

从上午

10

点营业到午夜

12

点。

根据规定的营业时间，我们对超市和影院的开放时间有了一定的了解。不过，可能会发生

一些事情扰乱预期的开放时间。例如，在暴风雪期间，影院可能会关门，而超市仍然会营

业。在这种情况下，可以认为超市比影院具有更高的保证级别。

需要有两种可用性定义：一是服务何时可用，二是可用时间的保证级别。

你可能会问：“在计算机世界里，服务不应该总是可用的吗？”来看一下不同可用性级别

的示例。



计划维护时间窗口 ...