写点什么

SDK 开发质量保障经验总结

用户头像
张明云
关注
发布于: 2020 年 12 月 10 日
SDK开发质量保障经验总结

相比于APP的开发,SDK的开发有些不同:

  1. 拓展性要求更高:SDK需要对外提供接口,无论是迭代还是重构,原有接口都不能变更,否则会对SDK使用者带来兼容、维护成本;

  2. 质量要求更高:SDK可能在各种业务场景中使用,使用情况复杂;且如果有质量问题时每个SDK使用方都需要升级,所以发布的SDK版本一定要是高质量的版本;

  3. 测试难度更大:SDK很多时候只有接口没有界面,对于测试来讲既是黑盒、又不确定SDK使用者怎么调用,即使测试时没问题也很难保证在业务中使用时没有问题。

 

        对于1已有成熟的解决方案,有新需求或需求变动,新增接口并让原接口过时即可。下面结合我实际负责SDK开发的经历,谈一谈2和3,即如何保障SDK的开发质量:

一、评审环节:

        评审环节最为重要的是在满足当前需求之外,还要基于对业务的理解,洞察可能的潜在需求,基于对需求的理解和洞察,设计接口和。尽可能在SDK设计时就考虑到需求可能的变更情况,设计出职责明确、兼容性强的接口,避免因为需求变更导致接口的改动。比如下载接口的设计,一次可以添加一个下载任务,也可能有一次性添加多个下载任务的需求。

        除此之外,还需要为SDK制定版本号(在代码中写明版本,而非在SDK名字上体现)和一套错误码,便于在SDK出问题时能够快速定位问题。

        SDK设计完成后,需要要求APP需求方的开发人员一起参与评审,主要评审接口设计的合理性和易用性,确保达成一致后才进入开发环节。

 

二、开发环节:

         因为SDK的特殊性,质量保障不能强依赖测试,既然SDK不好测,那就想办法让开发出来的SDK质量有保障、通过开发端提供测试工具简化测试的工作。

         靠谱的解决方案是为SDK开发Demo,Demo中演示每个接口的调用方式,并提供测试模式,用于对接口的性能、安全性等测试。通过Demo既引导了APP开发人员尽可能按预期的方式使用接口,又为测试人员提供了方便,通过测试模式可以对各接口做性能、安全等专项,专项验证SDK的质量。如果SDK存在需要长时间运行等可能导致功耗问题的情况,需要通过多渠道打包生成多个Demo,通过专项验证同时运行对整机性能的影响。

         为了便于开发者使用,为SDK写ReadMe,介绍接口的使用方法、使用流程是必不可少的。

 

三、发布环节:

         SDK的发布可以借鉴APP的发布流程,先和需求方拿一个APP联调,集成进APP灰度验证SDK的质量,如果质量OK再全量。

 

四、维护环节:

         为SDK设计一套单独的异常采集方案,将SDK和APP的异常分开,避免因为SDK集成到APP中无法单独统计SDK的异常率,通过统计SDK的异常率来衡量SDK的质量。

 

        刚开始接手SDK开发时情况是比较糟糕的,发布SDK版本时总是心惊胆战,市场反馈有APP的问题时,经常听到APP开发人员反馈这是SDK的问题。通过将上面的做法融入到流程和规范中,并不定期抽查团队成员对流程和规范的遵守情况约束团队遵守规范。现在几乎很难遇到之前那样的情况了,一年下来因为SDK导致的严重问题最多有1-2次,SDK的异常率远低于APP的异常率。

        上述的总结只讲了在开发过程中有真正实践过的方法,并非完美方案,像通过单元测试保障SDK接口的稳定性、通过热更新实现SDK补丁的动态更新都是有效保障SDK开发质量的方法。



下面是对这篇文章的总结:

  1. SDK相比于APP,需要更为注重开发质量;

  2. 保障SDK开发质量的方法有:为SDK开发测试模式、输出SDK使用Demo和说明文档、对SDK做专项测试、先灰度再全量、对SDK做异常采集;

  3. SDK的开发,永远是质量第一、效率第二。严格遵守流程和规范,只有这样,才不会陷入被使用方质疑的境况,才有机会始终以实现新增需求而非维护为主。



发布于: 2020 年 12 月 10 日阅读数: 24
用户头像

张明云

关注

纸上得来终觉浅,绝知此事要躬行。 2017.10.21 加入

先后做过miniGUI、Android应用、Android SDK开发,以及移动端技术方案设计及落地的工作。 先后负责过Android应用、移动中台、架构设计及落地和移动游戏开发的工作。

评论

发布
暂无评论
SDK开发质量保障经验总结