简介：什么是低代码？为什么我们需要低代码？低编码会使程序员失业？本文总结了低代码字段的基本概念，核心价值和行业现状，并带您完全了解低点代码。
如果您选择使用关键字来代表即将到来的2020年，我相信每个人都会同意成为“新皇冠”。流行病的速度太快了，就像龙卷风一样，在短短几个月内，世界各地的无数人都阻止无数人之间的联系。不幸的是，我们已经全面进入了互联网时代：无论N95面膜有多厚，它都无法阻止信息的光滑循环，而不是特殊流动（otaku：station B仍然很香）；无论房屋隔离多长时间，它都不会阻碍指甲新闻的时间。对于我们来说，必须是全速击败流行病并创造未来的最佳驱动力。”因此，在流行病时代，需要哪些新技术来解放IT生产力，并加速社会的数字化转型，使世界再次伟大？我认为这是低代码。
基于经典的可视化和模型驱动的概念，结合最新的云本地和多端体验技术，低代码可以在适当的业务方案中实现出色的效率，从而为专业开发人员提供新的高生产力开发开发PareParadigm Shift.one。另一方面，低代码还可以使不了解该代码的商业人员成为被称为“公民开发人员”（公民开发人员），弥补越来越扩大的专业人才差距，同时促进了业务的最终敏捷性和技术深入协作。本文将重点关注与低代码相关的背景知识，包括低代码，相关概念和行业发展的定义和含义。预计它可以帮助每个人更好地理解和理解低代码的新兴领域。
什么是“低代码”？如果您第一次听到它，也许您会和当年听到老板嘴里的单词时相同的：什么？“低代码”？“代码”是指我知道的代码，但是这个词“低”是什么意思？不是老板，我最近写的代码是丑陋和“低” ...我认为太多了，老板怎么能亲自展示代码。这是否意味着“低级编程”？老板终于发现我等待了编程向导太多堆放Java业务代码。送我写一个高性能的C语言网络库是太浪费了……显然，老板怎么会有这种技术感觉。这意味着什么？询问Google永远不会问老板。
Wikipedia定义
根据Wiki的定义，我们可以完善一些关键信息：
Forrester定义
遵循Wiki的描述，还可以发现原始单词“低代码”是Forrester最早在2014年提出的。它定义了低代码开发平台的祖先水平。
与Wiki的版本相比，此定义更倾向于阐明低代码所带来的核心价值：
低代码核心能力
基于上述定义和分析，总结以下三个低代码开发平台的核心功能并不难：
不仅要少写代码
回到最初的白色问题：“低代码”中的“低”，这是什么意思？答案很明显：这并不意味着抽象程度很低（相反，程度，低代码开发的抽象要高于传统编程语言），它也不是刻薄的维护和重复测试，总体质量比大多数手写代码都更强），但是仅在此情况下简单的“较少代码”在一些需求中，可以将代码手工撰写。
看起来更深，低代码不仅是为了编写更少的代码：编写的代码更少，而错误的错误（如所谓的“少错”），因此开发链接的两个支柱工作“ strarry up” the the”“”需求“需求更少，并且“维修错误”；如果要测试的代码较少，则测试用例可以更少。除开发阶段外，该平台还涵盖了随后的应用构建，部署和管理，因此运营和维护操作还运行和维护操作也可以运行。
但是，少的不是最终目标：如果您只想实现较小的影响，那么减少人类和降低质量的需求是相同的。低代码背后的理念较少，或者更多（更少）或更多更准确地说出多快和好 - 更有能力，更有能力，更快地在线，质量更好，成本更高可节省成本，并节省节省成本。值。
平台的责任和挑战
以上是低代码向开发人员提供的能力和吸引力。那么，低代码开发平台本身应作为服务提供商和应用程序的提供商和应用的职责，应遇到什么责任，它将遇到多少挑战？“正如阿里巴巴云所提倡的那样？“尽管这句话听起来很清楚，但我不知道您是否已经考虑过，为什么我们必须变得复杂而不玩，并无缘无故地找出答案？您不能直接杀死复杂性，对于我们的阿里巴巴Yun自己的员工来说，这太容易了吗？工作对于反映KPI的价值太容易了，还是不如公司在公司中的晚餐那么好？
经过长时间的冥想后，我发现了第一个热力学定律的答案：应用程序开发的总复杂性是恒定的，只能转移并且不能从稀薄的空气中消失。如果您希望开发人员做更少，享受简单的幸福，然后平台必须做更多和默默地采取尽可能多的复杂性。就像充满肌腱肉的杂技一样，旋转和跳跃高高的女性伴侣稳步旋转和跳跃。当然，上面的女演员很容易承受压力，而是他们各自的劳动分裂是不同的，而且他们所承受的复杂性也不同。
根据“人类月亮”的作者弗雷德·布鲁克斯（Fred Brooks）的划分，软件开发的复杂性可以分为基本的复杂性和意外复杂性。前者是解决问题时固有的最低复杂性。它与您使用的工具，体验是丰富的，或者架构是否良好等无关，而后者是实际开发过程中引入的复杂性。从通常的角度来看，基本的复杂性与必须解决业务的特定业务问题，因此在这里我称其为“业务复杂性”有更好的理解；任何开发方法或工具（包括解决任何开发方法或工具的解决方案），包括任何开发方法或工具（包括TheLow Code）的解决方案，偶尔的复杂性通常与技术细节密切相关在开发阶段，我也称其为“技术复杂性”；复杂性的这一部分正是低代码擅长的，并且适合解决方案。
阻止基础级别的技术细节，以便尽可能多地发展，减少不必要的技术复杂性，并支持它们更好地应对业务复杂性（满足灵活和普遍的商业场景的需求）。这应该是一个低代码开发平台。
在履行上述职责的同时，低代码开发平台作为开发人员的产品，还需要致力于为开发人员提供简单而直观的极端开发经验。除了这些背后的巨大工作量之外，还必须努力工作为了找到一个满足您产品定位需求和目标客户需求的平衡点，在“强”和“ Easy”的两个美丽的矛盾点中。这是一般 - 可使用的低代码开发平台面临的最大挑战。
专业代码 /自定义代码）
“纯代码”可能是我捏造的单词，更常见的是专业代码或自定义代码（自定义代码）;）开发模式。我之所以选择使用“纯代码”的原因是因为如果使用“专业代码”“专业代码”，看来低的代码不是专业的，“自定义代码”很容易使人误解低代码不能支持自定义代码无法支持的自定义定制代码。
当然，我认为更准确的标题是“高码”（与低代码相对应，但名称太不愉快，我不喜欢...），因为即使使用了传统的代码IDE，也可以使用某些开发工作（一些开发工作）（更合适的）可以在非代码中完成它，例如：SwiftUi接口设计器和服务器设计器和Server -side开发数据库使用时的PowerDesigner建模工具。在传统发展模型中。最后，通常是开发人员可以直接修改的代码。开发人员仍基于代码执行主要任务。
低代码和纯代码之间的关系实际上与视频和文章相似：
如果您根据上述比较关系得出，那么低代码将遵循与将来类似视频相似的开发轨迹，超过纯代码成为主流开发模型。Gartner的预测也表达了相同的观点：到2024年，65％在所有应用程序开发活动中，将以低代码完成。同时，有75％的大型企业将使用至少四个低代码开发工具进行应用程序开发。
但是以同样的方式，就像视频永远无法替换文章一样，低代码永远无法完全替换纯代码开发方法。将来，低代码和纯代码方法将以互补的形式共存很长时间，并且在随后的“低代码业务现场”一章中，每个方案都将详细列出哪些场景在此阶段，每个方案将在此阶段列出，每个方案将在其合适的业务场景中发光和加热。
零代码 /无代码
从分类的角度来看，应该有一个“零代码”（也称为“非代码”）“纯代码”。零代码是一个完全不需要编写代码的应用程序开发平台，但这确实如此这并不意味着零代码比低代码更为先进和先进。文本代码。选择背后的原因是，零代码开发平台期望尽可能减少应用程序开发阈值，以便每个人都可以成为开发人员（注意：：开发≠≠选择），包括业务分析师，不了解代码的用户操作，并且Vivit是产品经理（您不知道是否不知道该如何假装）。
即使是专业开发人员，在劳动力部门的趋势下（前端/后端 - 端/算法/sre/数据分析..），也很难招募一个可以开发和维护的完整堆栈工程师整个复杂应用程序独立。版本零代码可以改变所有这些：无论是Java和JavaScript不清楚的技术白色，还是精通深度学习，但没有时间学习Web开发算法Daniel，您都可以实现自己的技术梦想或者通过零代码。梦。“改变世界想法的想法比程序员更糟糕。”这个笑话可能真的成真。哦，不，即使是程序员，有想法的人也可以自己提高。
当然，所有选择都必须付款，零代码也不例外。完全放弃代码的成本是平台的能力和灵活性受到限制：
尽管零代码在狭窄的意义上与低代码有显着不同，但从广义上讲，零代码可以用作低代码的子集。在其相关调查报告中，Gartner将“无代码”分类为广泛的低代码应用程序平台“ LCAP”（低代码应用程序平台）和市场上的许多通用低代码开发平台也具有一定程度的零代码功能；例如，低代码字段中的Leader Mendix提供了一个简单易用的 - 使用零代码Web IDE -Mendix Studio，还包括功能强大的功能强大的低代码桌面IDE -Mendix Studio Pro。
HPAPAAS（PAAS）
如上所述，“低代码”一词由Forrester提供。作为Gartner，这也是一个著名的国际研究机构（又称某种能力），显然并不容易谴责这次新的歌词竞赛低代码字段的概念概念，因此他还发明了“ hpapaas”（hpapaas”（hpapaas“（hpapaas”（2017年的HPAPAAS”，2017年高生产率应用程序平台作为服务）听起来更高。
根据Gartner的定义，HPAPAAS是一个平台，支持语句，模型驱动设计和一个单击部署，可在云上提供快速的应用程序开发（RAD），部署和操作特征；这显然与低代码的定义完全相同，但是事实证明，名称太专业了，这可能不是一件好事。“ HPAPAAS”最终输给了更早，更扎实和更平滑的“低代码”：从2019年开始，“低音”一词（例如LCAP）开始完全使用@deprecated Mark的hpapaas“ hpapaas””。
图片来源：https：//blog.kintone.com/busines-with-hert/difference-saas-daas--apaas- apaas- hpapaas
值得补充的是，“ hpapaas”一词不是诞生的，而是从早些时候Gartner提出的“ APAA”继承的。在低代码实施开发平台外，APAA还包括一个传统的纯代码应用程序开发平台（高控制APAA，一种更可控的纯代码开发方法）。
这是不值得的，但我只想八卦。“ apaas”一词不是用稀薄的空气制成的，而是云计算的兴起更深。我相信，云中的每个人都猜测，云计算的概念（例如apaas/paaS/saaS）都与同样的静脉：APAA在PaaS和SaaS之间。它还提供了准备好的软件服务（更详细的说明可以涉及图片的来源）。
对于低代码，什么可能不是那么重要？毕竟，在信息爆炸的世界中，不乏新颖性和短暂的东西。大多数所谓的新技术只是花的闪光：出现并看到；大多数人“哦”，阅读，但表明他们不感兴趣。少数人惊叹于Itlater，我应该回去什么？它真的决定了新技术是否可以转变为新的生产力，而且从来都不是该技术本身的好和华丽，而是真的需要，也就是说，为什么需要低代码？如果您用不同的主题填写上述问题（冷知识：这称为“延迟主题的主题”），您可以更全面地看待此问题：
为什么“市场”需要低代码？
在这个叔叔和阿姨的“互联网+”和“数字化转型”时代，公司越来越需要公司通过应用程序（应用程序）改善信息的内部信息传输并加强与客户的联系。很长一段时间都没有出生，这也面临着供求关系之间的矛盾，类似于我国家的主要社会主义阶段：向后的软件开发生产力无法跟上人们不断增长的业务需求。
加特纳（Gartner）预测，到2021年，应用程序开发需求的市场增长将超过企业IT交付能力的能力的5倍。面对如此巨大的IT差距，如果没有革命性的“新生产力”系统，那么很难想象一下，它可以通过现有传统技术系统的延续而完全解决问题，而低编码技术则具有这样的任务。可以预期，通过以下方面，它将完全创新和发展生产力，储蓄几乎将进入世界深水：
提高成本降低和质量保证
尽管软件行业一直在高速发展，新的语言，框架和工具已经不断出现，作为从业人员，我们必须承认，软件开发仍处于手工艺品研讨会的阶段，低效率，高效率，高昂的人为成本和无法控制的质量。项目扩展交付已成为行业的规范，瓶颈几乎总是开发人员（可以通过机器解决的问题不是问题）；出色的发展人才总是很少的资源，而且昂贵。
相反，经过数百年的工业革命，大多数传统制造业已经摆脱了对“人”的强烈依赖：从原材料的投入到产品的产出，中间是稳定的支持各种精确仪器和自动化装配线。实现生产的标准化和规模。尽管信息化是人类的第三次工业革命，但软件行业的当前状况尚未达到成熟的“工业化”阶段。
因此，我亲爱的程序员的朋友，当您与前端的前端进行界面，以及产品的下午产品，然后整夜与您自己的虫子打架，终于进入Dreamland并成为一系列警报短信。当我醒来时，我抬头看着星空：“我有一个梦想……有一天，也可以在工业产品等批处理，稳定且高效的批处理中生产软件开发。”这种渴望正在慢慢成为现实。
是的，低代码是应用程序软件开发过程的工业化：每个低代码开发平台都是技术密集的应用程序工厂，所有项目都在同一生产线上紧密合作。该开发的主要开发不再是技术极客，熟悉一百种写作方法，但是一组想法，一个完整的应用程序制造商。与应用程序工厂中各种成熟的基础架构，现成的零件和自动化组装线路，开发人员只需要专注于核心业务价值。即使您遇到非标准需求，也可以随时自己执行，并使用最灵活的手动自定义（代码）来解决各种角落问题。
扩大应用程序开发劳动
通过允许仅通过简单的拖放完成大多数开发工作，低代码（包括零代码）大大降低了用户阈值，从而使企业能够充分利用前面提到的平民开发人员资源。代码还可以允许商业人员实现自助服务类型的交付，这不仅可以解决传统的IT交付模式下的任务积累问题（积压），并避免了大量稀缺的专业发展资源。简单和重复应用程序开发需求还可以使商业人员可以根据自己的想法真正实现该应用程序，并在其他人开发时摆脱不可避免的桎梏。
在这一点上，应用程序开发功能不再是一些专业开发人员的专利和特权，而所需技能的技能门槛和所有权将在未来变得越来越降低。真正实现的“技术民主化”将真正实现。
加强沟通和开发过程的协作
多方调查结果表明，软件项目失败的主要原因之一是缺乏通信。在传统的开发模型，业务，产品，设计，开发，测试和操作以及维护人员中，在领域中有自己的一组工具和语言。功能的交流变得困难和效率低下。这就是为什么当前流行的敏捷开发和DevOps强调沟通的原因（前者是协作Biz和Dev，而后者是协作的DEV和DEV和DEVOPS），经典的DDD场驱动的设计还提倡通过“统一语言”来减少业务和技术，以减少业务和技术，人员之间的交流是不一致的。
对于低代码，这种情况将从根本上得到改善：上述角色可以在相同的低代码开发平台（甚至同一个人）上进行紧密合作。这种新的协作模型不仅打破了功能的功能，而且还可以轻松地通过统一的视觉语言和单个应用程序表示（页面/数据/逻辑）来使对应用程序形式和项目进度的理解相结合，以实现更多最终的敏捷开发模型，并且进一步进一步分布[2]。
统一开发平台下的聚合效应
在低编码尝试将与应用程序开发有关的所有活动收敛到同一平台（一个平台）之后，它将产生更多的汇总效果和规模回报：
为什么“这个时代”需要低代码？
如果您知道市场上的各种低代码产品，那么不难发现该领域的许多参与者已经存在于低代码概念诞生之前，例如：低代码领域中的另一个巨大的Outsystems，这是建立的。早在2001年2001年。去年，Filemaker是低代码行业的领导者之一，也出生于1985年（正好35岁，这似乎很疯狂）。您以前不生气吗？从技术和业务的角度来看，可以将其汇总到以下原因中：
技术成熟度不足
各种核心技术（可视化，模型驱动器，RAD，BPMS ...）都有悠久的发展历史，而且似乎只是新的旧酒。但是，每个人都知道，任何技术都会遵循So -so -called the so -call of -call''炒作周期”。不可能跳过整个领域的开发，并在大规模上被采用并被大规模地进行生产。以模型驱动的技术为例，尽管已经存在系统的理论研究（例如MDA）十多年前的支持工具（例如EMF）在技术背景的背景下，由于能力不完整，太理想化的技术技术，高阈值的原因无法进入该行业的主流。
在这个时代，那些支持低代码的“旧”技术已经酿造和市场测试太久了，一些完美和互补的“新技术”（例如Yunyuan和Response Web）也在快速发展和快速发展，并且是时候到达成熟了，现在是时候通过包装和列出的“低代码”来为新的葡萄酒瓶提供，这为传统的IT市场带来了真正的香气之旅，迫切需要新的生产力。
商业收入并不明显
即使十多年前的低码技术已经足够成熟，它绝对不会在当年的应用程序开发市场中产生影响。为什么？由于技术服务于业务，当时对应用程序开发的需求是比现在要简单得多：没有当今的多渠道，多体验以及各种集成和定制需求，也不会奢侈地成为当今企业级别的标准弹性，分布和高可用性，并且缺乏缺乏IT业务场景缺乏快速变化，无法促进持续整合和快速交付。
尽管低代码可以完美地解决上述所有问题（例如，多端应用程序生成，云本地体系结构，API集成功能），但在年度市场和业务背景中，以及上面提到的技术不足，整体投资生产，整体投资生产将非常低，这不足以允许企业在大面积的大面积中采用低代码解决方案。
如今，在这个时代，公司几乎对新技术带来的功能和收入几乎“不好”。用户终端？android，iOS，h5，小程序都设定了。操作方面。操作方面吗？一般而言，我看计算机，但还记得为了在手机上进行调整。Server？shangyun，必须。什么是操作和维护？
如果您使用传统的开发模型，那么这样一组完整的工作时间和报价可能会吓到这群无辜而可爱的人作为产品经理；梦想，使用卷心菜（类似卷心菜）的价格实现白色粉末 - 类似于价值。如果Cheng Wei可以使用当前的低代码，DIDI应用程序的第一个版本不会被用来取消的外包（至少持续一段时间...）。
为什么“专业开发人员”还需要低代码？
尽管确实用于非专业开发人员的零代码，但它可以支持的业务方案确实受到限制。它不能真正创新传统的开发模式，取代仍然需要专业开发人员的复杂业务场景。狭义意义上的低代码有可能实现这一目标，因为它自然是针对专业开发人员量身定制的。Gartner的最新调查报告显示，“有66％的低代码开发平台用户是企业IT部门的专业开发人员。”这完全说明了专业开发人员需要的代码低于平民开发人员。
一批在屏幕前穿着格子衬衫的同学想问：“低代码不会编写太多代码。怎么能将其视为程序员？”尽管程序员讨厌重复自己，但重要的是说更多：开发：开发≠≠虽然虽然。10，000年前蹲在洞穴中的原始人被用小石头涂在古代图腾上。100年前坐在桌子上的徐齐莫（Zhimo）用笔写了一封信给林·惠林（Lin Huiyin）。我相信许多人今天躺在屏幕上，我相信曾经开始在手写板或iPad上写作。数千年来，人类使用的工具一直在不断发展，但是活动的本质并没有太大变化。小石头或鼠标，写作和绘画的本质是创造和表达。最终作品的质量不取决于您当时所持有的内容；同样，应用程序开发的本质是思想和逻辑，最终值的最终值。高度不确定您在实施时是否使用纯代码或低代码。
与纯代码相比，低代码可能会成为更好的下一代生产力：
减少不必要的工作量
视觉阻力和参数配置的极简主义开发模式，结合模型驱动的代码自动生成机制，可以消除大多数乏味和重复的样板代码；一个停滞的部署，操作和维护管理平台，无需通过您的SelySelffilm系列构建CI/CD，应用程序环境资源，配置监视警报；同时消除人工同步以维持具有多个功能的重复应用程序的一种结构，构建和发布多末端应用程序；等待，可以重新使用最大化软件。总的来说，低代码可以使专业开发人员更加专注关于创新，有价值和杰出的工作，而不是在上面的那些不必要的非商业核心工作上花费宝贵的发展时间。
强大的平台能力支持
尽管上述技术支持工作并未直接产生业务价值，但它将直接影响业务的绩效，成本，稳定，安全和可持续发展能力。看来的公司永远不会牺牲这些重要的指标来交换这些重要指标短期业务加速。低代码开发平台知道这一点。因此，尽管简化和阻止了基础技术细节，但它也将使您的封面一部分尽可能多（至少与纯代码开发方法一样好），包括但不限于但不限于IT
综合生态能力再利用
重用是提高软件开发效率和工程质量的最有效方法。在传统的代码开发模式下，开发人员可以通过提取公共类/功能，参考共享库，调用外部API服务，沉积代码片段和模板。该平台一个低代码世界还可以提供相应的多级和多维重用方法，例如页面组件库，逻辑功能库和应用程序模板库。
但更重要的是，低代码平台也可以为其集成的生态优势提供全面发挥，并提供强大而易于使用的能力（资产）的发现，集成和共享系统：以页面组件为例，您可以直接使用它直接使用它。系统组件还可以在平台附带的组件市场上搜索并引用更合适的组件。您还可以使用代码来开发自定义组件并将其发布到市场上。平台的生态系统越大，可重复使用的功能越多，并且应用程序的开发成本就越低。
相比之下，尽管传统法规世界的总体生态较大和深刻，这是由于各种技术的互操作性不足，缺乏统一的平台和市场以及高密码综合成本，但它并未形成与生态能力的重复使用，并与类似的规模电位。该系统导致重复轮子和低级别的重复结构的现象是司空见惯的，并且也称为“新基础设施”。
说到哪个，另一组学生包裹在杰珀的头上，这无济于事：“如果低密码确实发展，它不需要太多程序员？炸！”。它无法删除应用程序开发的核心：严格的业务逻辑，Ingenious算法设计，良好的工程风格等。即使他剥夺了他的编程语言和工具能力技巧的层次，他的剩下的就是仍然是有价值的铁杆开发人员。
当然，如果您坚持使用纯粹的编写代码改变世界，它将不会失业。或者可以选择那些暂时不适用的低代码的领域，例如基础系统驱动程序，3D游戏引擎，Rocket启动程序；或者，您也可以选择在低代码中编写必不可少的自定义代码扩展。为民用开发人员提供高质量的构建块。在本文中，您还可以选择在低代码平台本身的底部代码中添加砖块。”到邮箱：pengqun.pq@alibaba-inc.com。
为什么“我不”需要低代码
即使每个人都同意以上“为什么使用低代码”原因，但仍然有一些人不时测试水测试并给您“为什么我不需要低代码”。练习真相是正确的，大多数问题都在背后；但是我认为，更多的可能是主观的或无意识的BIA。这里列出了一些关于低代码和我的个人意见的共同疑问，并希望帮助每个人看到一个更全面和客观的低码。
问题1：低代码平台不容易使用
“我尝试了一些如此称呼的低代码开发平台，即能力较弱或经验差，只能开发一些玩具应用程序。”
作为一个深入的体验用户，已经调查了国内外各种低代码产品，我的意思是：不能全面。低代码也是热点；但是它们不能代表当前的行业层面和低代码的发展方向。市场上真正成熟的企业级别的低码开发平台完全能够满足有效开发方法中最复杂方案的功能需求，以及- 功能需求，例如安全性，性能，缩放率可能是企业级别应用所需的缩放。这个外国市场已得到充分验证（否则将不会像这样交换它们）。
当然，国内市场仍处于混合混战阶段。遇到真正的龙的可能性非常低，但是不可避免地会遇到金鱼，甚至木材。随着时间的流逝，具有真实力量和言语的产品 - 嘴可以脱颖而出，向所有人展示了所有人应该低的东西。
问题2：低发和低发展是无法控制的
“平台上的各种可见组件，逻辑动作和部署环境是黑匣子。
作为一名程序员，他也不知道不舒服的天空的基本原则，我更喜欢相信问题只是暂时的。尽管这确实是一个痛点，目前无法使用低代码平台，但它不属于低代码技术本身的固有缺陷。在计算机字段中有一个著名的说法：可以通过添加间接中间层来解决任何问题。低代码思维的正确性是正确的：一年和当前的云平台，他们都希望通过建立黑盒中间抽象来减少开发人员的工作量和心理负担。
当然，所有其他中层层都不是完全免费的，低代码也不例外。作为一个尚未成熟且稳定的新中间层，低代码将不可避免地发生各种问题，使用户感到损失，就像操作系统内核虫和今天的云主机I/O Ha ha ha ha ha ha ha ha ha.st。但历史法也告诉我们，所有伟大的技术最终都将成熟。只要低代码领域发展健康，问题总是越来越少，最终落在大多数人无法感知的范围内。今天的新用户不知道用户；今天，低代码开发人员遇到的“蓝色稀薄”问题最终将成为被遗忘的历史（他没有黑人历史）。
问题3：难以维护的低编码应用程序
“一旦应用程序复杂，将使用自定义代码插入各种复杂的逻辑流。
作为具有深厚软件维护意识的无脑部传教士（请参阅“火灾社会！必须检查和系统优化手册”），我必须说：以低代码开发，也谈论基本法律。无论使用低码开发还是纯代码开发，低维护的根本原因通常都可以在开发工具中，但是开发人员不遵循软件开发的通用原理，例如工程规范性的标准化，例如工程规范性，命名，干燥/亲吻/坚实原则等。
良好的低代码平台将永远不会阻碍开发人员改善应用程序的维护；相反，它还将提供指导和帮助。举例说明Mendix除了支持基本的模型分析和重建（例如无用的模型，对象重命名，亚逻辑流动提取）外，它甚至提供了ISO/IEC 25010标准应用质量监控（AQM）功能。另一方面，一个客观的原因使其难以维护的是应用程序本身过于复杂，低代码被用作高度抽象和自动化的开发模型，这是降低应用程序复杂性的专业人士。
两者合计，尽管低代码不是可以解决所有问题的银炸弹，但这不是炸弹带来更多问题：改善应用程序维护的上限必须高于传统开发模型；维护仍然是开发人员本人。
回答质疑的最佳方法是做自己并与实际绩效交谈。对于一个行业，判断其当前的绩效是否良好，或者将来是否有更好的潜力，可以从以下三个方面衡量：市场规模（是否足够大），适用的场景（是否可以降落在地面上（是否可以降落在地面上），竞争产品的状态（您是否已得到验证）？
市场规模
“谈话很便宜，向我展示代码钱。”
- Linus Starcraft
这篇文章可以被愚弄，但市场不会撒谎：
总而言之，有两点：
适用的场景
从理论上讲，低代码是一个完全针对传统纯代码的一般开发模型，应该能够支持所有可能的业务场景。但理论只是理论。河流和湖泊的低代码统一的梦想尚未进入现实，不可能完全替换现实。如前所述，低代码和纯代码的方法是互补的关系。将来，它也将在合适的业务情况下长期共存，发烧和发烧。同时，还必须指出，当前的低代码技术，产品和市场尚未成熟，尚未成熟因此，其中一些可能适合开发低代码的开发。目前，它只能用纯代码代替。
在2019年的低编码调查报告中，Gartner绘制了一个“应用金字塔”来解释低编码适用场景的应用：
概述
尽管低规模的代码是一个新兴的概念，但该行业本身并不是很新（前面提到），并且近年来已经积累了许多高级荣耀国王。在同一时间，低代码，作为一个上升的行业和资本热点，近年来，加入这个令人兴奋的战场。
上图是Gartner给出的低代码平台魔术象限，而Forrester给出的低代码平台技术频谱可以从图中看到：
本文总结了低代码字段中的基本概念，核心价值观和行业现状。尽管这些内容是相对基本的和部分理论，但我总是认为，深入理解的先决条件恰恰是这些事情，这些事物是勤奋的 - 技术 -体系结构只会告诉您如何实现该系统（如何），并且无法准确表达它。可以使用什么以及为什么要做这样的事情；以下两个问题的答案是所有设计和后续系统的演变的根本原因和驱动力。
作者：阿里巴巴Yunyun的本地应用R＆D平台Emas Peng Qun（Chu Heng）