谁说低代码做不了复杂的企业应用？
因为工作原因，我经常会在论坛中看到这样一种现象，很多所谓的专家，跳出来大喊甚至是痛骂低代码烂大街臭大街等，又拿不出什么有说服力的证据。
比如说低代码做不了复杂应用，那么复杂在哪呢？怎么个复杂法?为什么做不了？
每到这时我都会感觉很疑惑，一个企业应用能有多复杂？既不需要好看的界面，又不需要像滴滴那样抗住百万或千万用户并发的场面（最近滴滴不是崩了吗？有时间出个文章讨论下），对算法也没多大要求。
最起码90%以上的企业应用都是一些很标准化的构件组成的流程，无非是针对不同的业务流程做相应的修改。
从软件开发的角度来讲，企业应用比消费应用更好做：客户需求明显，长期合作支持。既不像C端产品那样用户群体庞大、体验多样化，也不用支持大规模的用户访问和使用，还不用根据用户的口味和风向实时更新，压力是小很多的。
很多人会说企业的应用复杂，那复杂性也分为2种，一种是业务逻辑复杂，一种是算法逻辑复杂，企业应用的复杂度大多都是集中在领域模型和业务流程，业务逻辑复杂对低代码来说不是问题，算法逻辑复杂才是问题。
如何理解业务复杂和逻辑复杂？简单解释下，业务逻辑复杂，就是业务人员能说清，只是步骤多，但执行起来简单。
举个例子，业务逻辑复杂就好比你要组织一场文化节活动，唱歌比赛怎么制订规则？怎么评分？画画展览怎么布置场地？小吃摊位怎么摆？因为涉及很多活动和细节，这里的业务复杂性就是这种要考虑的杂事很多。
算法复杂性呢？比如说解一道几何或代数题，你得用很多不同的几何定理、三角函数、基础公式来解决问题，越复杂的数学问题需要越复杂的算法，更多的步骤和技巧。
逻辑复杂就好像把复杂度平铺开，每个问题的处理难度都不高，就是步骤多，麻烦；而算法复杂就像攀登一座高山，每一步都需要精确的计算和判断，环环相扣，难度也比较高。
你只要看到我这篇文章《低代码就是不写代码吗？到底什么是真正的低代码平台?》就能知道。低代码在建模和逻辑方面的能力都是比较全面的，某些定制化的需求也可以通过脚本语言、开放集成等扩展机制，对于组件不能实现的标准化能力，完全可以通过写代码的方式进行协同开发。
事实上，这也是现在低代码平台接入现有工作流中最普遍的工作模式，像 iVX 和 Codewave 这种平台甚至是支持所有源码导出的，而且二次开发的能力也不差（ iVX 的代码可读性要比 Codewave 强一些）。
这就意味着你完全可以把低代码平台当成一个生成代码的简易工具使用，什么地方不想写代码，就用低代码平台拖拉拽的模式生成对应代码，然后接着用写代码的方式将其插入到你的主要工作流程中。
这其中，低代码平台只作为一个中转代码的工具，不用担心自己的工作成果或环境被锁定在某个平台上。你可以继续做你擅长的工作，只是把复杂的代码生成交给平台来做，你自己才是搭建这个逻辑框架的核心。
现在很多低代码平台都是采用一种混合模式——技术人员 业务人员这一套组合拳来进行研发工作的，等到低代码发展更成熟后，这样的模式占比也会越来越大。
所以说，并不是低代码做不了复杂应用，而是做不了算法逻辑复杂的应用，比如说 天体物理模拟、气候模型、嵌入式系统和硬件级编程这种偏研发、研究方向的，大部分的企业复杂要求，只是在某个业务逻辑之内复杂，专业的低代码平台完全可以覆盖。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
