前言
笔者在低代码领域工作大约3年左右，有用过别人写的低代码框架，也有从0-1搭建过企业级低代码平台。最近在搭的是面向实施人员/解决方案工程师的无代码平台，也就是目前的一些需求让我重新审视了一下，之前的做法是否太过刻板。一想到低代码，脑海里浮现的第一印象就是左侧组件库，中间页面搭建器，就往里面拖拖拖。我发现自己之前在做这个东西的时候纯靠刻板印象，和用户完全脱钩。所以想乘着自己的想法还没消失记录一下。
为什么会用到低代码平台？
低代码平台出现的初衷也很明显：
- 提高效率。
- 降低人力成本。
- 降低开发门槛。
- 堆积物料。
效率提升
说到提升效率，个人觉得这里提升的不仅仅是页面搭建的效率，还有更多的是优化了项目初始化，应用发布，应用部署的耗时。这些平时开发的时候你可能不会特别在意他们，但是他们花的时间是巨大的，特别是当你的版本迭代得越频繁，流程越繁琐，这些耗时就会成倍增长，有时候开发时间还没有在那等部署的时候久。
低代码带来了急速的CI/CD体验，大部分低代码输出的都是JSON格式的页面配置，配合固定的渲染器，只需要将JSON同步到发布环境，就能实时更新已发布的应用。这些过程完全可以是由UI以及自动化控制的，也就是说操作者不需要有开发背景，这就引出了下一个初衷。
降低人力成本/门槛
这里就会有点争议了，因为现在的低代码搭建器并不能实现这一点，有的甚至是你不仅要会前端开发，还要会写sql，然后还要理解他的低代码搭建器里的一些新概念和逻辑。
现在我看到的低代码框架，大部分都是面向开发者的，但是，它面向的是前端开发者！比如我用过的AMIS，如果你不了解他的底层实现原理你甚至都不能知道他超过3层的数据继承为什么不会响应变化！所以这类框架降低的一定是时间门槛，也就是效率提升，他也可以变相降低人力成本，也就是一个人搭三个人的页面 =.=。
但是作为平台一定要考虑的是的目标用户，比如retool，他的目标用户就定了，就是开发者，让那些不会写前端代码的，通过预定义的组件实现其功能。对于使用retool的公司，可以只雇佣一个后端或者数据工程师。他们降低了后端工程师的前端开发门槛，同时让一位前端工程师丢掉了工作。
所以大家也可以看出来，如果公司因为低(js)代码平台的引入会优化人员，那优化的一定是前端开发。
用户到底是谁？
这里说点绝对的话，市面上大部分的低代码搭建器框架的目标用户都是开发者，说的更具体一点，前端开发者。至于这些项目是谁发起的，大家也不言而喻了。
说实话，我做第一个低代码平台的时候，并没有太关心用户是谁，那个时候只有一个模糊的范围，就是非技术人员。这个范围就很模糊了，到底什么叫非技术人员，哪个领域的非技术人员？并且目标用户在我们的需求里是权重最低的，我们的平台需求权重最高的就是定制化程度要极高，也就是说什么都能搭（这个也是后面我们转到B2B的一个伏笔）。所以那个时候我考虑的是数据链，逻辑编排，事件机制这些东西。页面搭建也是使用的是最常见的拖拽的交互方式。我们还有一个解决方案工程师负责使用这个平台给客户搭建应用，他强的可怕，不管你写的什么功能他都能马上学会，它会js会sql。也就是他，给我一个错觉：这个平台谁都能用。
直到我们准备把这个平台发布出去，准备走2C的道路的时候，我们才发现，能学会使用我们平台的人少之又少。唯一让我们眼前一亮的用户，职位无一例外全是开发者，所以后面我们放弃了2C。那是我学到的第一堂课，低代码的用户不会是普通用户。
到目前为止，我们的低代码平台的适用用户还是得有开发背景的工程师。尽管我们优化了很多交互，让它变得更加的低门槛，但是你还是要学习一堆概念。不过我们给客户做的项目现在是完全没有前端工程师参与的。
无代码平台
由于某些原因我离开了上一家公司，但我对低代码开发的执念还是在我找工作的时候影响着我，我想做出一个低门槛的低代码平台，这里的低门槛不是指开发人员的门槛，而是技术门槛。就算是要学，也应该是直接学低代码引擎，而不是要去专门学其他语言。所以我在找下一份工作的时候也是尽量看下低代码相关的内容。
机缘巧合下，我入职了目前的公司，负责人跟我聊的是他们想做工业管理的无代码开发。我当时就被吸引了，这不就是我的目标吗。所以我很快就入职并且进行项目的谈论和实施。
当时公司用的是AMIS，他们已经在用AMIS搭项目了，负责人想让我基于AMIS进行二次开发。我用了AMIS大概一个月的时间，它刷新了我对低代码开发的认知，太难用了，我大部分逻辑都是写的JS，有时候它UI出bug你还要直接改JSON。拖拽更不用说了，难用到不想用，我都是直接改的JSON。(下图你知道我这个文本框要拖到哪吗？)
用AMIS你不仅要有过硬的前端知识，还要熟悉整套的低代码架构知识。之所以有这样的感觉是因为比我入职早一个月的同事还要来问我这个功能要怎么搭，那里为什么数据不更新，更不要说这个给非技术人员用。
当然低代码的拖拽我之前就踩过坑，AMIS的拖拽全在坑里面。但是就算我们有指示器，拖拽的时候布局不会闪烁，但还是会出现这种情况：
几个容器叠在一起，这里的示例好一点，至少有padding。如果是纯包裹容器，没有padding，你都不知道你拖到哪里去了。
经过和负责人的几轮交流，他也很希望我们能实现一个面向实施人员（不懂技术）的一个搭建平台，所以我们达成一致，重写整个低代码平台。他还是希望我去找找现存的已有的大厂的框架。但现实是我们的目标用户和现存的框架的目标用户根本就不在一回事。我列了一个对比图告诉他如果要给实施人员做一个搭建器，目前没有一个框架能满足我们的需求。
在实现的过程中，我也是有所怀疑的，没有拖拽真的能搭好一个想要的布局吗？而实际的效果却是出奇的好，我甚至都忘了我实际还是在页面上实现了一套拖拽的逻辑。我已经很少去在页面上拖来拖去的了，因为一旦布局定好后，很少有情况需要去重新改布局的。而在布局的时候，点选会比拖拽来的更加精准和明确。
当然，这里也有些前提约定，就是我们的布局是有几个固定的，来源于产品的设计规范。也就是说实施人员需要按照这些布局来填充组件，这会进一步降低页面搭建的门槛。类似下图，主页布局组件已经设定好了布局，实施人员只需要填充内容就好了，并且还能限制他们能使用的组件。这里用拖拽只会增加复杂度。
拖拽还是点选？
铺垫了这么多，我想表达的是，不管交互怎么样，我们最需要看重的是用产品的用户群体是怎么样的。
作为无代码平台，面向的用户是基本不懂技术的实施人员。拖拽+布局只会增加他们的操作难度。单纯的拖拽很美好，但是涉及到拖拽后布局的变更不确定性，嵌套容器的拖拽难度，让拖拽这个交互反而变得有点累赘。实施人员需要一个简单明了的指令：我要在这里插入什么什么东西。而不是我要把这个东西放到哪哪哪，然后这个哪哪哪在那拖了半天拖不进去。
那么拖拽没有一点好处吗？不是的！ 拖拽用在排序上是一个很棒的交互！比如在组件树上，组件树因为有明确的层级关系，所以在这里拖拽是很方便的操作，你能够很明确的知道组件会被放在哪里，在什么里面，在谁前面，因为这里不用考虑布局。
另外，使用网格布局的话，用拖拽也是最合适的交互