行业内对低代码开发是什么看法？ 第1页

软件开发领域的技术，最终无外乎两个目标，降本和增效

能实现其中一个就算是成功技术，能同时实现两个就是伟大创新了。

那么我们可以分析下软件开发的成本是怎么构成的，软件行业不像制造业，它几乎没有原材料成本，设备成本占比也很低，主要成本是人力成本，实现同样的功能用的人越少越好，越便宜越好。

但人力的少和便宜是不可能同时实现的，通常是“很少很贵的人”，或者“很多很便宜的人”，因为采用“很少很便宜的人”是无法在竞争中胜出的，“很多很贵的人”根本就做不到。

所以单纯降成本是很难的，人力数量和单位成本此消彼长，无法同时降低。

那么只能从提升效率下手了，但是增效也有两种思路，一种是让优秀的人能更高效地工作，一种是让普通的不那么优秀的人也能工作。第一种是提升个体效率，第二种是通过提升组织规模来提升效率，毕竟优秀的人太少了，让更多普通的人也能参与开发，从而提升组织的效率。

过去软件行业的技术就是一直沿着这两个思路去演进的，但是同时满足两条路线的技术是几乎不存在的。

比如 C/C++语言，emacs，VI，git是走第一条路线的，在优秀的程序员手里他们可以爆发巨大的生产力，而 Java，.Net，IDE，各种script 则是走第二天路线，降低编程的门槛，让更多人可以参与开发工作。

那么问题来了，目前火爆的低代码技术是走哪条路线的？

如果走第一条路线，那么低代码有太多限制，限制了优秀程序员的发挥，所以显然不是。

如果走第二条路线，那么看起来的确是降低了程序员的门槛，但是这东西能很多人同时开发吗？能大规模团队协作吗？

代码行业也要遵守守恒定律，不能无中生有，更多的功能只能靠更多的代码去实现，不一定要写更多，但是实际运行更多代码，不是你写就是别人写。

如果低代码试图走很少很便宜的开发人员就能做开发的路线，那么实际运行的更多代码由谁来写呢？

所以低代码技术要成功，第一条路线肯定行不通，优秀的开发者才不会用低代码平台，第二条路线就要求低代码平台具备大规模并行协作开发能力，还有第三条路线就是提供足够多的基础代码，让实际开发者可以用很少很便宜的人去做。

第二条路线的核心问题是并行协作能力，第三条路线的核心问题是庞大的基础代码库。

哪个低代码平台框架首先解决了第二或第三条路线的核心问题就能成功了。

所以可以看到Java及其生态系统可以说同时走第二第三两条路线既有大规模协作开发能力，又有庞大的基础代码框架库，同时解决降本和增效，堪称软件业伟大创新。

低代码会是下一个Java吗？