事实上，低代码既不是那么“无用”（仅能解决一小部分问题）、也不像大家想象得那么“简单”（像PPT那样易学），低代码有其独特性，是下一代信息化生产力的代表。当下的低代码，挑战与机遇并存，本文分析低代码在被质疑的诸多方面中典型的问题。
关于低代码，大家争论的焦点往往围绕通用低代码展开。
我们在上文中提到了**“通用低代码“的概念，目标是将低代码作为通用开发方法广泛应用于各类业务场景**。事实上，虽然有OutSystems、Mendix等公司的部分成功经验可供借鉴，但是行业里有不少人对这类不依托业务PaaS（Salesforce属于此类）的模式普遍存在质疑，主要围绕以下几个方面：
能解决复杂的问题吗？
低代码能够搭建复杂的业务吗？即使能够做到，与Pro-Code相比有明显的优势吗？
目前大部分低代码产品，真正适合解决的问题范围确实比较有限，很多平台为了做到通用化，一味堆砌各类功能，概念越来越多、产品越来越复杂，最终适得其反。
低代码的尴尬
低代码的处境其实很尴尬。“仅需要少量代码即可完成应用的搭建开发”，听起来很美好，但在实际情况中，因为涉及到职业发展、个人偏见等多方面原因，很多工程师不愿意使用所谓的“低代码”。另一方面，因为需要写代码，哪怕占比很少，这对于业务人员也几乎是不可能完成的事情。
“专业开发看不上，业务人员不会用”，因为低代码面向的用户人群定位不明，很多创业公司开始转型无代码赛道，将用户锁定为“无需了解编程能力的业务人员”。但是，目前通用型无代码总体表现欠佳，更多聚焦在细分领域，所以一般提到无代码，大家的普遍认为能够解决的问题范围有限，甚至有观点认为无代码因为太细分，不应该属于低代码的范畴。
此外，因为无代码需要通过图形化编排取代一部分文本型代码，在图形化编排方面，大家的更多关注点是其能否取代传统文本型编程的问题，这里也经常形成大家争论的焦点。
推广落地的困难
在低代码领域，有一个心照不宣的问题是：CTO或CIO 欢迎低代码吗？
在企业中，引入低代码有可能导致对技术团队造成一定程度的削弱，这可能是CTO或CIO不愿意看到的。另一方面，出于对低代码的偏见或错误理解，技术团队很多时候会低估低代码平台的复杂度而倾向于自研自建，“不就是建站工具吗？我们可以自己做”，这样的声音不绝于耳。
即使企业同意引入低代码，在推广实施过程中，各个团队的配合度也会是一项考验。对于技术团队来讲，一部分业务开发工程师工作被低代码工具代替了，这部分成员如何转型？对于业务人员而言，即使是无代码，也是有一定的学习成本的，他们的接受程度如何？凡此种种，都是在推广过程中会遇到的挑战。
商业发展的想象空间
在低代码的商业模式设计上，工具化还是平台化始终是个问题。低代码创业者希望找到可以平台化、生态化发展的模式，但是在实际推广时，让“用户自主化完成”、吸引“技术社区的开发者编写组件”、鼓励“合作方贡献行业模板”，这些都充满了挑战。甚至，在多数时候，低代码企业成为另一种外包公司形式的代名词也屡见不鲜。
感谢阅读，下一篇文章，我们将对低代码领域大家关心的更具体问题做出回答。
欢迎访问免费、通用的无代码开发平台Mybricks ，体验图形化编程的乐趣
