理念与设计原则
本文档为 Sentry 上的 SDK 开发设置了一些常规指南。它应该帮助内部和外部开发人员了解 SDK 的设计动机以及为什么我们以某些方式做出决定。
依赖成本
依赖是有成本的，而且成本很高。我们使用的每一个依赖都增加了 SDK 的体积，并增加了更多的许可、维护和安全问题。我们知道依赖关系对于支持集成是必要的，但是对于 SDK 的基本功能来说，绝对不需要依赖关系。显然，每个规则都有例外，在某些平台上，如果没有基本的依赖关系，我们将无法工作。一个很好的例子是 Python，我们需要一个 HTTP 请求的外部库来安全地发送 HTTP 请求。
请参阅：Micropackages and Open Source Trust Scaling
优雅降级
我们不希望我们的 SDK 成为造成客户损失的原因。如果我们的 SDK 破坏了客户，那么即使客户在一个过时的平台上运行我们的 SDK，我们也失败了。这意味着，如果我们的 SDK 运行在一个过时的浏览器上，我们必须有足够的弹性，优雅地退回到不做任何事情的状态。
如果不能做到这一点，我们需要确保通过在安装时警告此类情况提前通知用户。例如，如果一个 SDK 甚至需要一个最小版本来构建，我们需要确保通知用户，并且我们以后不会造成令人困惑的错误。
兼容性为王
即使一个平台正在失去相关性，我们仍然想要支持它。我们没有责任告诉用户他们运行在过时的平台上，他们很可能知道这一点。我们不能为客户平台设定基准。如果客户需要支持一个旧的浏览器，我们至少不能破坏那个浏览器，我们还应该重新考虑是否支持它。老平台对于企业客户来说尤其重要，因为企业客户更有可能需要支持这些老平台。
客户价值问题
每个更改都有代价，应该避免为更改而更改。如果更改对客户有利，那就很好，如果更改只是实现了它自己的目的，那就增加了我们破坏现有代码或引起用户失望的机会。没有什么比客户发现自己的报告因为无意义的重构而降级更糟糕的了。
配置是有代价的
我们会优化以提供出色的开箱即用体验。定制（Customization）应该就是：定制（customization）。默认物质（Defaults matter）和这些默认值应该是明智的。如果集成可以执行，则集成应该自动激活，因为未启用每个集成只会导致更糟的客户体验。
优先考虑客户便利性而不是正确性
如果能带来更好的客户体验，做一些稍微不正确的事情是可以的。如果我们的 SDK 能够增加对更多平台的支持，那么发行过时的代码也是可以的。如果能带来更好的客户体验，那么我们的 SDK 做“不应该做的事情（things that should not be done）”是明智的。例如，我们更喜欢 monkeypatch 而不是手动配置，即使这些 monkeypatch 在其实现中可能是脆弱的。
假设新手开发人员
文档、指南和营销材料都应该以不熟悉该语言的开发新手为前提。不要仅仅为了简短的例子而使用可能不熟悉的语言特性。
写下规则
如果做出了违反或澄清本文件的决定，就应该把它们写下来。SDK 是否划定了一个平台的支持范围？应该有一个文档来概括支持什么。当对旧平台的支持被放弃时，就会出现这种情况。
在任何情况下，客户都不应该升级库而发现自己的栈不再被支持，他们只能通过编写客户支持来了解这一点。
启用 Customers
虽然我们通常应该尽量减少 SDK 的 API 范围。同时，我们还需要确保使客户能够实现他们的目标。考虑一下 SDK 可能无法立即解决的情况。如果有足够的 API 可供客户以更具创造力的方式使用我们的 SDK，我们通常会认为这是额外的好处。
