于是小C向CTO“求救”，经过一番调研，引入了低代码，随后“奇迹”发生了，他们只用了5%的人就搞定了60%的零散需求。在崩溃边缘的小C，终于“得救”了。

　　小C的故事再次引发了我对低代码的关注。近几年来，低代码迅速崛起，成为企业数字化建设不可或缺的工具。但是，对于低代码的态度也呈现出两极分化的态势，拥护者说它无所不能，反对者骂它是“行业毒瘤”。

　　K哥作为国内较早一批关注低代码的自媒体人，写过十几篇低代码方面的文章。在今天这个属于程序员的特殊日子里，我想再深入聊一聊低代码。

　　低代码，究竟有啥用？

　　先来看一个案例：

　　我的一位朋友L总，是某知名零售集团CTO，最近有一件事情让他很头疼。集团新成立了一个“新渠道零售部”，专门针对新媒体、私域拓展销售渠道。

　　按照惯例，这种八字还没一撇的业务部门，L总作为CTO是不会投入开发资源去支持他们的，而是等他们的业务探索完成后，才进行系统建设，把成熟的业务模式进行系统化。

　　但是，“新渠道零售部”的总经理非常强势，跑去找董事长说，如果不建设系统，业务无法正常开展，他就不干这个总经理了。于是压力转嫁到了L总头上。

　　这时，L总想起了低代码，通过低代码快速搭建可供业务部门试错的系统，既快速交付，又降低了IT投入成本，一举两得。

　　于是，L总团队只用了两周就上线了CRM、客服系统、运营平台系统。要是用传统的软件研发模式，没有三个月是不可能完成的。

　　通过这个案例，我们对低代码能够做什么，有了比较直观的了解。简单来说，低代码能够帮助企业快速实现IT系统的研发，低成本地支持企业快速创新和试错，提升企业业务敏捷的能力。

　　低代码的核心价值

　　实际上，低代码给企业带来的价值远不止这些。K哥本身是大厂技术高管，在我看来低代码具备两大核心价值：促进IT与业务融合、提高应用开发效率。这样讲比较抽象，下面我结合一些案例来说明。

　　1）促进IT与业务融合

　　所谓IT与业务的融合，实际上就是让IT走进业务，业务融入IT，业务与IT之间无缝连接。

　　在日常工作当中，业务和开发的协作有缝隙，需求沟通速度慢、需求理解容易有偏差。常常会出现业务和开发都不明白对方在讲什么，仿佛是来自两个世界的人。这种现象叫“知识的诅咒”，即一个人了解了某种知识，就很难站在没掌握这个知识的角度，去思考和理解他人。

　　那么，如何打破“知识的诅咒”，让业务和开发更愉快地“玩耍”呢？解决的办法很简单，就是让他们掌握同一种“语言”，低代码就是一个很好的解决方案。

　　K哥在研究国内低代码市场时，发现了一款名为奥哲·云枢的低代码产品，其由国内企业数字化服务商奥哲所研发。据相关报道，该产品已经被不少企业所接纳，其服务版图不乏中石油、中石化、中国航天、华泰证券、西子联合、宝马等顶尖的大型企业。

　　在研究这款产品时，K哥发现这是国内首款以领域模型为驱动的低代码产品，其拥有可视化建模能力，能让缝隙合拢，即让业务和开发讲同一种语言。

　　使用低代码的软件研发过程是这样的：业务人员和产品经理先梳理业务需求，产品经理和开发人员在平台上以可视化的方式构建领域模型、模型间关系、领域服务及领域规则，高度地概括业务的底层逻辑。后续的开发及迭代的过程中，产品经理、开发都基于领域模型进行业务沟通，整个过程也就环环相扣。

　　相较于传统开发模式，低代码让开发人员提前介入业务，不仅知道How和What，还知道了Why。开发人员能对业务问题进行深度思考，从“被动接受需求的码农”，逐渐转变成为“最懂业务的技术专家”，开发出来的软件也就更符合真实业务场景。

　　另一方面，业务人员通过低代码平台，以“拖拉拽”的方式就可以独立完成简单应用搭建，小的修改就不需要再去麻烦技术人员。减少了零碎需求，开发人员得以更专注于核心业务系统的架构构建和开发工作，发挥出更大的价值。

　　2）提高应用开发效率

　　对软件开发有一些了解的朋友都知道，学习任何一门开发语言都是有一定门槛的。

　　然而，低代码降低了这个门槛，通过对开发全过程的可视化，从纯编码的模式转变为“拖拉拽”相结合的模式，降低了整个软件开发的难度，也降低了学习和维护成本。

　　衡量软件研发成熟度，有一个非常重要的指标：代码复用性。简单来说，就是功能代码是否进行了封装，是否能够进行共享和复用。

　　奥哲·云枢通过组件的方式对功能代码进行了封装。平台上目前拥有UI组件、列表组件、个性化流程组件等通用组件，以及支持业务场景的组件，如：支付服务、天眼查集成、电子签章、SAP集成等等。

　　此外，企业可以将自行开发的组件及模版上传至私有市场，做到团队IT资产的沉淀及复用，彻底解决重复造轮子的问题，从而提高团队整体的开发效率。

　　也许你会问，那测试怎么办？该平台采用Sandbox架构，能让用户以标准化的方式构建测试环境，对数据进行脱敏处理。

　　有了测试环境，接下来就是执行测试用例了。该平台还提供了测试自动化方面的支持，这能高度释放测试人员的精力，让他们专注于理解业务，设计出更完善的测试用例，而脏活累活则交给平台。

　　低代码不仅能够提升开发、测试人员的工作效率，还可以帮助运维人员提高产能。

　　它实现了数据化运维，如：应用依赖管理、应用全链路监测和分析、应用异常监控告警。想象一下这个场景，有了低代码平台，你可以喝着咖啡做运维，一切尽在掌控之中。

　　以上我们聊了低代码对产品、开发、测试、运维人员的赋能，接下来聊聊：低代码如何帮助系统架构师更好地工作？它能否实现前后端分离、后台业务逻辑的抽象和服务化？

　　随着低代码平台的日益成熟，这个问题也已经解决了。低代码能够统一技术标准和开发规范，构建统一的研发体系，大大减少研发内部的协同成本。对于拥有外包IT团队的公司，这点尤其重要。

　　不仅如此，K哥发现奥哲·云枢还可以做到集中维护业务逻辑，进而解决技术债的问题。

　　我们以构建一套复杂供应链系统为例：系统页面可能有几十上百个，但是页面仅负责界面展示和交互，不涉及业务逻辑。业务逻辑都封装在领域模型中，这种分层架构、领域建模的方式在架构设计上是非常优雅的。

　　这款低代码产品能够在软件架构上做到这个程度，是超出我的预期的。我也非常欣慰地看到这两年国内低代码领域的技术进步。

　　结束语

　　以上我们聊了低代码的作用，以及低代码本身具备的两大核心价值。就像上文提到的程序员小C的故事，低代码极大释放了程序员的生产力，也赋予了业务方参与业务系统开发的能力，并帮助企业构建敏捷业务能力。

　　K哥相信，低代码将逐渐成为像L总这样的企业CTO/CIO们，赋能业务方的最佳手段。通过低代码快速构建应用，能支持业务方不断创新、低成本试错，最终实现技术深度融合业务，为企业带来价值增量。（来源：技术领导力）

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。