SDK之我理解的SDK

这是SDK系列的倒数第二篇,其实应该是第一篇来着。最近发现写了两个月还没写完,进度有点慢,这几天抓紧时间写完。不过随即发现当时完全没想错,这部分还是最难写。先写一个成稿,后续想到更多的内容逐步补充和更新吧。

什么是SDK

SDK即软件开发工具包(外语首字母缩写:SDK、外语全称:Software Development Kit)一般都是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。

​上面这是百度百科对SDK的定义。但是现实中我们开发的SDK更多的是Second Development Kit,我认为这类SDK其实就是把每个应用接入相同功能都要做一遍的工作抽离出来,然后提供给别人使用的公共组件。他最大的价值都是代码复用和降低工作的复杂度、理解成本。

为什么要做SDK

  1. 批量开发 原谅我用一个这么low的词。如果没有批量开发,就不会有大量的重复性的工作。就是因为批量开发一批类似的东西,所以才会有相同的功能要重复开发。
  • 程序猿懒 首先,这里的懒不是贬义词哈。换我也是一样,开发中如果遇到以前开发过并且一样的功能,我也不会傻傻的再去研究一边,再去分析一遍,效率太低了,肯定是用现成的。这里某种程度上也不是因为懒,是为了提高效率。
  • 代码复用 既然已经有成熟的方案,为什么还要重复的造轮子。尤其是有些轮子早起来还没那么容易。代码复用这是软件开发和设计中一个很重要的原则。尤其是像SDK这种很多地方都是完全一致的逻辑。
  • 提高效率 通过SDK的各种封装,可以有效的屏蔽第三方或者具体的功能实现,降低开发者对功能理解的成本,提高接入效率。

上面的四个原因是个人总结的比较重要的原因吧,当上面的几个或者条件具备了,一般开发者或者团队就会不自觉的把一些公共的模块慢慢抽离出来,时间久了,就变成了SDK。来源于开发并最终服务于开发。

SDK的一些特性

SDK跟一般的程序或者软件相比,还是有一些不同点,个人总结了几个开发过程中体会比较深刻的:

  • 使用对象:开发者,程序员。这是一群充满奇特思想,充满创造力的人群,你永远不知道他们怎么用你提供的sdk。
  • 使用时间:一旦发布,只要在这个发布包里,任何东西都会影响到别人。而且鬼知道什么人会在什么时候用,你至少要维护比较长的时间。
  • 发布节奏:虽然现在提倡敏捷开发,但是版本迭代的节奏还是不要太快。让开发者升级SDK是一件很痛苦的事,虽然很多时候成本并不高。

SDK应该有哪些内容

文档

这里的文档包括商业接入流程、接入指引、架构介绍、更新方法、API说明、测试报告、常见问题、版本历史、接入验证方法或验证工具等。这些,具体的可以参考之前专门写的文章:SDK开发经验之文档,这里会有很具体详细的说明。

api

SDK的核心内容,提供给开发者的API包。

Demo

关于Demo我也专门有写文档来说明。仅仅通过他人的口述、视频、文档往往无法完整的了解到SDK的接口的所有的作用,好比盲人摸象,你对它的认知、印象、经验将完完全全从他人所提供的教程中继承而来。而Demo能够全面地介绍出它所包含的所有内容,能够辅助你学习如何“使用”它。具体的关于Demo可以参考之前的文档:SDK开发经验之Demo

版本

任何SDK都是一个持续的存在,是一个接一个的迭代的,因此从一开始就应该有版本来对每个对外发布的内容作标示。还别不信,现实开发中还真的有遇到没有版本概念的SDK,当时的震惊无法用语言形容啊。关于版本之前也专门写文档说过,具体的可以参考:SDK开发经验之版本SDK设计心得之版本号。里面对于版本和版本号都有比较深入的分析。

公告

SDK的开发者和使用者之间的信息其实是不对称的,开发者无法得到使用者关于使用方法的反馈。使用者无法及时知道SDK的变化,包括文档、版本等。如果SDK自身有一套面向开发者的公告系统。例如邮箱(其实不是好办法)、微信公共号、wiki上的公告等可以及时告知开发者版本发布、最新bug、通用问题解决方案等问题,都是一种很不错的选择。

沙箱

当然如果只有客户端的话,其实沙箱的存在没那么重要,如果有后台的话沙箱就很重要了。可以方便开发者模拟请求,验证参数等。

技术支持

技术支持主要用于接入的联调。有时候开发者会遇到一些无法通过文档、demo等解决的问题,技术支持将是一条很有效的方式,一般通过QQ群、企业QQ等对接会比较好。但是切记,如果文档、demo、公告等这些基础设备都不完善的话,技术支持的人迎来的只有噩梦。

监控、告警

