@justin03 嗯，这种，实现起来不难。
但是业务方，可能更加希望直接操作数据库吧，更加灵活。
除非他的 SDK 封的，数据模型抽象的特别好。

帅气~反手就是一个 star ！

先问是不是，再问为什么？

而且，不能抛开具体的应用场景来说这个问题。
就我所见，小公司，后台开发，还是 Java 最多。

如果真是有个哪个公司选的是 node，那估计创始人之一是前端初出身。
如果选 Go，那估计创始人之一，是 C/C++出身。。

年轻的时候，不要想着涨薪，闷头积攒能力才是王道。

====
来自过来人的教训。。

有副作用用 post，无副作用用 get

反手就是一个赞~

看着日益增长的房价，和自己慢悠悠涨的薪资，以及几年不升的职级。的确挺焦虑的。

不过话说回来，路还是要自己摸索，别人给的，都不是路，是套路。。

现在的 web 接口，就是太灵活，一个东西有很多种解，这样才会早餐分歧。。
啥时候，能出一个编程范式，可能一个东西，就只有一种实现，那么程序时间就可以解放了。

甚至，编程机器人，也就不远了。。哈哈😄

@zzzzzzZ 少点戾气吧。。。

@whileFalse 不懂 lambda 驱动是什么意思，是 aws 那个 lambda 吗？
我想的是，未来软件应该是像拼积木一样的，或者组机器一样的。
有一个非常庞大的共享的组件库。（包括前端，后端）
前端可以是类似于 react 那种的基于标签的组件库（比如表单元素，必须有 value，onChange 属性，这是一种协议）。
后端的 web，微服务，可以是类似于 reactive 风格，类似于 spring-flux 那种，基于函数式的串联
大数据的话，flink，spark 那种，其实也是一个处理流，是完全可以具象化一个 DAG 图的形式，每个节点就是组件和边就是流
所以一个很关键的是概念应该是协议和实现。应用应该是面向协议的。
到时候软件开发，应该会更加轻松。。

所以回到我的主题，未来程序应该就是开发组件，实现一个已有的协议。
需求方自己负责对组件进行组装。。

@gz911122 好用吗？有坑吗

@gz911122 kotlin 的协程能用吗？

@gabezhao 是么，那我感觉我可以去试试写小说咯~

就问谁还记得 7xi.net

@whileFalse 怎么说呢？接口给出来了，实现就行，需要控制哪方面？时间问题还是什么呢

@leo108 所以公司是不是只需要雇佣一个系统分析，拆解师，就好像雇佣一个电脑组装师一样。。

@leo108 的确，在日常工作中，这些工作的确相当繁琐。

但是对于一个细分领域，是不是可以通过工具，将这些流程规范化，标准化。比如测试样例生成软件？接口定义模板？（前提是平台要定一个模块集成规则，spring IOC，RPC ？）
当然，这个需要摸索。。

那，就我上面提的场景

> 作为我自己来说，假如我每天收入 500 元，我是愿意拿出 100 元，解放自己的时间的。将我的工作进行适度的抽象，拆分，不泄露公司隐私的前提下，将这个作为任务派发出去的。

发展到后来，会不会出现专门的“系统分析，拆解师”，这样也是分工更加细化的趋势吧？

@qq976739120 所以就是，我就只出这么多钱，帮我实现这个接口，爱干不干。。
当然有些人，核心模块，他是愿意出高价，把活交给一个信誉，技术，评价比较高的程序员的吧？

@est 我只知道他是个 CRM 软件？还做开发者平台的？他是什么模式？