背景
在互联网+时代，越来越多的程序员投身于互联网行业，成为茫茫RD大军中的一员。由于公司自然具有的盈利性质，注定了大多数RD需要专注于业务开发，尤其是在入行前几年，需要完成大量架构上相对重复、设计思路相似的业务逻辑开发。而这些现实都与程序员热爱新技术，要求快速成长的诉求有一定的冲突。如何将两者结合实现双赢？本文旨在通过阐述link card快速接入工具从产生、设计到落地的整体思路，为上述问题提供一种可能有效的解法。
参考资料
正文
什么是link card？
引用微博开放平台的介绍：link card是用户链接接入到微博兴趣图谱所获得的与微博消息流深入连接的能力特性。pc端feed对接入兴趣图谱的url具体展现样式如下图所示：
link card 快速接入工具
1. 发现问题
在业务开发中，由于同一链接，需要在移动端、pc端的feed以及私信流同时生效。为简化业务方工作，整个link card服务由平台统一对接。遗憾的是由于历史原因当前的对接方法为邮件手动申请权限，会在沟通层面浪费大量时间。对半年内涉及到该服务的4个业务线的5位RD童鞋进行数据收集，如下表：
痛点统计
| hurt point | Data |
|---|---|
| 接入流程烦琐，沟通成本高 | 沟通时间跨度 > 3day |
| 调试成本高 | 联调时间跨度 > 5day |
| 重复造轮子 | 重复开发时间75% |
| 公司资源浪费 | 重复申请资源 |
可以很明显的看出，接入link card服务已经成为影响开发效率的一个亟待解决的问题。与上游沟通确定，短期内无相关流程的改进计划。作为下游业务方，提出自动化快速接入，多业务资源共享的解决方案。对工具效果进行“大胆假设”：
痛点fix设想
| hurt point | Data | target Data |
|---|---|---|
| 接入流程烦琐，沟通成本高 | 沟通时间跨度>3day | 沟通时间跨度0 |
| 调试成本高 | 联调时间跨度>5day | 联调时间跨度0 |
| 重复造轮子 | 重复开发时间75% | 开发时间0 |
| 公司资源浪费 | 重复申请资源 | 资源1份 |
最理想的情况是将所有痛点都能完全fix掉～
2. 分析问题
目标已定，剩余“小心求证”过程。通过与平台以及双端同学沟通，对当前link card接入流程进行整理，简单的数据流图如下所示：
红色方框部分是涉及业务方开发的部分，可见不同业务线会重复进行同种工作。总结之前开发经验可知，80%需求集中在2、3种特定的特型解析上。因此快速接入服务的核心思想为多业务线重用同一特型。通过实现可靠、业务间隔离的解析分发功能，保证业务方只提供接入兴趣图谱的url、解析特型种类以及展示数据即可完成接入；同时增加移动端公共接口，实现数据驱动的自动解析，保证输出可定制。升级后的接入流程如下图：
其中红色方框为业务方开发部分，而橙色区域为添加的快速接入服务部分，利用分发机制使整体link card接入过程对业务方透明，只提供原始数据，无需理清复杂的依赖关系，保证快速接入。
3. 解决问题
分别对服务的两个模块进行分析，主要特点为：
- 以展示特型为纬度，多业务线复用资源；
- 提供沙箱机制，保证业务之间数据无污染。
基于流程设计，落地的实现方案及其优劣主要有以下三者：
备选方案
| 备选方案 | 优点 | 缺点 |
|---|---|---|
| 静态工作类 | 方便使用，易于推广，性能好 | 与线上代码耦合度高，不利于进一步优化 |
| 内部服务 | 业务与服务逻辑解耦，利于服务升级 | 接口方式学习成本高，不易推广 |
| 工具类与服务结合 | 具有前两者优点 | 开发成本高 |
结合实际业务需求，前期收集用户需求确定产品形态，后期具备广泛推广能力。为保证技术产品的健康成长，采用渐进式方案：
step1=>operation: 静态工具类
step2=>operation: 工具类+服务
step1->step2
在最新业务中落地，业务方对比预期效果如下表：
实际效果统计
| hurt point | Data | target Data | real Data |
|---|---|---|---|
| 接入流程烦琐，沟通成本高 | 沟通时间跨度>3day | 沟通时间跨度0 | 沟通时间跨度0 |
| 调试成本高 | 联调时间跨度>5day | 联调时间跨度0 | 联调时间跨度0 |
| 重复造轮子 | 重复开发时间75% | 开发时间0 | 开发时间10min |
| 公司资源浪费 | 重复申请资源 | 资源1份 | 资源数＝特型数 |
从统计结果可以分析出，快速接入工具完成了解决了实际业务中影响进度的主要矛盾，同时对次要矛盾也有一定程度的解决，完全符合预期。
思考
从业务出发提炼服务，有助于保证对产品需求的快速支持，并且可以充分锻炼、提升自我，实现了一举两得。个人愚见，这种提炼的习惯除了对业务的深刻理解以及自我成长的热情外，还需要培养好的习惯。其一是对具体问题解决方案的抽象：前期深入理解->中期多方求证->后期数据反馈；另一是程序猿/媛自我修养的习惯：从体力劳动到脑力->从手动肉扛到自动化。相信每一个对未来充满希望的RD都有自我提升的小心得，业务从来不会阻碍成长，相信保持开放的心态，多做尝试肯定可以收获更多，与君共勉～