本文内容

• 低代码发展现状
• • 国外趋势
  • 国内风云
• 低代码产品形态
• 低代码研发痛点
• • 多人协作不便
  • 孱弱的表达能力
  • 混乱的变量和参数
  • 动态计算/事件顺序/黑盒子
• 本文小结

一直想写篇文章，聊一聊“低代码”这个话题。一方面，“低代码”这个概念确实非常火，其热度丝毫不亚于曾经的“中台”。有人说，2021年是属于“云原生”的时代，看起来我们每一年都在被技术的“娱乐圈”抛弃，明明连 都还没有入门呢们已然在欢呼雀跃般地声称要抛弃 。这个世界有时就是如此地魔幻，明明我们生活在一个拥有大量基础设施的时代，我们不必再像前辈们“刀耕火种”一般地去开发软件，可我们的生存空间为什么就越来越狭窄了呢多多事件过去没有多久，腾讯的阳光普照奖再次让“打工魂”觉醒，也许果真像大鱼海棠里设定的一样，人的记忆只有7秒。而另一方面，我想结合我最近开发“工作流”的感受，来吐槽下这个看起来美好的“低代码”。也许，对企业而言，引入“低代码”的确能减少研发成本，可博主并不认为，它会降低业务本身的复杂性，如果所有声称“低代码”或者“无代码”的项目，最终依然需要研发人员来作为收场。对此，我想说，对不起，这不是我想要的“低代码”。

低代码发展现状

或许，一个人成熟的标志就是，在面对一个未知的事物的时候，决不会不由分说地一通吐槽，就像一个人在职场上，你不能永远都只是学会抱怨，相对于抱怨，人们更希望听到的是解决方案。所以，一个人的成长，本质上就是不断学会为自己、为别人找解决方案的过程，前者是为了认识自我，而后者是为了交换资源。所以，在听我吐槽“低代码”前，不妨先一起来看看低代码的发展现状。

低代码研发痛点

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

多人协作不便

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

孱弱的表达能力

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

混乱的变量和参数

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

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

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

本文小结

坦白来讲，这篇博客实在没什么“技术含量”，无非是按照一个月前的计划在整理内容。我对“低代码”持一种中立的态度，作为程序员，我是希望有这样的技术来简化流程，可以让研发人员从枯燥的“增删改查”中解放出来，留出时间去做更多有意义、有价值的事情。当我了解了低代码和零代码的差异以后，我突然明白，我需要的其实是零代码，因为我希望那帮业务人员能自己搞定，这样就不用再来烦我，可经历这段时间的“低代码”，我清醒地认识到，这个想法根本不现实。一来业务人员并不像他们想象的那样，除了不会写代码以外无所不能；二来业务的复杂性满足守恒定律，它永远不会消失，只会从一种形式变成另一种形式。也许，低代码真的能帮企业省不少钱；也许，企业最喜欢做的事情，就是花点小钱招人外包做这种事情。但我依然想告诫开发者们，不要去追逐这些看起来美好的东西，对企业来说，它今天使用 A 技术，明天使用 B 技术，完全无关紧要。可对于个人而言，这个选择显得非常重要。看一看曾经的 SAP 咨询顾问就知道了，如果有一天 SAP 都倒闭了，你掌握着这些只有在 SAP 上能发挥作用的技术有什么用呢技术人员来说，学习通用型的知识和技能，永远比把鸡蛋放在一个篮子里要更保险。

来源：云来雁去