# SDK 开发总结
sdk 通常是封装业务中常用的能力，方便在业务开发中快速使用，比如说登录、权限管理、请求等。
sdk 的开发，包含以下几个方面：
- 需求分析
- 功能开发
- 单元测试
- 构建发布
- 文档编写
- 技术支持
# 需求分析
明确这个 sdk 要解决的问题是什么。边界在哪里。sdk 应该是职责明确的，而不是将功能都堆积在里面。
# 功能开发
在明确需求后，进行功能开发，需要注意的是，在 api 设计中，遵循开闭原则，保持良好的扩展性，使用户能够根据 sdk 提供的能力再扩展，最终满足不同业务的定制化需求。
这个扩展性，可以通过插件机制来支撑。sdk 只能提供常规的能力，不应该做得大而全。对于一些特殊场景的特殊需求，应该由 sdk 提供基础能力，业务方利用基础能力再扩展、定制。
功能开发过程中，还要明确兼容性，对于有兼容性要求而存在兼容性问题的，需要做特殊处理。常见的有 IE9 下的各种 api 不兼容问题，比如 XMLHttpRequest 不支持 CORS，需要使用 XDomainRequest 来做兼容。
# 单元测试
功能开发完成后，编写单元测试，对每个功能进行测试，单元测试应该覆盖大部分代码分支，使用场景，同时注意边界问题。
# 构建发布
构建之前进行完整的单元测试，单元测试不通过不允许构建。
构建一般选用 gulp + rollup，配合 babel 或 typescript 。
打包器选用 rollup 而不是 webpack。webpack 的优势在于打包不同类型的资源，包括 js、css、html 等，更适用于应用的打包。rollup 是一个 javascript 模块打包器，可以将小块代码编译成大块复杂的代码，例如 library 或应用程序。天然支持 es6 和 tree-shaking，更适用于 library 打包。而且 webpack 会生成运行时代码，增加包体积。
一般 sdk 的构建产物有三个：cjs、esm、umd。对应不同的模块规范，
在 package.json 中将 main 指向 cjs 所在目录；将 module 指向 esm 所在目录，配合 webpack 可以进行 tree shaking 优化；umd 文件用于供业务方直接以 url 的方式引入。
# 文档编写
良好的文档，对于 sdk 的开发者和使用者都能带来极高的收益。使用者可以用更小的学习成本使用，开发者可以减小不必要的客服时间。
文档一般包含以下几个部分：
- 概述，简单介绍 sdk，一般包括这个 sdk 提供了什么能力？为什么要做这个 sdk。
- 快速上手，sdk 的极简使用方式。
- API 文档，详细全面的 sdk api 说明。
- 常见问题，记录使用中常见的问题，避免其他使用者重复踩坑。
- CHANGELOG，更新日志，便于使用者查阅遇到的问题新版本是否已经解决，或者是不是新版本的修改导致了现有代码上的 bug。
# 技术支持
sdk 对外发布后，后续维护相当大一部分的精力主要花在对外答疑上。基本上使用者遇到的问题都是以下几类：
- 不知道是否有提供某个功能
- 使用方式错误
- 业务代码有问题，导致执行结果与预期不符，实际与 sdk 无关
- sdk 本身存在 bug
其中第一、第二、第四点，作为 sdk 的开发者，一般情况下能够比较容易地判断出来。对于第一、第二点，主要的应对措施是完善、细化文档。随着文档完善及使用熟练度上升，比较会逐渐下降。对于第四点，需要注意的是修改后发布的版本要遵循 semver 语义化版本规范。
对于第三点，一般是提供一个简单的工程给业务方，要求业务方在上面将复杂的业务代码剥离后复现，如果复现不了，大概率问题原因不在 sdk，这时候可以要求业务方检查自己的代码。但有时候业务方检查后还是发现不了问题，又把问题甩了回来，这个时候只能拿他的工程项目看内部代码。
大部分问题通过调试可以解决，比较极端的是业务方对 sdk 做了两次扩展，扩展 A 以比较常规的代码实现，扩展 B放在其他隐蔽的地方实现，比如以一个 cdn 上 js 文件的方式引入做扩展，重复操作导致出现 bug。
# 参考
← 通用后台管理系统开发 介绍 →