低代码内容分享(三)：低代码为什么没前途

最新推荐文章于 2024-11-03 04:08:48 发布

之乎者也·

最新推荐文章于 2024-11-03 04:08:48 发布

阅读量940

点赞数 16

分类专栏：低代码内容分享文章标签：低代码

本文链接：https://blog.csdn.net/qq_45038038/article/details/136029726

版权

低代码内容分享专栏收录该内容

10 篇文章 3 订阅

订阅专栏

现代管理学之父德鲁克，提及创新本质时，说了两点：一是让昂贵的东西变得便宜，老百姓能用；二是让高门槛东西变得低门槛，普通人可用。乍一看，低代码挺符合这两条的。

试想一下，如果有这样一个神奇的工具，能让产品经理根据需求在4小时内就“拖拽”出了一个产品给到客户，那将会是怎样一个场景。

低代码：让人找不到工作？

可如果放到一年前，低代码这个“用户故事”的画风是这样的：

一个传统行业老板整来一套低代码开发平台，让某位产品经理在上面填上数据库字段。接着画bpmn（业务流程管理）流程图，拖拽前端组件，一个系统就成了，全程不用写代码。最后一周撸出一个项目来，能赚一百万左右。

工程师们见状纷纷准备跑路了，看样子只招实施就行。走之前还不忘来一句：低代码，yyds！

低代码当时被吹嘘得很膨胀：解放开发者的生产力，就靠它了！

然而，经历一年多的发展期，低代码给许多人带来的却是无数个打脸瞬间!从基层的“低代码”开发工程师，到系统设计的架构师，彻底沦为了一场“吐槽大会”。

产品经理：我到底在做产品，还是做工具？
架构师：本质这玩意是一锤子买卖，本身无法应对需求变化！这系统根本没法扩展！
开发工程师：简单的工具还行，遇到复杂的，需要扩展的就傻眼了。
低代码工程师：天天用些低代码封装的东西，更像混吃等死，没提升！

是大家对低代码期待过高了吗，还是低代码本身就是个“伪需求”？

伪需求还是真需求？

真正的需求才是产品持续发展的动力，那么低代码的“真需求”在哪里呢，去年Gartner公布了一项低代码的用例调查，排名靠前的是：表单和数据收集应用程序，在应用程序中协调业务流程和工作流的应用程序，取代纸张、电子邮件或电子表格的应用程序，为当前本地应用程序定制新的应用程序UI。

视线拉回国内，不难发现，低代码现如今的应用场景不外乎几个方面：

首先，在数字化转型场景中，低代码在B端用户中的声量较高。这个工具似乎成为解决他们“最后一公里”问题必不可少的一个选项。传统行业进行数字化，往往缺乏技术人员的储备，同时系统和设备也封闭陈旧，比如奶茶店、服装店，让他们专门招研发团队来搞数字化，一则招不到人，二则即便招来了也大材小用。低代码就不一样了，拖拖拽拽，就能快速搞定一个case，老板们当然会点赞了。

其次，对于初创企业，人员和规模并不大，想要快速使公司运转，就必须快速搭建出CRM、OA、项目管理、进销存等系统，而这些系统看起来已经很成熟，但要找到足够的技术人员来快速交付，难度很大。这时候低代码的用武之地就来了，只需要找到熟悉业务的非技术人员，经过培训就能快速搭建出企业所需要定制的应用。

最后，对于大中型互联网企业而言，同样也有低代码发挥的地方。这也是部分开发者最为担心的地方：低代码抢走了原本属于自己的需求。其实，就现状来看，真大可不必。

众所周知，需求在产品经理有重要和紧急之分，现在来看交给低代码来实现的，往往是那些“紧急且不重要”、甚至“不重要不紧急”的需求，为什么还需要交给研发来排期呢？交给低代码工具不就好了么？

再者，低代码对于开发复杂系统而言，难登大雅之堂。一来内部是个黑盒子，仅扩展就成问题，二来低代码的颗粒度远没有高到可以让CTO们大笔一挥，架构图里哪个系统要用低代码来实现，因为稳定性不能保证。

因此，专业的事情交给专业的工具办，低代码不是来抢活的，而是给技术人腾出时间和精力对付更具创新力的事情。

低代码只是开发者的可选项

在软工圣经《人月神话》一书中，作者Brooks指出了软件发展的一个僵局：在落后的项目中增加人手，只会使进度更加落后。

为了更快完成项目，开发团队会发展的极其庞大，以致于所有的时间都花费在沟通和变更决策上，反而让项目结束变得遥遥无期。

那么低代码会不会成为打破这一僵局的工具呢？当然是。

如果说在业务需求层面上沟通难以达成一致，那就交给甲方爸爸来自己搭建吧。

把相关的代码模块化封装之后，甩给真实业务场景中人员自己来拼装应用，既达到了快速响应业务需求、适应变化的目的，同时给业务人员更大的自由度，省去与开发人员的沟通时间，同时让应用更贴近场景。

所以，同样一个“人月”，专业的开发工程师和低代码搭建工程师所发挥的作用是大有不同的。

其次，开发人员也需要低代码工具来持续创新。

的确，专业的开发人员，技能非常强大。但它们也很稀少。如果公司想继续提高效率，低代码工具是必须的。

专业开发人员面临的环境往往是这样的：碎片化的数据和流程，积压许久的遗留系统，臃肿的工作环境，他们无法利用新兴技术去保持敏捷，同时还能保证无风险。

