低代码会是六便士还是一地鸡毛？（低代码时代）

“满地都是六便士，他却抬头看见了月亮”。

毛姆写下的这句话时，那个为追求艺术的斯特里克兰为追求心中的艺术梦，抛妻弃子，穷困潦倒，留下划时代的艺术作品。

低代码诞生，也是源于程序员对减少工作量的追求，工作之余能抬头看看看月亮

所谓的低代码，顾名思义，就是以不用或者很少用写代码的方式，来构建企业应用。一听到不用写代码，很多人当然非常的欢迎。毕竟，请程序员来写代码是一件很费钱费时间的事情，鼠标点点，就把应用程序给构建好，是看起来很爽的事情。所以既有非常支持的一堆人群在，也有很反对的一堆人群在，这显然是可以理解的。

上面这个例子，至少说明，如果有合适的工具，即使不写代码，也可以干很多的事情。低代码开发应用程序，我们这里需要仔细定义开发是什么？才能够理解低代码的未来到底怎么样。

关于开发，或者目前市场上关于低代码开发程序，至少有两种不一样的观点。第一种观点，开发过程中依然会涉及到代码，只不过代码的生成是在后台，由系统自动生成并且产生。

这种低代码开发的方式，并不是什么新鲜玩意。在2000年以前，就有了Visual Basic， Delphi等很多著名的可视化开发工具。它们倡导和鼓吹的，其实也就是机器可以帮你写代码，所见即所得的。你自己不需要写什么代码。

这种开发方式成功了吗？没有。为什么呢？代码这个东西，并不是一个好的抽象层面的东西，里面涉及了太多的细节。如果说低代码就是系统后台帮助生成代码的话，只要有点问题，客户还是要翻出后台自动生成的代码去改。Visual Basic和Delphi其实都无法逃脱这种命运。于是乎，可以看到未来必然是一地鸡毛。因此，我们可以说，以系统后台自动帮助用户生成代码的方式提供的低代码平台，前途是非常有可能一地鸡毛的。

我们再回头来看一下Photoshop这个例子。最终用户在制图的过程中，并没有使用和接触到背后的代码，相反的，用户使用的是系统提供的非常全面，细致而复杂的各种模块。用户正是用这些模块提供的功能，完成了自己对图像处理的创作。

这种创作也可以对应到低代码市场来。低代码的另外一个实现形式，我们不妨叫做搭建应用，以区别于生成源代码的开发应用。平台提供了大量丰富的可以定制的功能和组件，用户则聚焦于自己要实现的业务逻辑，利用这些组件进行“创作”，搭建应用。

可以想象，这里只涉及到对已经实现很完善的各种组件的调用和组合，并不涉及到代码本身，所以这种平台的低代码应用是可以做到零代码搭建成功的。

这就是目前APaaS的概念。不同于SaaS直接提供应用，也不同于PaaS提供平台，它的主要作用是给真正的应用提供各种各样的组件。用户可以在这组件的基础上搭建自己的应用。

当然，这并不是说低代码可以开发所有的应用，事实上几乎每个APaaS在提供组件的时候都需要聚焦于某个行业某类应用，就像Photoshop聚焦的是图像处理一样。

在这个行业这类应用下进行深耕，用最优秀的开发者开发出易用强大的组件，然后开放给更多的应用搭建者，以无代码的方式进行搭建，这种方式的低代码平台，如果做好了，自然是前途一飞冲天。

而且这种方式搭建应用，和传统的请专业开发者来给自己构建系统的好处是不言而喻的。通常来说，市场上并不缺乏开发者，但是对特定应用来说，比如说企业的ERP管理软件，优秀的开发者，同时还需要懂业务，是很宝贵的资源。很难做到每个企业都可以网罗一批优秀开发者，投入足够的时间进行开发给自己企业使用的系统，无论是时间成本还是钱，代价都是巨大的。

相反的，通过应用平台APaaS的方式，公司可以集中市场上对特定领域的业务流程非常熟悉，同时开发能力也非常优秀的开发者，开发出适用于这个行业这个领域这个业务的对应组件。

这些相关组件的开发并不容易。开发出高质量的组件往往意味着更大量的时间成本和金钱成本。然而，好处也同样是不言而喻的。这些由既懂业务，又懂技术的人开发出来的组件，无论是专业性还是可用性都非常的高。

由于在APaaS这样的环境下，这些组件得到了广泛的复用。平均成本分摊下来，就不显得那么的吃惊了。这样，企业应用者可以聚焦于应用本身，通过APaaS平台提供的组件来搭建自身的应用。APaaS平台则通过给大家复用组件，不但分摊了成本，更能赚取丰厚回报。而这又会促成APaaS进一步升级其组件。良性循环得以形成。

当然，这种做法并非没有缺点，一旦使用组件进行搭建，必然会遇到一些灵活性的问题。比如说我想做这个事情，如果我请专业人员专门为我开发的话，就是一个功能。如果我通过组件搭建的话，可能会落在几个模块里。

模块化必然带来灵活性的牺牲，然而和收益比起来，灵活性的牺牲并非是天大的问题。和模块化带来的各种好处比起来，这点灵活性的牺牲是可以容忍的。

所以，在我看来，低代码如果是以系统帮助用户生成代码的方式来提供服务的，其结果很可能是一地鸡毛。如果是通过APaaS的方式来提供丰富的模块，用户使用模块来搭建应用程序的话，那应该有一番天地。

当然，这样的APaaS平台要是能成功的话，前提条件是其能够聚焦特定的应用领域和行业，让对业务非常熟悉的，好的开发人员，打磨出一套适合行业应用开发的，高质量的组件。

从这个角度看，低代码显然也并不是万能仙丹，可以用来开发所有的软件。但是我们可以看到，如果APaaS的平台模块化做得足够好，搭建应用的时候对用户的门槛就会足够的低，这就能促进更多人来使用。最终低代码开发是不是能一飞冲天，还是取决于APaaS平台自身产品有多硬。