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

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

低代码发展现状

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

低代码研发痛点

多人协作不便

孱弱的表达能力

混乱的变量和参数

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

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

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

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