软件工程师如何抵御低代码的冲击

软件工程师如何抵御低代码的冲击

在我年轻的时候，我的一个好朋友的叔叔被一辆派对巴士撞死了。在他的葬礼上，人们在悲伤之余不禁在想：他怎么不在看见那辆巴士或听见声音的时候躲开呢？同样，当我听说程序员因为低代码软件而丢掉工作的时候，我的脑子里也蹦出了类似的疑问。显然，他们也应该躲开低代码软件这辆派对巴士啊！

我朋友的叔叔躲不开，因为他身处夹点，无处可躲。这篇文章将介绍程序员会遇到的低代码夹点以及如何躲开它们。

1、场景设定

我们继续用派对巴士这个比喻，并假设你是一家大中型企业的软件开发人员。你和你的团队负责构建、部署和维护公司使用的各种应用程序。有些应用程序是你们自己开发的，有些是现成的，需要定制或集成。

突然间，你发现有很多用户在开发自己的低代码应用程序。你应该担心这个吗？我觉得大可不必。

2、大型企业里的夹点并不多

从 2010 年开始，随着流程自动化工具 Blue Prism 和 UIPath 的崛起，你或许已经看到自动化给金融和人力资源领域的工作人员带来的戏剧性影响。这是因为这些领域存在很多夹点。当应付账款业务被自动化，从事该业务的工作人员很难再转到其他岗位，因为整个相关的工作岗位都消息了。

但软件工程与应付账款不同。你的工作量是由软件能够给企业带来多少价值决定的。你可以看一下自己目前的工作内容。如果你所在的团队与其他大部分 IT 团队一样，那么应该会有很多开发新应用程序的需求以及给已有应用程序添加新功能的需求。如果说自动化可以让这些需求减少，那等同于说速度更快的汽车可以把你载到火星上。如果低代码软件承担了你的部分工作，你还有其他项目可以做。如果处理得当，你甚至可以把一些棘手的项目丢给低代码。

自动化的引入可能会深化而不是减少软件工程师的工作。——Ralph Aboujaoude Diaz， HFS Research

其次，软件工程的某些方面比较难以自动化，所以低代码派对巴士很难开过这个地形。

例如，非开发人员可以使用低代码工具做出数据表，但如何让这些数据表跟他们要解决的业务问题映射起来，这些工具并不会提供太多帮助。

低代码工具也让非开发人员构建和部署应用程序变得更容易，但这些工具并不会确保相关人员会参与项目的各个部分，以遵循风险和合规规约。

随着低代码在你的企业当中传播开来，作为软件工程师，你花在写代码上的时间变少了，花在工作其他方面的时间变多了，而不是失业。

对于大部分软件工程师来说，随着低代码软件在企业内部的铺开，他们将有更多的机会为公司创造更多的价值，不需要做那些无聊的重复性工作。——Jan Oberhauser，n8n CEO

3、撇开比喻，我们说的是哪种类型的项目？

低代码软件可以被用在很多种不同的项目中，从流程自动化到帮助用户提升效率的应用程序。在你阅读这篇文章的同时，想象以下的某个场景：

一款房地产经纪人用来向客户发送合同日期提醒的应用程序；

一款读取医疗记录并识别没有得到优先治疗的病人的后台应用程序；

一款通过抽取保单相关字段来构建机器学习模型的应用程序。

4、“解剖”一个软件项目

有很多书教我们如何构建企业级软件项目（可以阅读 Blair Reeves 的《构建企业级软件》）。为了契合本文的主题，我们把一个软件项目分为四个阶段：

计划和整体设计；

构建；

部署；

维护。

为了帮助大家更好地理解低代码软件是如何影响大家的工作的，我们来看一下低代码在上述的每一个阶段都具备哪些能力。

1. 计划和整体设计阶段

