Skip to content

做通用服务的一些感悟

转载: https://neveryu.github.io/2022/thoughts-1/

作者: neveryu

生成人像摄影图片.webp

总结

入职滴滴一年, 造了不少公司级别的“轮子”, 不少轮子已经在业务线跑起来了, 运行状况还算可以. 我自己也总结了做通用服务要注意的几点:

1.一定要好用, 用起来要简单.

这是我一直贯彻的理念, 如果你写的通用服务不好用, 那一定会受到质疑和吐槽. 同样我们用开源的框架, 也一定会选简单好用的,

当年 jQuery, prototype, tangram 等 JS 库百家争鸣的时候, jQuery笑到了最后, 为什么呢?

很简单的一点 jQuery好用啊, 一个 $(xxx) 搞定一切. 相比 tangram 那种 Baidu.T.createDom() 的方式, 高下立判.

我们在设计通用 JS 库的时候, 一定要站在更高的角度去对需求做抽象.

比如我在设计统一登录 SDK, 首先要想的不是复杂的交互逻辑、如何去实现、有哪些技术难点, **而是去想, 别人怎么用这个库, 怎么用起来爽. **

登录的需求就是用户触发一个登录动作, 登录完成能拿到用户一些信息, 所以我就设计一个 login(callback)接口,

那么使用方只需要简单调用这个方法, 就可以完成登录需求, 而不用去关心登录各种复杂的细节.

2.该做封装的地方要封装, 对外暴露的接口越少越好.

封装很重要, 举个通俗的例子, 有一天我去洗手, 发现水龙头的开关把手没了, 把原始的开关暴露给我了,

也能用, 但是体验就会很不好. 水龙头的开关把手就是对原始开关的封装.

我在做 JSBridge 库 的时候, 也是一样的道理, 如果让用户直接调用 IOS 和 Andrid 提供的原生 bridge 接口的, 也能 work,

但是非常难用, 需要判断 IOS 和 Android 接口的差异, 还需要考虑 bridge ready 事件后才能执行方法等, 这些都是我原本不需要关心的细节.

所以我们的库就是帮助用户封装掉这些“脏活”, 对外提供简单的 DDBridge.funcName(options,callback) 接口, 优化使用体验.

为什么说对外暴露的接口越少越好, 因为接口越多, 则说明用户的学习成本越高,

比如如火如荼的 Vue.js, 1.x 版本很多接口的功能大同小异, 所以在 2.0 版本的 Vue 就干掉了很多接口, 减少了用户的学习成本.

同样的, 我们在做 JSBridge 分享接口相关的时候, 也通过一个 share 接口封装了端提供的微信分享、支付宝分享、微博分享等接口.

3.先思考再动手, 设计合理的代码组织方式.

我们在写代码之前, 一定要先思考清楚, 切忌上来就写代码, 那样很容易写成一波流代码.

合理的代码组织方式, 有利于代码的扩展和维护, 最基本的就是模块化.

这里没有银弹, 需要大量的实践和总结, 学会抽象的看问题,

看一些设计模式相关多书籍, 多看优秀的开源的代码, 可以先从模仿开始.

由于我们写的是通用服务, 用户也可能会提出各种需求, 当我们遇到这个问题的时候, 不能上来就写代码去实现甚至 hack,

而是先思考这个需求是不是可以抽象成通用的需求, 如果不能抽象, 我们如何更优雅的实现,

之前的设计是不是有问题. 总之, 要多想多思考, 也可以和小伙伴讨论, 争取做到是在设计代码而不是堆代码.

4.追求体验极致.

现在很多前端都在玩 node, 玩构建工具, 玩 mvvm 框架, 玩 es6, 好像感觉学会了这些就可以提高身价.

其实, 这些大部分都是工具、服务我们平时工作的, 不要忘了我们的本行还是前端, 还是需要写页面的.

其实前端有些组件和效果如果想要追求体验极致的话, 也不容易. 如果能做到极致, 身价也不会低.

举个例子, 我在写 mofang 移动端组件的时候, 有个筛选器组件 picker, 类似 IOS 原生 UIPickerView 的东东,

我当时拿到需求的时候, 也从 github 上搜索过, 没有满意的, 体验都很一般, 于是我就对比 IOS 原生的 UIPickerView 的体验,

思考它的实现、一点点细节的调试, 最终也撸出来体验几乎一致的移动端 h5 picker 组件.

举这个例子其实想说明, 我们在做通用服务的时候, 要多花心思,

如果能做出一些极致体验的东东, 不仅对用户来说他们很乐意使用, 对自己也是一种锻炼.

5.一定要写 wiki

要写 wiki!要写 wiki!要写 wiki! 重要的事情说 3 遍.

由于我们做通用服务, 免不了和用户打交道, wiki 就尤为重要了.

我们需要把通用服务的接口, 使用方式, 常见问题等都写清楚,

好的文档可以很好的指导用户如何使用我们的服务, 这样可以大大的减少沟通成本, 节约我们自身和用户的时间.

6.要学会销售.

有些人可能会觉得写通用服务似乎比做业务的同学更高大上, 其实不然,

本质上我们都是在为公司打工, 都是在输出自己的价值, 只是做事的重心不同.

那么做公共的同学的价值在哪里, 就是让自己写的通用服务被更多的人用, 去提升他们的工作效率.

所以, 我们要学会销售自己的服务, 而不是写完一个的服务摆出一副你爱用不用的态度.

如果你写出来的东西没人用, 就算它再牛逼, 对公司的价值也是 0.

另外, 我们还要学会从业务中去沉淀服务, 要去发现业务中的痛点, 可以提升效率的地方, 然后用技术的手段和工具去解决它.

7.一颗服务的心.

做公共的同学一定要有颗服务的心. 我们售卖的是自己的服务, 那么也一定要做好售后服务,

除了 wiki, 各种沟通钉钉微信沟通群也要积极响应, 耐心的去帮助用户解决问题,

其实很多时候, 都是靠着用户去帮我们去发现 bug , 完善功能和优化体验的.

谈下我的个人成长

我入前端这行已经4年了, 在学校的时候我是玩 .net 的, 喜欢折腾.

毕业后当然和大部分应届生一样, 渴望进 BAT 这样的大公司, 不过 BAT 几乎不招 .net 的岗位.

由于我读研的时候做过一些网站方向的开发, 所以就投了百度的一个相近的职位, web前端开发.

这里我要特别感谢我百度的mentor张袁炜, 他是一个对技术要求很高的人, 受他的影响, 我也成为一个对技术有追求的人.

四年的工作经历, 我写过页面, 写过网页游戏、写过 chrome 插件、写过框架、写过组件、写过服务,

由于一直在做不同的东西, 每一年我都有所收获.

兴趣导向, 有的时候我感觉写代码和玩游戏是一样爽的事情,

我也很喜欢看优秀的开源作品, 看看他们的代码设计、技术细节,

会吸收一些不错的东西到自己平时的工作中.


前端这几年发展很快, 新技术层出不穷, 有的时候, 我们要跳出自己的舒适圈,

接纳一些新事物, 新技术, 去让自己不断学习, 而不是满足于自己已掌握的那些技术.

这里我不是去倡导滥用新技术, 而是要保持一颗学习的心态, 一颗包容的心态.

📌 评论规则

需要 GitHub 账号登录 禁止发布广告、无关内容 请保持友善讨论