关于设计 sdk 的一点思考

我最近在做 sdk 的时候，一些设计上的决策都与高T 不同，这让我开始反思我设计上的思路出在哪里。

sdk 这个业务的侧重点与工具的需求完全不同。需求一般都很简单，难点在于接口（API）设计，因为接口需要对外，而且一但确定，变更成本会很高。我对于接口设计的理解主要是：

• 易于理解，用户好上手。
• 用法保持一致，便于用户推测行为

但牢记这几点准则，我的判断最近也总翻车，我痛定思痛想了想，我犯的思维上的可改进的有两点：

• 易于使用 > 易于理解。”易于理解“ 更多是从代码可读性的角度去想，但有时会忽略业务本身。应当转换思维，充分了解业务后，选择更加易于使用的形式。当然，对于如何“易于使用”，也需要在实战中增加经验，我暂时总结出以下几点：
  • 增加 option 参数的成本 < 增加新接口的成本
  • 平衡灵活性和实现成本。尽可能提供更灵活的配置。
• 无论哪一种方案，都需要考虑全面。
  • 设计应该能够覆盖各种场景，正确性大于一切。

总结来说，在我心里考虑设计方案的优先级需要调整一下。业务 > 代码正确性 > 代码质量。永远优先理解业务，保证设计符合业务需求。之后考虑所有可能场景，保证在当前架构可行。最后考虑代码怎么摆放比较舒适。

最后！我发现另一件事，就是复盘这个习惯，如果你的复盘结论是错的，那就适得其反了。我也没有很好的办法避免这种情况，所以只能在每次复盘的时候，别抓住表象！