用做产品的思路去开发基础框架

前言

提高RD及QA同学的人效最有效方式是将基础组件或系统进行封装与定制开发，为上层使用人员（RD/QA）提供友好的接口，对于RD同学来讲不需要关注底层实现细节，能够更多的精力关注自己的业务开发。

产品化开发系统

刚接触微服务的时候，看过一篇amazon的文章，作为服务化系统与云计算的鼻祖，amazon及贝索斯的前瞻性思考着实令人佩服，提出了数字化服务的概念。

amazon最开始是将图书及电子资源的服务进行api化，提供自己内部其他系统或合作伙伴进行使用，在最开始就提出了将每个服务对于研发做到产品角度的友好，这也逐渐演化到了aws的性质，每个商用的友好的服务都是一个独立的产品。

其实我们日常研发用到的好多基础设施都具有这样的特征，比如ES，Kong，K8s，CAT及JDK，操作系统资源，Mysql监控，Spark UI等各种监控系统或可视化的调度操作界面供研发人员使用，友好的界面可能也是我们喜欢用某种框架的原因。

所有我们会花好长时间去自研一套基础系统，整体微服务系统中在服务降级，服务链路，慢查询，舆情信息等系统都会有比较友好的系统，包含了友好的UI界面和简单的操作按钮，达到了可以一键限流，流控可视化，一键扩容等效果，整体上提升了RD的人效，而不用每次都通过对接一个SDK去从头开发，也不会因为SDK版本升级让业务方重新上线发版。

像计算机一样思考

经常见到好多公司的架构师指定各种使用规范，满满的一套wiki，运维和DBA同学写了各种工单操作wiki，每次也避免不了RD同学就同样的问题提问。

我总结这种交流和合作方式还是人的合作方式，而不是计算机的合作方式。

将太多规范性的内容通过语言或者wiki交到人的手里去实施，归根结底是不靠谱的，人是会犯错的，我们可以将这部分交给计算机，而将选择权交到人，这样可能达到最好的结果。

建立一套有效的监督系统，可以更好的帮助我们发现问题，而不是将问题淹没在海洋里。

要幸福

有的研发同学感觉不幸福，我猜：

不幸福的可能是我们到了互联网时代，公司还在用软件公司的角度去思考迭代，用大项目分层堆代码的方式面对新需求的迭代，用人工的方式去回滚代码及数据库版本。

不幸福可能是我们到了大数据时代，还在用基础的方式去处理认知，就像几年前自己手写分布式多线程系统去做日志处理而不敢去尝鲜使用hadoop，spark，这样我们可以花更多的时间去和产品对接，做出更酷的产品。

不幸福的可能是我们到了AI时代，还在各种登陆OA系统，点击各种按钮，选择各种checkbox提交工单，目前NLP，基本的图像识别，语音识别可以用到我们的研发系统中了，NLP虽然是一个值得付出一辈子的领域，但是简单的分词，相似性推理，可以用到内部的系统中，我们的chatops系统可以帮助我们简单的连接所有想要的研发系统，OA系统等，虽然目前还很稚嫩，但是我们是带着未来去思考的，依旧很幸福。

从事编程行业应该是很幸福的，我们可以通过科技帮助人们生活变得美好而简单，做基础框架的好处就是我们可以让RD的工作更加简单，脏活累活交给框架，看到大家通过一键点击就可以让自己的系统具备了多实例交付，可以帮助QA同学更好的对每次新版本上线老接口的自动化回归测试，减少烦恼，框架开发者也是会很幸福的。