使用低代码平台危险的赌注

　　低代码应用平台（LCAPlowcodeapplicationplatforms）在多样、复杂的现代软件开发情势下应运而生。依据Gartner（高德纳，全球最具权威的IT研究与顾问咨询公司）的数据，Mendix是这方面的翘楚，所以允许本文将它做为参照。但其实类似的结论也适用于Outsystems、Appian、Kony、BettyBlocks以及其他平台。
　　在向高管推销时，LCAP们会号称业务人员（即非专业开发人员）就能构建企业级的解决方案。那么，后来专业开发人员都失业了吗？事实是几年以后Mendix承认：专业开发人员比以往更需要。见下图。
　　好尴尬呀！我猜测Mendix意识到任何比基本的CRUD复杂的事情都需要一个软件工程师，就好像除了打气之外的汽车维修工作都是需要专业人员一样。
　　不幸的是，当下的低代码平台并不是给专业开发人员设计的。并且长时期的依赖低代码平台对业务来说是危险的赌注。下面我来解释其中的原因。做原型开发很赞
　　事实上Mendix对开发简单的自动化商业流程、或者交付可运行的原型系统来说，是业余开发人员不错的选择。在一个可视化的设计器中定义数据模型，使用内置的组件、模板来设计脚手架交互UI，甚至可以使用microflows（microflow类似于Java中的方法，有入参，出参，可在里面做循环，判断等等）描述业务逻辑：
　　完成之后，可以把应用一键部署到Mendix云上，然后运行。看上去简单而有魔力，这足够让企业高管签支票。
　　但是，当你的应用过了原型阶段，用户交互和业务逻辑会不可避免的越来越复杂。这个时候，为了避免结果一团糟，你将需要一个专业工程师来推进项目。
　　所以下一步，我们从专业工程角度来看。低（慢）代码
　　用低代码平台的时候，任何逻辑包括计算和用户交互都需要用一个microflow来描述，如上节中的图示。这里就有一些问题。
　　首先，会慢。想象一下，拖动、配置，然后将十几个模板连接起来，相比于在好用的IDE里敲十几行代码。规模上去以后，你的microflows不可避免的多到难以管理。
　　其次，可读性。模板看上去很妙，但是后面的SubRegistrationValidation呢？不跟进去根本无法阅读。
　　权宜之下，Mendix提供了Java操作。你可以在一个microflow中调用Java方法（但是由于云部署的限制，对这些Java方法也有严格的限制）。你可以在Eclipse中写好Java代码，尽管更多人选择更优秀的IDEIntelliJ。透明度是一个风险Java代码的入口都在microflows中，所以调试、跟踪都变的复杂了。逻辑流程分散在两处。
　　最后不得不提的一点是版本控制。好消息是确实有这方面的版本控制软件，坏消息是它是Subversion的一个受限制的子集。跟git再见吧。不可控
　　任何熟悉Java生态的人都不会低估开源的能量。当有一个异常抛出时，你能看到发生异常的代码，也能通过调试来看发生了什么，你能Google，也能提一个pullrequest。最坏的情况，你可以fork整个项目。这些都是可控的。
　　用Mendix的话就什么都别想了。它是一个商业权属物，调用栈里是个黑盒子。你可选的只有付费的售后支持，或者祈祷上天能在社区获得回答，每月大概200个问题，与stackoverflow上带Spring标签的问答数目比比？销售商锁定
　　Mendix可能是被经常问到这个话题，他们发布了一篇文章来解释如何解除锁定。如果仔细阅读，它提到了：
　　你可以拿到你的数据、DDL，UI资源和代码（microflows可以神奇地转为Java代码）。
　　那么你拿到的代码可以脱离Mendix的运行库和API独立编译或者运行吗？事实上，这需要重写整个系统。你被锁在一个商业权属物平台上，你甚至不拥有你构建的系统。扩展性受限
　　Mendix的目标客户是大型企业，所以扩展性在他们的市场材料中被多次提及。2017年他们引入了statelessruntime无状态运行时，所有会话信息即存在客户端，又持久化到数据库。理论上，横向扩展将没有上限。听起来很酷，但有一个问题数据库。
　　数据库通常是企业级应用的瓶颈所在。在集群的无状态Mendix服务后面是用什么在存储数据呢？没有惊喜就是关系型数据库。Mendix使用的是PostgreSQL。Mendix没有缓存，而且它生成的DDL是有问题的，比如，我见过对一个1：N的关系生成了一张N：M的临时表。
　　如果控制权在自己手里这样也可以接受。Oracle及其他数据库已经证明了RDBMS是可以扩展的，你可以优化DB结构，缓存数据或者使用Citus这样的方案来做扩展。但问题是使用Medix的话控制权不在你手里。
　　唯一可行的是使用只读复制（如AmazonRDS），但这个对写数据没有帮助。
　　总结，存在基础上的扩展限制，并且缺少微调性能的选项。降低（提高）技术要求
　　降低技术要求对主管来说听起来很美妙，昂贵的、难找的专业人员不再需要了。实际上，这是一个坏招。当你真的需要一个专业开发人员时，就会苦恼如何找到一个好的开发人员，因为对于专业的工程师来说，使用低代码平台意味着职业生涯的结束。价格很美丽
　　最后但并非不重要。一个单应用授权最低1875每月，限于50个内部用户，并且最少购买三年。可以部署到premises的企业授权最低7825，几乎100K（10万）每年。所以一个有几千内部用户的大型企业每年大概需要几百万美元。
　　并且要注意的是依据以上讨论，我们只是针对相对比较简单的应用。这对我来说很疯狂了。这个定价下，你还不能自己发布你自己构建的应用。那为什么LCAP还如此流行？
　　在我看来，答案令人沮丧。在大型机构中管理工程师团队无论是内部还是外部目前来说都过于复杂。预先进行预算规划，相关人员（架构师或者直线经理）各自有各自的议程，缺乏责任感等等。所以推进、实现自己的想法很难。更有趣的是，管理人员下意识的应对策略还是雇用更多的开发人员，当然还有更多的经理。毋庸置疑，这会使情况变得更糟。我知道有几家拥有超过10，000（！！！）个开发人员的银行，我还知道里面至少有一半的人在从事无用的工作。令人绝望的是，企业高管因此寻求那种神奇的、解决所有问题的解决方案，例如LCAP低代码应用平台。
　　如何摆脱这一团糟是另一篇文章的主题。但这是一个管理问题，而不是技术问题。跳过所有细节，如果你能让310位具有相当资质的人员全力开发，并能与相关人员和决策者直接沟通，你将获得比想象中的更快、更便宜、出色的结果。有其他选择吗？
　　如今，开发人员工具和框架有很多选择。例如，SpringFramework是最流行的企业软件开源框架，可以与React或Angular等Web框架很好地结合在一起。在过去几年中，SpringInitializr和JHipster之类的工具使上述操作变得更加容易。
　　如果你需要更快的结果和更容易采用的方法，那么CUBAPlatform之类的RAD工具非常值得考虑。它建立在SpringFramework之上，并通过可视化开发工具和无缝集成扩展插件市场进行补充。对于开发人员而言，这可能是LCAP的最接近的替代方案，同时仍然提供灵活性和便捷的开发过程。
　　因此，有很多选择，如何选择应取决于任务、团队技能和偏好。总结
　　低代码平台用来开发原型很赞。它们将业务相关人员和IT连接，使结果可视化，促进双方更快地达成一致。由于参与人员很少，所以成本也很低。但也只能到此为止！
　　否则，继续使用下去，开发速度将减慢，你将越来越多地陷入又贵又限制诸多的商业权属平台中。
　　只要AI还没有替代我们工作，企业软件就应该由专业开发人员来构建。因此，设定一个可到达的目标，组建一支精干的小型团队，聘请有能力的领导，让他们自己选择工具，并且不要忘记将他们纳入业务领域。很快地，你将看到你的想法逐渐成形！