在张爱玲的小说笔记中，我摘录过这么一句话：
你如果认识从前的我，也许你会原谅现在的我。

之所以将其摘录，是觉得这句话怎么看都很有道理，时间在变，人无时无刻也不在变，似乎充满了无尽的正能量。

的确，时间可以抹去多数的恨与悲，时间可以记录许多的爱与欢，可唯独那些惨杂着爱恨悲欢的事件，不但无法抹去，而且铭记在心。

在我的从业生涯中，够资格的，应该要属围绕SDK所发生的那点事了。

这里说的SDK是什么？

所谓SDK，全称为 (Software Development Kit) ，中文叫 “软体开发工具组”，是用来帮一个产品或平台开发应用程式的工具组，由服务开发者提供给接入开发者使用的的工具包。

说白了，就是一个用于连接服务端的公共组件工具箱。

自古道 “手巧不如家什妙”，好工具不仅能够提高开发效率，避免重复开发，而且还能降低BUG率，便于升级与维护；

可自古又道 “拙匠常怨工具差”，当出现问题或异常时，把工具当成头号嫌疑犯，这也是常有的事。

爱与欢：SDK是最人性化的设计

今年年初，为了提供更好的基础服务体验，基于松耦合、快速迭代的产品理念，在分布式缓存的第三代设计上，我们果断放弃了第二代所采用的OpenAPI模式，而尝试SDK模式，结果受到应用研发各团队的一致好评。

从产品收益者的角度来看，SDK给接入者带来的收益是：

进一步拓展传统的统一通信和控制台边界，方便开发者、链路跟踪及日志分析等功能紧密整合到一起，从而创建独一无二的管理者体验；

通过API封装通信功能，降低开发者对通信技术和协议的门槛，直接调用通信能力内嵌于应用之中；

利用SDK实现负载均衡策略，支持热加载，与平滑过渡、扩容伸缩；

这些收益确实实在在的落在了掌心，为用户带来了多、快、好、省的利益，得到赞美与夸奖也是理所当然的。

就在上线的第二周，为了这样表彰大家的辛劳，推杯换盏在所难免，在宴席上，某同学借着酒劲说了一句 “SDK应该说是最人性化的设计啦”

的确，无论服务方还是接入方，此时此刻充满脑海的，除了爱，更多的是欢……

恨与悲：异常都是SDK惹的祸？

几个月前，在某次缓存超时告警事件中，原本沾沾自喜的SDK模式，却被推到了风口浪尖：

SDK交付前测过吗？测过？没问题？那为什么我们一用上就有异常？

我们FullGC那么高，是不是你们SDK导致的？

负载均衡算法是不是有问题？你们是怎么实现的？干嘛之前不告诉我们？

连珠炮般的问题，有时让人难以招架，不过又由于缺乏数据留痕、监控评测、日志分析等手段而难以给出具有说服力的回应，所以唯一能做的就是当出现问题时，用主动积极的态度、人肉化的手段，勉强应对进行处理。

在大智慧工作期间，类似的场景我也遇见过多次，一般任何以SDK模式提供接入的平台或产品，当应用本身出现异常或故障时，SDK都会被优先贴上疑犯的标签，随后被拖到死角打个半死，甚至屈打成招（无法提供有效证明）的案例不在少数。

不可否认的是，SDK的场景模拟测试至关重要，但令人愤恨的是，要想持续开展却非常困难：

与应用接入方的版本迭代周期不一致，无法及时获得测试环境；

与应用接入方的目标不一致，很难在应用测试周期中增加SDK的测试用例；

为了测试SDK而特地搭建应用模拟环境，无论从成本，还是收益角度出发都不合适；

的确，无论什么理由，作为SDK提供者，当使用者出现问题与异常时，都应毫无理由的给予积极协助，但却隐含着一种恨与悲……

可能大家会问……

出现这种情况，基本都属于监控没做到位，如果做到位肯定一眼就能发现
好一个 “如果做到位”，作为一家快速发展的互联网企业，除了某某某公司之外，又有谁家的监控不是 “一步一踩屎” 爬过来的？在设计当初就能 “掐指一算” 考虑得面面俱到？

也许有人会说，既然这样，干脆把SDK移交给应用研发团队自己去维护不就行了
您说的没错，上文提到的这些点，或许可以得到改善，但任何一种选择都会有利与弊之分。

比如SDK中通常会包含通用算法、公共方法等较为共享的内容，如果移交，那该有哪个团队接手呢？如果各自维护，那原本基于SDK获得的收益又将不复存在，并进入之前的恶心循环了吗？

对于我来说，能做的只是在企业与团队的发展过程中不断的去寻找平衡。或许这种平衡，无论时间多久，也永远，永远，无法找到……

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/g7mlGxTlCqsDnl6Am1G1lg