监控和告警主要是为SDK开发者自身服务的,一方面通过监控和告警可以了解游戏的版本、接口调用量、接口失败率等数据,另一方面可以尽早的发现问题,比业务更快的响应。想想你通过监控了解到开发者的版本存在什么问题,然后在他还没有发现问题的时候就找到他告诉他你哪里有问题,要怎么改,他将是一种怎样的赶脚也表情。

数据视图

这部分其实偏向于数据分析了,主要两个功能吧,一个是做大数据,做进一步的数据分析和挖掘。另一个就是做SDK的品牌数据,逢人就吹你怎么怎么牛逼,怎么吹,就靠这个。

SDK开发遇到的一些问题

关于SDK开发中遇到的问题,说实话实在太多了,多的无法说完!!!!所以最终下定决心汇总这整整一个系列来总结。这里就对一些共性的说明一下:

  1. SDK的开发者和使用者之间的信息同步和沟通。 这是我认为开发过程中遇到比较多的问题,我们经常做一个东西有多个方案,但是不知道那种方法对使用者更方便,结果经常用了我们并不方便不过以为使用者很方便但是最后证明对他们反而更麻烦的方案。建立开发者和使用者之间的沟通机制真的很有必要。
  • SDK使用者之间的相互交流 SDK的开发者更多的关注于SDK的开发,使用者更多的关注于SDK的使用。尤其是对于游戏开发,使用相同的引擎的游戏开发肯定比SDK的开发更了解一些开发中的问题怎么解决。很多时候联调中会遇到有些之前已经有游戏开发者遇到并且已经解决的问题,又有开发者来问,但是我们因为可能涉及游戏引擎等我们并不熟悉的问题解决会比较吃力。如果开发者之间可以交流就可以很简单的解决这个问题。 当时初衷想建立一个开发者的社区,后来考虑到别最后变成猎头的天堂而引来合作伙伴的不满而最终没有实现。说实话如果有个社区,会好很多。不管是开发者之间还是SDK的开发和使用者之间的交流都会很顺畅。
  • 不用数据说话,拍脑袋订标准。 这个是属于内部问题了。经常增加功能或者添加一些限制条件的时候大家不是根据数据统计去分析一个合理的值,而是直接根据自己的经验拍脑袋订一个。说实话个人觉得虽然我们也是用户,但是我们和真正的用户的差距还是挺大的,通过拍脑袋订的很多方案或者数据并不一定合适。 开发中完全可以先发一个版本出去,增加一个数据上报点,收集一些数据回来通过数据分析给出一个合理的,有意义的参考值。这个过程的工作量不会大很多,但是会科学很多。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏新智元

【干货】谷歌软件工程技术实践总结:软件开发、管理和人员调配(20PDF)

【新智元导读】作者 Fergus Henderson已在Google工作了10年以上,拥有超过15年的商业类软件的行业经验。本文梳理并介绍了Google 软件开...

59270
来自专栏Java学习网

程序员需谨记的8条团队开发原则

  当你从学校出来,找到第一份软件开发工作的时候,你就不再是一个单独作战的程序员了,你将会有一个团队,你的一举一动也将直接影响团队的效率和产出。下面这8条团队开...

35650
来自专栏云计算D1net

如何保护混合云安全:IT专家需要知道的内容

15770
来自专栏携程技术中心

干货 | 携程运维工作流平台的演进之路

作者简介 徐豪杰,携程旅行网技术保障中心流程工具团队资深软件工程师,于2013年加入携程,主要负责携程工作流平台架构设计与建设,在流程建设方面有着比较丰富的积累...

68190
来自专栏ThoughtWorks

致测试同仁们:让我们做安全测试吧!|洞见

本文首发于InfoQ: http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safe...

38140
来自专栏BestSDK

智能存储能够聪明到什么地步?

今天的存储可能天生就知道哪个应用程序在创建、拥有和访问存储数据的每个数据块;这些数据需要什么级别的安全和保护;应如何实现应用程序I/O性能(通过缓存、分层规划等...

47830
来自专栏云计算D1net

如何集成云层与本地存储

云和本地存储正走向越来越紧密的整合,于是云成为了另一个存储管理员可用的层级。 ? 组织不大可能把100%的数据都移到云服务上,但大多数企业都会至少想让一部分数据...

32360
来自专栏SDNLAB

JUNOS DEVOPS尤便捷 更精彩

一、 新一轮IT变革来临(DEVOPS) 如今IT发展风起云涌如火如荼,各领域技术百花齐放,各山头厂商占地为王。纵观整个IT江湖,虽拥有众多的昙花一现和太多的不...

34980
来自专栏大数据文摘

超贴心 :一份简单明了的营销分析软件包测评

22150
来自专栏腾讯高校合作

小程序这13大新能力,将对你产生什么影响?

微信公开课“小程序专场”,微信团队带来两项全新能力——“第三方服务”和“附近的小程序”。 至此,小程序近期一共开放了13项新能力。对于用户来讲,会带来哪些影响呢...

34560

扫码关注云+社区

领取腾讯云代金券