14个文本转图像AI API
设计优先 API 开发：神话还是现实？
2024-12-05
设计优先这一概念在 API 开发领域获得了大量追随者。它承诺带来一系列好处，包括改善用户和开发人员体验、缩短上市时间并降低开发成本。出于这些原因，设计优先的支持者经常将其视为解决 API 开发和管理所面临问题的灵丹妙药。
但并非所有人都对设计优先方法充满信心。一些技术领导者认为，设计优先方法带来的问题和它解决的问题一样多，这让我们很多人不禁要问：为什么要采用设计优先方法？ API 推广者 Kin Lane 在LinkedIn上提出了这个问题：
API 设计优先是真的吗？还是我们只是在做梦？
这个问题问得很合理，而且回答也很有启发性。今天，我们将通过此主题的反馈来了解开发人员对这一概念的看法，并提出关于设计优先的四个非常明确的要点。
情况很复杂
许多开发人员认为，设计优先虽然在理论上很好，但总体而言，在现实中却是一个复杂的话题。实际上，要达到设计优先的利用和生产水平需要大量的投入，而这种投入并不总是那么容易实现。
Postman 企业解决方案工程师 Bryan Cross 表示：
“我想知道 100% 设计优先是否真的在软件开发的任何方面得到了充分实现/规范化。它一直有点理想化，但却因计划的现实、不断发布新功能的需要、竞争和技术债务而失败。”
这是一个非常突出的观点。设计优先的很多问题来自于这样一个事实：它需要完全接受，而这在实践中可能不切实际，尤其是在扩展和开发现有产品的团队中。在一个具有根深蒂固的产品思维模式的组织中，采用任何单一范式都是困难的。倡导一种可能与业务逻辑和方法存在根本冲突的范式，使得设计优先特别难以获得接受。
这种复杂性可能部分源于设计优先作为一种策略的推广和内部讨论方式。一些开发人员会拒绝新的做法，而且当核心价值主张不明确时，这一比例只会增加。因此，如果设计优先要成为一种合理的方法，它的好处需要得到验证和大规模推广。这些结果包括改进协作、更贴合业务逻辑、提高清晰度以及更好的用户和开发人员体验。
关键要点：设计优先并不是灵丹妙药，也不是一刀切的范式。
它取决于优秀的工具和标准
其他人则对设计优先的概念持更为积极的态度，并看到了未来巨大的增长潜力。微软高级云解决方案架构师 John Dohoney, Jr. 指出，“借助 Github Co-Pilot 等工具，API Code First 开始成为一种可行的方式。”Solo.io 客户成功主管兼 FlowStep 创始人 David Yonan 也持类似的积极看法，他指出，“[设计优先] 绝对是可行的，你只需要正确的框架、工具和方法。”
任何新技术的现实情况是，支撑它的结构对于长期成功至关重要。如果没有传输信号的布线系统，电话就什么都不是，如果没有工作站，互联网就什么都不是，等等。在设计优先的世界中，实际管理利用核心原则的项目开发和实施所需的工具对于长期成功和健康至关重要。因此，不成熟的设计优先策略引出了一个问题：目前存在的工具是否“足够”？
Kin Lane 指出，这种长期成功很大程度上可以通过有效的标准和模式来实现：
“应用和重复使用现有的标准和模式是其中的一个重要方面。投资以设计为先的行业标准机构，利用政府监管来激励变革，肯定会在自上而下的设计优先运动中发挥重要作用。”
与工具本身一样重要的，标准在其中发挥着巨大的作用。例如，我们都大规模使用 HTTP/S 来促进大规模的相互通信。我们都有电话，但我们使用特定的电气和电话连接来连接国家和地区。定义构成 API 有效设计的核心标准，然后讨论如何将其用作“第一”元素，对于使其成为增值主张至关重要。
关键要点：设计优先需要足够的工具和标准才有价值。
这取决于环境
许多人认为，设计优先的运用很大程度上取决于环境。普遍的看法似乎是，在某些特定情况下，设计优先确实有意义，Kin Lane 表示：
“设计优先并不总是所有项目的答案，并且它的应用在不同行业、不同企业和不同团队中会有所不同。”
想象一下，有人问你哪种连接更好：HDMI 还是 DisplayPort。这个问题遗漏了很多回答所需的背景信息。我们从哪个系统连接，将它连接到什么？支持哪些标准？我们需要音频还是只需要视频？需要多少台显示器？
答案可能千差万别。同样，在评估设计优先时，我们应该询问背景。设计优先的问题在于它在理论上是一个好主意，但实际应用却很少，还是更准确地说，设计优先在某些情况下是一个强大的解决方案，而将其作为万能药来推销则是错误的？
还有团队背景需要考虑。即使产品需要采用设计优先的方法，实施该方法的团队也可能没有得到适当的安排来获得其好处。Falabella Financiero 的解决方案架构师 Adriano López Núñez 在以下帖子中指出了这一点：
“我认为这在很大程度上取决于团队领导者角色的愿景，因为并非每个人对 API 生命周期都有相同的概念，因此 API-First 方法被扭曲，并增加了‘快速行动’的迫切需要。”
关键要点：设计优先在特定用例和团队结构中具有重大优势，但它并不是万能的。
设计优先还有尚未开发的潜力
许多开发人员认为，设计优先已经引起了巨大的轰动并带来了巨大的好处，而许多讨论都忽略了这些积极因素。Delta 高级 API 设计师 Miguel Quintero 指出：
“这是真的。软件开发的每个阶段都像过山车一样考验你的耐心和领导能力。”
设计优先，或 API 优先，具有很大的优势，但在应用中也带来了很大的复杂性和困难。ServiceNow 的解决方案顾问 Bobby Lancaster 提出了一个有趣的观点，他认为设计优先的阻力可能来自于许多 API 公司过于注重微观：
“这是真的。我们只是梦想不够大。我记得我们讨论过 JCR Licklider 和他对互联网的愿景：星际计算机网络。如果你从星际的角度考虑联网计算机，那么 API 优先的设计是有意义的。”
这个概念有其可取之处。如果互联网的最终目标是成为一个庞大的互联计算机网络，那么采用设计优先的理念就更有意义了。不过，有人可能会说，这种网络的每个部分仍然需要作为自己的服务（或宏微服务）运行，如果是这样的话，设计优先可能对整体有利，但对单个解决方案不利。
关键要点：设计优先具有巨大的潜在上升空间。
设计优先的例子
设计优先并不局限于理论：设计优先确实取得了成效，这已有几个案例。一个具体的例子是微软的 Maho Pacheco 和 Renato Marciano 的工作，他们通过微软开发者博客详细介绍了设计优先的开发过程。他们特定的环境代表了设计优先方法的最佳情况：需要一种具有固定合同的新产品，在指定的框架和结构内处理大量数据。
在这种情况下，设计优先是一个强大的解决方案。因为需要一份牢固的合同，而对大量数据的合同遵守对于持续成功至关重要，所以建立设计优先方法可确保新产品从第一天起按预期运行和扩展。团队受益匪浅，因为这既是一个新产品，也是一个团队可以转向设计优先方法的产品。如果团队一直在开发一种没有单一合同或形式和功能的成熟产品，那么设计优先可能会更难利用。如果该团队的结构也不适合这种方法，那么就会困难得多。
结论
面对这么多不同的意见，设计优先到底处于什么位置？事实上，人们对设计优先的看法与人们如何看待他们的 API 有很大关系。刚进入开发过程的人可能会认为设计优先是一个强大的概念，因为他们正处于开发生命周期的开始阶段——障碍很少，很容易克服。另一方面，企业开发人员可能会认为设计优先是一种几乎没有好处的转变，需要进行重大改革。
事实上，他们都是对的。设计优先通常被认为是一种万能的解决方案，但事实上它只是一种选择。就像扳手实际上只适合“扳手的东西”，螺丝刀只适合拧螺丝一样，设计优先的适用性和实用性范围很窄，无法为所有团队和情况建立普遍价值。
