language-agnostic - 首先使用 API 编写代码，然后是实际的 API - 这种方法是否有名称并且对 API 设计过程有效？

Question

处理新 API(库、类等)的标准方式通常如下所示:

你想想 API 用户需要什么方法

你实现了你怀疑用户需要的 API

所以基本上你试图猜测你的 API 应该是什么样子。它经常导致过度工程化的东西，巨大的 API，你 想 用户将需要并且很有可能您的大部分代码根本不会被使用。

前段时间，甚至可能是几年前，我读过一篇提倡先写客户端代码的文章。我不记得在哪里找到了它，但作者指出了几个优点，比如更好地理解 API 的使用方式、它应该提供什么以及基本上已经过时的内容。我认为想法是它与 SCRUM 方法和用户故事相结合，但在实现层面。

只是出于对我最新的私有(private)项目的好奇，我开始的不是实际的 API(某种工具包库)，而是使用该 API 的客户端代码。当然，我的代码都是红色的，因为类、方法和属性不存在，我可以忘记智能感知的帮助，但我注意到，经过几天的编码，我的应用程序“具有”所有基本功能，而我的库 API“是“比我开始一个项目时想象的要小得多。

我并不是说如果有人拿走了我的库并开始使用它，它不会缺少某些功能，但我认为它帮助我意识到我对这个 API 的想法有些缺陷，因为我通常会尝试涵盖所有基础并提供方法“以防万一”。有时它让我很伤心，因为我在基本功能上犯了一些愚蠢的错误，更专注于某人可能需要的代码。

那么我想问您，您是否曾经在需要创建新 API 时尝试过这种方法，它对您有帮助吗？它是某种公认的有名字的技术吗？

Answer 1

So basically you're trying to guess what your API should look like.

这是以这种方式设计的最大问题:在软件设计中不应该有(嗯，最小的)猜测。基于假设而不是实际信息设计 API 是危险的，原因如下:

这直接违背了 YAGNI 的原则:为了完成任何事情，您必须假设用户将需要什么，而没有任何信息来支持这些假设。

当你完成后，你终于开始使用你的 API，你总是会发现它使用起来很糟糕(糟糕的用户体验)，因为你没有考虑如何使用库(UX)，你是思考图书馆必须做什么(功能)。

根据定义，API 是用户(即开发人员)的接口(interface)。像其他任何东西一样设计只会导致糟糕的设计，不会失败。

编写示例代码就像在编写后端之前设计一个 GUI:一件好事。它迫使您考虑设计决策的用户体验和实际效果，而不会陷入无用的理论和假设中。

与 Gabriel 的回答相反，这不是自下而上的设计:它是自上而下的。与其设计库的具体后端，然后在其之上强制使用抽象接口(interface)，不如先设计接口(interface)，然后再考虑实现。