自Gartner于2017年提出aPaaS概念至今已经5年多了，而我们搞aPaaS建设也有一年多了，现在是时候回头总结深入思考一下了。在进行一番调研与回顾后我认为，所有搞aPaaS的同学都应该直面并深入思考以下三个问题：
- 低代码为什么行？
- aPaaS为什么好？
- 我们凭什么能？
低代码是比aPaaS更基础的概念，提出时间也更早。低代码与aPaaS的关系简单来说就是：低代码是一种理念，而aPaaS是践行这种理念的解决方案。如果低代码都不行，那aPaaS定然好不了。不管是理念还是方案，其目的都是为了提高软件开发的效率，或者更严谨地说是为了提高用软件解决问题的效率。抓住这个根本目标，我们来深入思考并回答以下上面三个问题。
一、低代码为什么行？
低代码(Low Code)，按百度百科的定义，是一种可视化的应用开发方法，用较少的代码、以较快的速度来交付应用程序，将程序员不想开发的代码做到自动化，称之为低代码。这当然是一个很诱人的想法，但真的可以实现吗？
回顾一下软件工程和编程语言的发展史，我们经历了从汇编到C语言再到Java，从面向过程到面向对象，从瀑布模型到敏捷开发。同时，软件开发相关的从业人员越来越多了，其角色和分工也愈加细化，粗略地可以分为产、研、测三种角色，每种角色里都有更细致的划分。不同角色的人员所需要掌握的知识技能是不同的，其学习的门槛和成本也有着天壤之别。最后，在互联网技术的普及下，大众对计算机和软件的使用及理解也越来越广泛和深入，他们从学校开始就不断在积累软件相关的知识与技能。
以上是现状，而低代码做为一种理念充分利用了上述现状的优势：
1. 打造一个低门槛高产出的生产工具(低代码平台)，让更多人加入到软件开发的工作中来，人多力量大。
2. 专业的人做专业的事，发挥不同角色的优势，实现软件工程领域的人力资源优化配置，整体上提效。
3. 充分利用学校和社会教育，让“市民开发者”利用自身已经具备的知识经验，快速完成软件开发相关工作。
这也是我认为低代码从理论上可行的根本原因，同时也是打造低代码平台工具的根本遵循。换言之，如果一个低代码平台的学习成本很高、只能被一小撮人使用、平台的用户角色划分不明确、用户过往的经验对使用平台没有任何帮助，这样的平台注定是失败的。
二、aPaaS为什么好？
aPaaS全称application Platform as a Service是应用平台即服务。所谓应用平台，那就是生产应用和支撑其运行的平台，所谓as a Service就是这种平台要像服务(而不是产品)一样对外提供。这是我对aPaaS的理解，再来看看Gartner的定义：
aPaaS是基于PaaS的一种解决方案，支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。
现在市场上的aPaaS可谓玲琅满目，如百度的爱速搭，阿里的宜搭，腾讯的微搭。纵观各个aPaaS平台，从外部视角观察，可以总结一些共性的特点：
1. 拖拽式完成应用的界面搭建
2. 配置化设计应用的数据与流程
3. 少量代码实现应用的逻辑处理
4. 组件化开发理念贯穿应用开发的全流程
5. 针对垂直化应用场景而非通用化性景
6. 面向业务人员，使其可以直接创建自己需要的应用\
如果一个aPaaS平台能在上述几个方面做到位，那提效还是很有可能的，至少从表面上看，它会节省很多编码工作，也可以缩短需求从提出到实现的路径长度。
为什么这么说呢？我们知道，一个软件（尤其是Web系统）从需求提出到最终部署上线，其中最耗时的两项工作就是聊需求和写代码（尤其是调界面）。现在好了，一方面，aPaaS通过拖拽式、配置化和组件化等方式，让很多开发工作标准化，并提高了模块/组件的复用性（尤其是定位于垂直领域），这就节省了很多重复性的编码和测试工作；另一方面，aPaaS是可以直接让业务人员使用的平台，这就让需求的提出者摇身一变成为应用的开发者，瞬间缩短了需求沟通的路径，并极大降低了需求理解偏差的可能性。
以上从减少必要工作量和避免无效工作量正反两个方面提高了软件交付的整体效率，也就回答了第二个问题，aPaaS是好的、是可以提效的。
另外，从实现原理上来说，aPaaS本质上是软件开发的一种新方法和新工具，它将程序的编写方式从贴近机器编程语言的阶段向贴近人类自然语言的方向又推进了一步。aPaaS平台的用户不必再学习复杂的编程语言和了解计算机的工作原理，他们只要按照自身过往使用软件的经验稍加学习平台的用法，就可以开发出自己需要的软件。可以乐观地说，在数字化时代，面临各行各业软件需求大爆发和软件行业生产力不足的矛盾，aPaaS无疑是一种解决问题的利器。
三、我们凭什么能？
低代码行，aPaaS好，这两个答案是重要的，但更重要的是我们凭什么能。由此由引发下面三个问题：
1. 我们是谁？
2. 我们在做什么？
3. 我们是怎么做的？
第一个问题，是对自己的定位，定位不同则出发点和导向不同，取得的结果也自然不同。正如一位智者说的，“我们要成为有10年经验的CRM设计者，而不是重复做了10年CRM需求的码农”，以设计者的定位自居是我们做好aPaaS的基本要求。
第二个问题，看起来简单，但实则需要不断深入思索。我们在做aPaaS平台，这是一个简单的回答，但在aPaaS还是一个云里雾里的概念是，仅有这么一个回答是不够的。我想，弄清楚aPaaS到底是什么，并形成对aPaaS的统一认知才是这个问题的答案，这也是写作本文的一个初衷。
第三个问题，是最易被忽视的，尤其是在做类似aPaaS这种创新探索类项目时，因为没有太多前人的成功经验可供参考，这时候通常被采用的策略是“摸着石头过河”。这当然是一种方法，但“摸着摸着”我们可能就往了抬头看进而走错了路，因此我们需要时不时回头看看，对照的最初的目标检验一下当下的所作所为是否有失偏颇。
我想，当我们有了正确的自我定位、对aPaaS的共识越来越广泛深入后，再加上能不断反思调整我们的做法，如此，我们为什么不能做好一个aPaaS平台呢？
本文到此就结束了，但一切似乎才刚刚开始，如果你耐着性子看完了，不妨再看看另一篇文章：关于aPaaS的设计思考。
我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。
