还可以让用户自己来控制解析的方式：
// 自定义解析器interface MyParser extends Parser {// 需要用户自己实现void doParse();}// 指定解析器date = DateUtils.parse('2021-01-18', MyParser.class);这两种方式在 SDK 的设计中屡见不鲜 ， 此外还可以让用户自行编写或指定配置文件 ， 也能提高灵活性 。
高效稳定其实 ， 开发 SDK ， 尤其是在大厂开发 SDK ， 是个很 “坑” 的工作 ， 我相信做过的朋友会感同身受 。
因为随着使用你 SDK 的用户越来越多 ， 可能会发现各种各样莫名其妙的问题；而且 SDK 作为相对底层的依赖 ， 对使用方的影响也是无法估量的 。所以 ， 不想经常加班改 Bug 的话 ， 就要保证你 SDK 的稳定性 。
我们需要注意以下几点：
1. 测试为了保证每个功能都是正常的 ， 我们可以编写 单元测试（UT）来最大程度上地覆盖 SDK 的功能和代码 。
尤其是每次改动代码后、发布新版本之前 ， 都要再完整地执行一遍测试 ， 不要盲目自信 。
文章插图
接口测试报告
此外 ， 还可以通过 压力测试 来估算 SDK 的执行效率 ， 比如每秒最多同时执行 3 次、每次要执行 500 毫秒等 。建议将这些信息补充到说明文档中 ， 给用户一些预期 。当然也可以尝试通过压测来优化 SDK 的性能 。
2. 兼容性重要的函数和接口尽量减少改动 ， 尤其是函数名、入参和返回值！
举个例子 ， SDK 0.1 版本时 ， 函数的定义是这样的：
boolean isValid(String str)结果突然在 0.2 版本时改成了：String checkValid(StringBuilder str)这样就会导致用户升级时一脸懵逼 ， 怎么报了一堆找不到函数呢？因此 ， 对于比较大的改动 ， 可以新写一个函数 ， 并且给老函数打上类似 @Deprecated 的注释 ， 表示已过时 ， 引导用户去用新的 。
此外 ， 还可以在 版本号 上做做文章 ， 小改动时只改变小版本号 ， 比如 0.0.1 到 0.0.2；大改动时才改变大版本号 ， 比如 1.0 到 2.0 。这样可以给用户一个预期：这次改动很大 ， 可能会存在不兼容 。
3. 暴露异常要让用户感知到 SDK 代码中可能抛出的异常 ， 交给他们去进行相应的处理 ， 防止出现一些意料之外的错误 。
此外 ， SDK 要合理地打印日志 ， 尤其是异常日志 ， 在出了问题时要让调用者知道是出了什么问题 ， 便于排查 。
推荐阅读
- ntopng 的安装源码安装，一个非常棒的流量监控工具
- 忍冬书评,盘叶忍冬的主要用途
- 轻松搞定Excel气泡图制作
- 桑葚干能提高性功能吗,用桑葚干泡的水能天天喝吗喝桑葚干泡的水对身体有哪些好处
- 干槐花包饺子做法大全,槐花饺子的做法
- 金银花泡水喝的作用与功效,金银花泡水喝的功效和作用
- 禹州药材批发价格表,禹州药交会的特点
- 程序员的阴暗面
- 治疗肾病最好方法,鼻窦炎的最好治疗方法
- 石斛枸杞泡水喝的功效,石斛花泡水喝的功效及药用价值