利用单一云基础的低代码工具可以使开发人员能够加快他们交付的创新步伐。

此外，低代码使开发者甚至没有技术技能的人更容易进行软件开发。而且由于低代码开发平台的存在，会使专业开发人员和非开发人员之间的协作成为“融合团队”。

目前这方面做的不错的是国外的低代码独角兽Mendix，专门面向专业的开发者做低代码工具。

低代码：带有欺骗性的神话？

Brooks曾用很戏谑的笔触描述道：用“人月”来衡量一项工作的规模，是一个危险和带有欺骗性的神话。

同样地，用“代码多少”来衡量一项工具的作用，也是一个带有欺骗性的神话。

匠人都是以工具出名的。低代码的火热，势必也会造就一批低代码大牛。但这并不代表低代码的价值亚于专业开发。

低代码能否受欢迎取决于市场上各位干系者的接受度。

目前市场的反馈就是：老板们看了必须上，使用者试了试不想用。

就以国内为例，11月份，不少巨头纷纷秀起了低代码的肌肉：

11月3日，阿里云云栖大会上，阿里巴巴集团副总裁、钉钉总裁叶军宣布：钉钉上的低代码应用数已经突破500万，低代码开发者数量超过380万。
11月13日，腾讯升级了“微搭”，目前已服务开发者数300万，新增小程序使用率70%；
11月18日，华为AppCube全线产品全面升级，侧重在低代码、零代码、数据看板三个方面进行了升级优化。

数字背后可以看到，虽然饱受争议，但低代码的使用者的确在猛涨。

低代码怎样干有前途

低代码平台的用户反馈并不那么乐观，正如文章开头所描述的不同岗位的使用感受那样：意见很大。低代码这个“盲盒”拆的好，是高效，拆的不好那就是不能用。

根据TechRepublic的一项调查，受访者希望低代码平台能够提高生产力（15%）、缩短应用程序开发时间（14%）和自动化手动流程（12%）。技术和非技术团队可以通过实施以下一些建议，共同努力实现这些期望。这里给一些使用建议。

创建一组平民开发者

我们将平台开发者视为不以coding为生的人：产品经理、流程专家、商业分析师、设计师和MBA项目毕业生等等。这些都是来自不同背景的聪明人，他们有着不同的视角来解决问题并找到解决方案。此外，这些人也是熟悉业务的人，他们与解决方案有紧密的联系。

因为非技术性的队友可能是开发生态系统的新手，他们需要接受培训，以了解各种可能性以及如何最好地实施他们的最新想法。通过学习，没有经验的建设者可以获得了进入一个新领域的信心。

所以，公司需要为采用低代码解决方案制定明确的激励措施。这意味着要清楚低代码的好处和结果。为什么要鼓励平民开发者不断学习和尝试新工具？哪些潜在的结果会让工作中的生活变得更好？

此外，还需要提高整个公司对低代码所带来的的潜在机会的认识。老板必须确保向员工提供学习和开发资源，从而为进一步提升解决问题的能力敞开大门。

关注具有战略意义的关键低代码项目

许多业务团队通常被激励参加低代码项目。他们希望提供新的产品和解决方案，并更快地将想法推向市场，又或者是需要为客户创造更强大、更紧密、更定制化的体验。他们感到痛苦的是，在手动重复输入相同的信息和其他低效的模拟活动上浪费太多时间。

实际情况中，许多低代码工程师都是业务方面的熟手，并且愿意学习可视化编程，可以为他们的日常工作创建简单的用例。

在开始时，这些用户还没有考虑到自动化或应用程序开发的确切用例。为了找到想法，他们可以探索日常业务活动中的已知痛点和特定行业的需求，也可以从预先构建的内容市场开始，看看一些常用的解决方案。一旦他们有了一个想法列表，就应该有一个基于预测的业务影响的战略优先级排序过程。

业务用户开始的另一种方式是参与概念验证（POC）原型开发项目，以转换更复杂的流程或活动，该流程或活动已经被IT部门分配了高度的战略优先级。POC原型是业务用户（如设计师）与开发人员同事或项目团队分享其最终产品愿景以验证需求的绝佳方式。

日常问题和请求是低代码解决方案的最佳选择。业务人员应该被授权构建所需的扩展和应用程序。在IT资源和专业开发人员短缺的情况下，低代码工具可以让任何人改进自己的工作流程和自动化手动工作，并在生产解决业务问题的工作原型时最大限度地提高速度、灵活性和创新性。

通过低代码学习资源适应新角色

虽然低代码工具比编程语言更容易访问，但在开始之前需要学习，特别是对于刚接触软件开发的业务用户，否则构建的第一个自动化和应用程序将是草率的、不可扩展的，甚至会产生IT风险。

低代码课程为缺乏经验的用户打开了一扇大门，让他们在进入之前获得基本的理解。它们涵盖了概念性的事情，如：识别用例以及如何确定从哪里开始的优先级，包括对软件结构、设计和逻辑流程的深入了解，以及在构建工作开始之前对用户体验的规划。当然，在构建简单的培训案例时，对能力进行全面的实际审查，确保通过实践经验获得产品知识。

因此，对低代码技术感兴趣的个人越来越多地利用学习工具和课程。这些学习计划也会扩大低代码工具的使用范围。