sdk 的作用是把一些功能封装起来，提供给别的开发者使用，如何才能编写一个好的sdk呢
首先，谁最有权力来判断我的sdk好不好呢？产品经理吗？领导吗？当然是我们的用户。
我们不妨以用户使用sdk的全流程来思考一下，好的sdk有怎样的特征
怎么做一个好的sdk
- 让用户选择
- 宣传已经接入的知名业务
- 强调团队已经产出的优秀产品
- 到内部论坛、外部宣传
- 让用户了解
- 编写更好的文档
- 提供playground
- 让用户更好的接入
- 让用户用的更好
- 让用户更好的解决问题
- 让用户更好的维护、升级
容易接入的sdk
- 优雅的代码
- 使用typescript或jsdoc来优化代码提醒
- 完善代码注释
- 良好的分类和代码组织
- 有规律，良好的命名
- 提供demo
- 可下载可运行
- 可在页面调试运行
- 减少用户心智负担
- 尽量减少需要的参数，提供默认参数
- 允许集中配置
- 屏蔽用户不需要操心的细节
好的sdk代码
- 完成应该做的工作
- 提供一定的自由度
- 控制体积
- 最好允许选择，组合功能来生成sdk包
- 支持按需，分平台引入
- 第三方依赖较少
- 最小可用原则
- 扩展性
- 支持用户自己编写插件
- 可维护性
- 系统拆分为独立模块，降低维护复杂度
- 兼容性、稳定性
- 尽可能覆盖多的平台/系统
- 跨端跨平台一致
- 新版本的sdk与旧版本的兼容
- 新老接口
- 新功能
- 稳定运行，不影响宿主
- 高效
- 高效率完成任务
- 低内存占用
解决问题
错误处理
- 分类分级别
在线答疑
- 机器人自动答复
- 研发同学值班
运维及升级处理
- 如何版本处理
- 向前兼容
- 如何避免没有权限的人使用
- 后端校验
- 数字签名
- 收集数据
- 使用者情况
附录
solid原则
- 单一职责：一个接口负责一个功能
- 开闭原则：对扩展开放，对修改关闭。添加功能时加代码而不是改代码
- 里氏替换：父类可以用子类替换
- 接口隔离：不同功能的模块用不同的接口
- 依赖倒置：高层模块不以来低层模块