在这四个阶段当中，这是低代码最后一个可以取代的阶段。计划和整体设计阶段涉及很多事情，从让相关人员参与其中，确保有足够的预算和资源来构建和维护应用程序，到检查是否在构建对的应用程序。例如，假设你在一家房产公司工作，这家公司的客户抱怨要很长时间才能拿到合同文本。解决这个问题有很多种方法，但使用哪种方法取决于对造成这种延迟的原因的了解程度以及掌握了哪些降低延迟的方法。短期来看，低代码工具还无法做出这种分析。

2. 构建阶段

这是低代码软件可以发挥核心作用的阶段。在进行整体设计之后，你的团队或业务用户就可以用低代码软件很快地做出应用程序。在这个阶段，低代码软件的关键优势是它们可以帮助你的用户决定什么才是他们真正需要的。他们不用画草稿和沟通需求细节，而是不断迭代解决方案，直到获得他们想要的东西。

低代码的一个关键点是它抽离了基础设施的复杂性，就连非专业人员也可以构建和部署非常复杂的应用程序。——Rick Lamers， Orchest CEO

这个阶段仍然还有一些地方需要团队的参与——那些低代码解决方案无法处理的棘手问题。例如，如何抽取房产客户联系人的相关数据？如何在没有标准访问接口的情况下访问某些政府的数据集？如何构建可以基于风险对索赔进行分类的机器学习模型？如果说你们不具备这方面的专业知识，一些新兴的公司，如 Managed Functions，可以处理这些问题。

3. 部署阶段

低代码在这个阶段最为狂野。各种低代码平台都提供了不同的部署方式。

RPA（机器人流程自动化）公司提供了统一控制中心，负责处理应用程序的部署和维护任务。这解决了部署和维护问题，但代价是你的团队需要使用各种不同的工具来部署和维护低代码应用程序。

微软构建了两种类型的低代码应用程序。一种是带有图形界面，给业务用户用，一种是基于代码的，给开发人员用。开发人员可以使用现成的工作流来部署应用程序。

AWS 和谷歌还没有确定该如何解决这个问题。

还有成百上千的低代码应用程序提供了各种不同的解决办法。

结果是，你的团队需要制定指南，告诉人们要如何处理这些事情以及由谁来处理。我之前的系列文章中已经提到过这些。有了指南之后，低代码平台有助于大家遵循指南——但这是 IT 的责任，而不是业务人员的。

4. 维护阶段

这个是最为蹊跷的一个阶段。软件的维护涉及问题修复和功能增强。大部分企业没有设立专门的业务团队来处理这个问题，但他们需要参与，因为是他们自己构建了这些应用程序，他们是唯一知道这些应用程序来龙去脉的人。

随着时间的推移，低代码可以更好地处理这个阶段的问题，但仍然需要软件工程师和业务人员的共同参与。

5、要避免的夹点

如果你是大中型企业的软件工程师，并且与业务人员沟通顺畅，那么久不需要有太多的担心。你总是能找到为公司创造价值的方法。

但是，低代码仍然会给两个领域的软件工程师造成较大的影响，如果你在这两个领域中，就需要注意一下发展趋势：

小型公司（或者大公司的小型技术团队）；

应用程序开发公司。

对于小型公司来说，使用低代码软件比自己开发应用程序更说得过去。对于小型公司的 CEO 来说，他或她需要决定的是要雇一个 React 程序员来开发一个新的定制化应用程序（然后期望这个程序员不要离职、退休或死掉）还是使用低代码软件来开发一个。很显然，会选择后一个选项。在这些公司工作的软件工程师会丢掉他们的饭碗，或者转去为公司开发低代码应用程序。

应用程序开发公司的大量岗位将会消失。在这些公司，初级和中级开发人员很少有机会能够像公司直招的工程师那样发挥他们的沟通技能。如果你是一个负责写代码和构建 ETL 管道的初级或中级工程师，看一下你的周围，如果你的周围有很多同事做着同样的事情，那么是时候考虑一下该如何增强你的沟通和面对客户的技能了。

6、结论

技术变革在缓慢地发生，然后薄积厚发。我们似乎正处在低代码革命的转折点。在接下来的几年，我们将看到软件工程师的工作发生戏剧性的变化。如果你避开了这些夹点，对于你来说就是好日子。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。