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

前言

提升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同窗更好的对每次新版本上线老接口的自动化回归测试，减小烦恼，框架开发者也是会很幸福的。

幸福来自于付出而不是索取。