不要将你的 API 设计得过于简单

原副标题：千万别将你的 API 结构设计得过分单纯

关于计算机科学的事实真相

架构这般这般

有啥架构、库和服务项目的存在实际上是为了让你撰写更慢的标识符？几乎所有的架构都是这般。

为何我们有这么多架构，每月还会出现两个捷伊？这原因在于两个架构企图让控制系统显得单纯，在那个过程中却导致了操控性难题或代码上的诸多不便。

两个懊恼的使用者说：“我要写两个彻底消除那个难题的新架构。” 他写了两个更慢的新架构。只是时间难题，另两个懊恼的使用者就会发现另两个难题，并写下两个捷伊架构。

这是两个连续不断的困局。

你的控制系统很繁杂。这既并非坏事也并非坏事，有些控制系统其本质上是繁杂的，因为它与生俱来这般。

假如你企图精简控制系统，那就是违反它的其本质。清洁标识符体育运动对你没有协助，就像面向对象体育运动一样。

千万别认为将控制系统降解为小部份会使它显得单纯。现在你有很多项目组，他们被拆成了分立的部份，误以为这样就单纯了。幼稚是技师的敌方。控制系统不能透过部份来认知。它或者全部认知，或者不屑一顾。

这是你难以获得的遭遇战。

API 代表插件程式设计USB。它与控制系统进行USB可视化，拒绝接受控制系统的虚无样子，包括它的迷人、声名狼藉、单纯和复杂的部份，以及其中的严重错误和优点。

千万别装作你的控制系统是单纯的，透过曝露两个仅展现其幸福另一面的外露 API。你在向顾客提供不实的抽象化，最后这种抽象化会外泄，引起难题，并对顾客产生负面影响。

构筑两个 API 来抽象化繁杂性，使顾客端更易使用，就像冲破青带，让兔子难出来一样。然而，最后兔子将难以分立生存，调用该 API 的前端也将这般。

顾客端最后会遇到意想不到的副作用，例如操控性延迟、高 CPU 使用率、高内存使用率或高网络使用率。

抽象化总是会外泄。

你可以曝露控制系统的真实其本质，但可以设置默认值，认为这些默认值适用于大多数情况。虽然有用，但大多数顾客端会选择走捷径，使用默认值而不去认知它。

他们又回到了同样的沉船上，只不过这艘沉船上有一艘救生艇，开发人员可以依附其上。他们查看默认值并认知出了难题所在，并在必要时进行覆盖。

假如你将控制系统曝露出来，那个难题本不会发生。

你可以尝试消除控制系统的繁杂性，而并非隐藏它。你可以用两个看起来单纯的部份来替代它。这样做可能会解决一些难题，但请注意，捷伊繁杂性可能会出现。两个捷伊怪兽诞生了。旧怪兽可能被杀死，但它可能仍然存在。

亲爱的顾客，你可以使用两个单纯的后端 API，但请认知那个 API 可能并不真的单纯。千万别认为它理所当然，相反，深入了解它的繁杂性，认知它是如何构筑的。

透过了解 API，你不仅会欣赏它，而且在 API 所创建的抽象化外泄到你这里时也会做好准备。你将准备好保护你的前端堡垒，也可误以为修复后端做出贡献。

拥抱繁杂性，认知它并与之共同工作。这可能会开花结果，带来有效的操控性，也可能会意外地诞生两个完全自由且真正完美的全新控制系统。

两个真正单纯的控制系统。

这篇文章中的所有内容都不构成建议或行动号召。把它看作是一束在黑暗房间里首次照亮的蜡烛光。