低代码指南100问：23低代码研发痛点？

低代码研发痛点？

相信大家都知道了，接下来的内容是本文真正的重点。为什么要这样说呢？这主要和博主自身的工作有关系，简单来说，公司需要一个想象中的可视化设计器，业务人员只需要通过拖拽就可以完成业务逻辑的编排，而开发人员则需要负责对外输出组件供业务人员使用。这听起来特别像我们刚刚讨论的第二种产品形态对不对？听起来非常美好对不对？我承认这个想法真的符合潮流、非常的“低代码”。所以，我们前期采用了微软的 Windows Workflow Foundation 框架，使用以后的效果大概是下面这个样子：

多人协作不便

那么，我们在这个过程中到底遇到了哪些问题呢？首先，这种可视化编辑的场景，遇到的第一个问题就是多人协作，如果你使用过腾讯文档、钉钉文档这类在线文档类产品，你应该能领悟到我说的这个点。微软的这个框架是采用XMAL这种格式来储存数据的，虽然理论上可以通过 Git 实现多人协作，实际维护起来表示非常地麻烦，所以，我们最终由单人去维护这些工作流。那么，更广义上的低代码又该如何解决这个问题呢？流程图这种东西，就是一种看起来非常清晰，改起来非常麻烦的东西，就像一条锁链一样，你要不停地断开和接上。

孱弱的表达能力

其次，是流程图这种表现方式的“表达”问题，就像你如果需要在SQL里表示循环要用到游标一样，这类工作流都无法表达程序三个结构中的循环，更不用说表达力孱弱的表达式啦，所以，这就造成一个非常尴尬的问题，你在流程图里写不了太复杂的表达式，一旦业务人员写不出来，就需要开发人员去写辅助性质的代码，类似正则、字符串插值、字符串处理、格式化等等的函数或者API非常缺乏。当然，我最无法忍受的，就是组件与组件间传值的方式，你除了返回JSON和写表再没有其它方式，更何况这个JSON返回给某个组件了，人家还未必能直接解析直接使用呢？因为编辑器无法绑定这种复杂的数据结构。

混乱的变量和参数

接下来，我最想吐槽的是，关于全局变量和参数的问题，在流程图中你经常需要各个分支的标志位(Flag)或者是临时变量，然后你就看到了那种“变量满天飞”的混乱局面，简直像极了你刚开始写的代码，你需要顺着每个线条，逐个点开每个组件的属性面板，查看它都使用了哪些参数或者变量，至此，你终于明白了它的数据是如何流动的。从前，乡愁是成千上万行的代码；现在，乡愁是剪不断理还乱的“蜘蛛网”。多年前，我对虚幻引擎(Unreal)的蓝图功能有多么憧憬；多年后，我对这种基于流程引擎的低代码就有多排斥。尤其是，当我需要复用某一段逻辑的时候，我只能小心翼翼地选中节点和线条，然后再拷贝过去。

动态计算/事件顺序/黑盒子

最后，我参考了一位被 Power Apps 所折磨的朋友的意见，除了上面提到的这些问题， 属性面板或者公式无法使用动态计算的值，类似Vue 里面的计算属性，从实际使用的体验来看，这类以流程引擎和表单引擎为主要卖点的低代码工具，其实都会存在这样的问题，而面对这种问题，一般只能通过trick的手段来解决。同样地，Power Apps 事件顺序的不确定问题，因为低代码实际上是框架提供了某种机制，可以帮你完成某个事情，所以，低代码内部对于使用者来说，完全就是一个黑盒子，譬如 Power Apps 在无网络的环境下使用会卡顿，调试起来非常不便等等。