「技术趋势」软件开发人员应该了解的2022年技术趋势（软件开发领域最新技术）-ag凯发k8国际

forrester对2022年的软件开发做了5个预测。bill detwiler与软件行业资深副总裁兼首席分析师jeffrey hammond(该报告的主要作者)讨论了开发者和it领导者在2022年应该做些什么。

软件开发处于不断变化的状态。低代码和无代码平台正在将一些开发过程转移给非程序员。人工智能正在改变我们测试自己编写的软件的方式。covid-19大流行迫使开发团队重新考虑在每个人都在远程的情况下如何工作。

forrester刚刚发布了软件开发的5个2022年预测，我们有机会与jeffrey hammond进行了交谈，他是forrester的副总裁和服务于应用开发领导者的首席分析师，也是techrepublic动态开发者播客上报告的主要作者。hammond也是一名前开发人员和开发团队经理，在软件行业有超过25年的经验。以下是为便于阅读而编辑的采访实录。

杰弗瑞•哈蒙德,forrester

jeffrey hammond，副总裁和主要分析师，服务于forrester的软件开发领导者

图片:福雷斯特

比尔:好吧。杰弗里，你是弗雷斯特刚刚发布的一系列预测的作者和首席分析师，这些预测是关于2022年软件开发的预测。我知道我们会讲到低编码和无编码。但在此之前，请告诉我forrester是如何整合这些预测的，以及你是如何在这份报告中得出结论的?

杰弗里·哈蒙德:是的。我认为第一作者指的是《猫的牧人》，因为我们的团队聚在一起，大约有八个人，我们进入一个隐喻性的泥坑，在那里我们都有自己的观点。想象一下，8位有着强烈观点的分析师。这几乎就像是说这是架构师的观点。这就是我们要讨论的。

所以我们要决一死战。我们会说，“我看到了这个，我认为它明年会成为一个大事件。”最近退休的约翰·赖默说:“我看到了，我认为它会很火。”

现在的挑战是我们只能选出前五名。如果你有7到8个分析师，那就小于1个分析师。所以，我们把这些东西放在一起，我们真的对它们进行了研究，然后我们想出了我们认为真的会在明年产生重大影响的东西。

这个特别有趣，因为对于这些预测有一些相当强烈的观点。我不确定我们是否100%都在同一页上，但这就是为什么这个练习在我看来是非常有价值的。

bill detwiler:那么当你有这些相互矛盾的想法时，你是如何决定应该采用哪种预测的呢?也许你会，我是说，你不会在拳击场上决斗。还是像最高法院一样，有不同的法官投票?你如何达成共识，或者至少选择一个赢家?

杰弗里·哈蒙德:是的。也许这就相当于来回地发布简报。我给你们举个例子。因此，我们提出的一个预测是，至少有三分之一的测试专业人员将使用机器学习，使测试自动化更智能的明年。在那个世界里有一个更大的话题。对话围绕着人工智能将在未来发展中扮演的角色展开。

现在，有些人基本上会说，“你知道吗?5年后，我们将有人工智能编写代码，这将大大减少对开发人员的需求，因为我们今天编写的很多基础设施代码都是可以由机器自动编写的。”

我们中有些人会说:“你知道吗?这样做的结果是开发人员必须维护更多的软件。”然后，“是的，我们真的看不到对优秀开发者的需求在短期内崩溃。”

所以你把这两个极端放在一起，你就会有一个非常有力的讨论。你所要做的就是回到研究中去，看看数据然后说，“我们看到了什么?客户在做什么?供应商告诉我们的即将到来的事情是什么?”

然后你就会发现，“人工智能会让开发人员被淘汰，而人工智能永远不会让开发人员被淘汰。人工智能真正开始产生影响的领域之一是测试。”

很多开发人员并不特别喜欢走出去编写自动化测试用例的想法。他们不想把时间花在这些事情上。他们想要构建业务功能，他们想要解决问题。他们想要驱动商业价值。

但你知道吗?必须编写这些测试用例。因此，这是一个很好的例子，在这个领域中，开发人员希望机器能做更多的事情，机器能够做更多的事情，我们可以看到工具和技术的证据，它们可以做更多的事情。

你把这些放在一起，然后说，“好吧，如果我们推断这个趋势，我们看到的只是增长，因为我们进入下一年。”我不知道这是否有用，但是…

bill detwiler:不，这是一个很好的解释，因为它引出了我的下一个问题，我真正想要谈论的是低代码，无代码的运动，因为这是另一种技术。

杰弗里•哈蒙德:哦，低码的避雷针。

比尔:是的。这是另一个技术脚，就像你说的人工智能，将会有一个戏剧性的影响，或者可能会有戏剧性的影响，取决于你问的是谁，对应用开发前景的发展。

你刚才谈到人工智能可以被看作是对开发者已经在做的事情的扩充，实际上是接管了一些他们可能不喜欢做的事情。因此，在零和游戏中，这是互补的，而不是对抗的。要么让人工智能来做，要么让开发人员来做。

这就把我引向了低编码和无编码的预测。当有业务终端用户或其他非程序员业务专业人员编写代码时，开发人员还需要编写代码吗?或者您仍然需要维护所有的代码?那么，你们对2022年低代码和无代码的预测是什么呢?

jeffrey hammond:所以具体的预测是，到今年年底，75%的开发团队将部署和使用低代码ag凯发k8国际的解决方案。注意，不是75%的开发者。所以如果组织中有人在使用低编码，那就占75%

在某种程度上，我觉得自从我从事开发工作以来，也就是近30年的时间里，这种强迫极化的想法是我们必须要解决的问题。在某些方面，我觉得低编码已经成为了其中一个领域。

我学的是金融专业，在一些大型组织中学习powerbuilder代码。4gls在90年代早期的windows上。从概念上说，这些4gl与今天的一些低代码工具有什么不同?

如果我们不得不放下来看，我们有外部函数接口，我们可以调用它来做一些事情，比如读blob。如果我们需要访问数据库，我们会去找dba说，“我需要您编写一个存储过程，它接受这些参数并返回这些数据。”

一天后，他们又回来了。30年后，今天的mendix或者outsystems或者power都在做这个，除了它可能在调用一个没有服务器的功能。它在调用lambda，或者访问由kubernetes集群上的容器运行的api。

对我来说，真正的价值在于我想在什么层次的抽象上工作。这就是无代码和低代码出现的原因，因为从无代码的角度来看，有些用户必须在一定的抽象层次上工作，因为他们没有深入的知识。

这个人可能会使用不需要代码的工具。每个人都必须从某个地方开始，但即使是专业的开发人员，有时也会因为他们的目标而选择在更高的抽象级别上工作。

也许我想使用lambda，因为我不想处理kubernetes中集群的自动缩放。我只是想让它发生，这样我就可以专注于业务逻辑。也许我想用mendix或者outsystems，因为你知道吗?我得在三周内拿出一个追踪和追踪的应用程序。

或者企业需要实施路边皮卡，每一天如果我们没有它，我们就会损失数百万美元，因为我们的零售机构关闭了。这就是我们在2020年看到的low-code。在很多情况下，速度是最重要的，因此，开发人员选择了更高层次的抽象，他们推出了应用程序。

对我来说,我认为我们需要做的,是我们需要看看我们看到的更多的频谱从高水平的抽象,抽象和理解水平低,业务将在多个接触点谱基于他们正试图完成什么。我认为在每个组织中都有低编码的地方，如果你这样看的话。

bill detwiler:如果你是与开发人员交谈，也就是一线开发人员、编码人员，他们看着无代码和低代码，想着“这将如何影响我，我应该如何准备?”你说呢?

我明白你说的从企业的角度来看,甚至从强调速度,但是如果你的人一个新的开发人员第一年,你还在大学或某种类型的培训项目的学习代码,他们需要知道low-code没有代码,和我们认为它会如何影响他们做的工作,寻找明年或明年甚至五年从现在做什么?

杰弗里•哈蒙德:我认为它将要做的一件事是我们之前的一项预测，它可能会改变我们组织软件开发团队的方式。

在典型的it企业中，所有的开发人员都在it组织中，他们会去找cio，他们可能会从业务部门获得需求，或者每隔几周就会去找业务赞助者，但这是一个非常孤立的组织。

正如我们所看到的，越来越多的组织大规模地采用了敏捷，他们开始将产品负责人放到这些团队中，这些产品负责人可能来自业务部门，但他们在技术上仍然是自组织的。

当您开始看到越来越多的业务开发人员通过低代码参与开发时，我认为您可能会看到更多的混合团队，在这些团队中，开发人员可以通过矩阵管理嵌入到业务组织中，甚至可以与这些组织联合或分配到这些组织中。

想象一下这样一个世界，不是业务用户给你一个草图，或者一个需求文档，作为一个开发人员，你必须解释它。想象一下，一个开发人员可能正在做一些线框图，或者一个业务用户正在做一些ui。

因为我倾向于发现，企业真正关心的是像素，他们关心这些像素是如何工作的，他们关心这些像素是如何流动的。他们不关心api是如何构造的。他们不关心kubernetes集群是如何建立起来的。他们不关心函数是如何自动伸缩的，他们只关心它是否有效。

所以我认为作为一个专业的开发人员,这意味着的一件事就是,我们也许开始关注的技术品质系统一点,我们得到一点帮助业务的功能和价值,我们必须提供,甚至一些比较或线框图我们不得不解释过去。

你甚至可以看到,从少low-code世界,当我们开始看到越来越多的组织讨论设计系统,在那里他们表达系统如何应该和行动,还有小一点的工作负载从发展的角度对我们的前端。

所以它会完全说，“不需要前端开发人员”，绝对不会。英雄，移动应用程序，面向客户的应用程序，你仍然需要关注细节并在那里寻找启示。但也许对于一些面对应用程序的员工，我们可以用这些混合团队做更多的前端工作。明白了吗?

比尔:是的，是的。这是报告中另一个预测，也就是跨职能团队，协作工作管理。请更详细地谈谈这个预测。

我和应用开发组织的人交谈过，他们描述的是同样的事情。在我20年的科技生涯中，我个人就像钟摆一样来回摆动。

所以说一下这个，它似乎就像你说的，回到“嘿，我们要嵌入开发者。我们将使他们更接近最终用户，而不是这些独立的it组织的一部分。

但对有些人来说，这不是一个容易的转变，对吧?它需要一些不同的技能。我的意思是，我记得在学校和工程学校上学的时候，那更多的是，“好吧，你是一个工程师，你要去工作，然后……”

那时我的专业是工程数学和计算机科学。那就是，“你要自己工作。你不会有一个真正的大团队。也许你会从其他组得到一些信息，但它会是你，它会……”这就是- – – – – –

杰弗里?哈蒙德:把他们放在办公室里，给他一罐可乐，然后把披萨塞到门缝下面。这就是你所需要的，对吗?

比尔·戴特韦勒:就是这样。但那是完全的，完全的…这是不同的。但仅仅五年之后，情况就不一样了。教授们在这里来来回回地推来推去。我在和自己约会……60年代，70年代和80年代，仍然有这样的心态，80年代出现的一些新人，现在我们到了90年代。

所以说第一点，对跨职能团队的预测，开发人员应该真正考虑的是如何进行过渡，开发应用程序开发负责人，以及他们如何确保员工成功过渡?

杰弗里·哈蒙德:没错。我认为这非常重要，因为从文化的角度来看，开发者有更多的需求。多年来，我们基本上一直在说，“嘿，看，工具是伟大的，但如果你没有正确的开发文化，你就不会在敏捷和提高速度方面取得成功，这对开发人员也是一样的。”

大约在10年前，我写了一篇关于高性能开发团队的最佳实践的文章，其中的许多内容今天仍然是正确的。它基本上借鉴了dan pink在2000年代中期所做的关于内在动机的研究，基本上证明了开发是一个创造性的职业，也是一个启发式的职业。

所以你需要有能力表达创造性思维的开发人员，有能力采取自主的行动，有能力在精通的文化中工作，有能力为共同的目标而奋斗。如果你有这些东西，他们就会想要对终端用户感同身受。他们想了解用户想要什么。他们想要学习新技术来满足用户的需求，并将其价值传递给用户。

它一直影响到文化。我给你们举个例子。多年来，我与亚马逊进行过交谈，亚马逊有趣的一点是，他们的服务团队中只有10%的人有产品经理。

这些都是向外部客户公开的服务。剩下的90%，工程经理是团队组织的核心关键。因此，工程经理可能有很强的技术背景，但他们的团队仍然要根据他们在亚马逊其他地方创建的服务的重用程度来衡量。

因此，如果要对重用进行度量，那么如何确保重用是好的呢?你走出去，了解别人的需求。你知道你的团队需要做什么，以确保其他团队可以从你所做的努力中获得价值。你实际上扮演了一个产品经理的角色。

所以这些东西，同理心和自主性对于成功是至关重要的。所以，如果你想作为一名开发人员，有一条通往工程经理的职业道路，或者在某个时候开始在职业链条上往上走，重要的不仅仅是技术，还有其他软技能。

所以你可以让我站在你说的那一边。因此，当这些团队开始变得越来越跨职能，能够和一个没有技术背景，或者没有技术学位的产品经理一起工作并且能够转化他们想要完成的事情。

工作能力与业务用户可以画出他们想要的东西,或勾勒出一个屏幕设计,但不知道他们正在寻找的信息实际上是很难齐心协力从所有那些你的现有系统,甚至可能不是能够提供实时数据,并有对话的方式,他们觉得不贬低,或他们不感到被边缘化,我认为是非常重要的。

更重要的是，我们的另一个预测是，我们不会很快回到办公室。物理托管作为一种克服这些挑战的方式，作为一种能够看到其他人在想什么的方式，作为一种进行高带宽对话的方式，我们不会将其作为一种奢侈。

多年来我们一直在说，“文化很重要，组织也很重要。工具可以起到帮助作用，但它们不如正确处理其他事情重要。”我们几乎要在上面转180度。

所以当我们谈论协作工作管理工具或价值流管理工具时，它们变得比以往任何时候都重要的原因，是因为我们现在必须做的很多事情都必须通过数字机制来完成。

举个例子，微软。amanda silver，做了一个关于微软如何适应一个完全偏远的文化的演讲。她说的其中一件事是，“我们需要能够从任何地方发货。”这不是他们以前做过的事情。

因此价值流管理是那些事情之一，如果它被正确地实现，并且工具支持它，开发人员可以从任何地方发货。他们可以从任何地方推进，他们可以从任何地方构建，这使得这些团队比以前更加自治。

协同工作管理也是如此。它支持高带宽的通信，所以你没有这种自顶向下的项目组合模型，每个人都在等待项目经理或计划经理做出决定，然后他们继续前进。

它允许团队进行高带宽的对话，即使他们不再在同一个豆荚中。所以它利用了物理托管的便利，并用我所说的精神托管来代替。团队，即使彼此不在一起，仍然可以进行高带宽的协作，这对敏捷的成功是至关重要的。

比尔·迪特韦勒:你如何做到这一点，同时又不让人负担过重?因为我认为有无数的会议，或者一天50个zoom电话，或者团队，hangouts或者webex，或者任何你选择的平台，你如何做到这一点而不让人们因为太多的交流而不知所措呢?正确的平衡是什么?

杰弗里•哈蒙德:我把这些都放在经理们身上，以确定正确的基调。stack overflow，最近在acm杂志上写了一篇文章，在那里他们写了一些他们发现的实践。

其中一个特别突出的问题是，一整天都不参加视频会议，即使人们还在工作。大多数时候他们都是沉默的，但如果有人有优先中断或者有问题，每个人都在那里，所以他们可以直接问。

如果有人有了答案，他们可以非常迅速地做出反应。这和你把头从荚果上翘起来，说:“嘿，有人知道该怎么做吗?”没有什么不同。

所以他们并不是真的。这是被动的协作。像这样的小事情，“确保你的状态是准确的，知道你是否打扰了别人，然后尊重这个状态。”所以小事情。

从管理的角度来看,我认为这是认识到,当我们从一个sprint成马拉松,这个初始破裂的生产力,因为人们不做两个小时上下班了,他们承诺在晚上或者周末的时候,当他们不能够出去社会时间,或者看到自己的朋友是不可持续的。

我们将会看到影响，我们应该预料到，如果我们没有看到这些影响，如果我们仍然看到人们以高于正常水平的生产力工作，也许是时候介入并说，“嘿，你在周末承诺。你真的不应该这么做。”

“让我们把周末定在周末，让我们确保我们是从长远的角度来处理这件事。”我认为对开发团队的经理们来说，监控倦怠症状是非常重要的。

比尔·戴特韦勒:这是我知道的，或者至少从我的经验来看，对于那些高度……这完全是泛化。我并不是说每个人都是这样的。这是我所知道的人们的一种感觉，特别是当你的团队中有成员，他们在获得反馈方面不太善于交流。

所以作为一名经理，除非发生了非常糟糕的事情，除非发生了意外，否则很难看到这些迹象。我不是说这并不是经理的责任,它不负责寻找这些迹象,但它可以更难发现如果你有第一的人,不沟通或沟通习惯,然后你的额外障碍没有物理距离,在你看不到的肢体语言。

我明白你说的关于会议的内容，你还得整天开着缩放电话或视频电话。我们不在办公室。我们在人们的私人住宅里，我们看到新闻里的恐怖故事，比如人们不小心打哈欠，或者在他们的公开视频通话中发生了他们可能不希望发生的事情，所以这对管理者来说是一个棘手的时期。

如果你是一个开发经理，或者你是一个单独的贡献者，一个团队成员，你会建议他们做什么来确保这种交流能够定期进行?

杰弗里•哈蒙德:嗯(肯定的)。嗯，我认为其中一件事是预算更多的时间在社会互动。我给你们举个例子。我们的团队会议通常是每两周开一次。我的老板把时间改为每周，但我们并没有做两倍多的事情。

我们增加了更多的时间来进行一点社交活动。大家都好吗?你在干什么?近况如何?我知道很多创业公司，在历史上，当每个人都在同一个地方，他们会吃早餐和晚餐，他们会一起吃早餐和晚餐，诸如此类的事情。

所以我们周五还可以一起喝啤酒，如果那是一种文化的话。我们仍然可以讨论我们的10%时间项目，如果你已经实施了10%的时间。我们的目标是努力保持和办公室一样的社交互动水平。如果你不能做到全程，那就确保你作为一个经理已经尽了最大的努力。

我们看到的一件事是越来越多的组织正在调整他们的衡量标准。所以有一些措施，比如参与。想象一下，定期为开发人员提供服务时，你会问:“你最近怎么样?”你有多满意?”

看看这个发展组织的净发起者分数。事实上，经理们甚至关心这一点，这是一个很好的迹象，因为这表明，他们将人才视为一个战略问题，应该予以关注。不是弗雷德·布鲁克斯，神话般的人月，让一个开发人员出来，再把另一个扔到绞肉机里，这很好。

我认为，如果你使用github或gitlab之类的工具，你可以通过观察流量指标甚至每天提交的时间来做一些事情，从而了解一天的时间是否超出了它应该扩展的范围。所以这些都是我认为值得考虑的投资当你进入2022年从管理的角度来看。

bill detwiler:我认为因为你之前提到过，covid在美国不会很快消失，很不幸。我们很可能会在某种程度上改变工作条件，即使不会一直持续到2022年。

现在组织已经实施的一些变化将会持续更长的时间。不是因为流感大流行，而是因为他们意识到，他们这么做有很多理由。

让我们谈谈你的最后两个预测，那是专门教你如何谈论它的。一个是关于现代化，另一个是关于达到这种清晰的网格技术。从现代化。你对2022年的预测是什么?

杰弗里·哈蒙德:没错。covid创立之初发生的一件事是在那些收入一落千丈的行业中。旅游和运输，比如零售。我们看到预算受到了影响。我的意思是，你会期望情况是这样的，结果，很多人把他们的一些现代化努力搁置。

这就像，“如果我们在两到三年内将无法存在，那么我们是否必须改变这些东西并不重要。”另一方面，我们看到一些组织基本上说，“看，该死的鱼雷，全速前进。如果有的话，我们必须更快行动才能生存。我们必须在电子商务方面加倍努力。我们必须在店内取货或本地送货等方面加大投入。”

这就造成了有产者和无产者之间的分歧。现在，当我们进入这个马拉松式的阶段，那些基本上踩了刹车的公司面临着生存危机。他们要么必须重新启动这些程序，要么说推动踏板的人之间的差距会越来越大。

杰弗里•哈蒙德:因此，我们确实希望看到预算回归，尤其是当如何实现现代化变得越来越清晰时。正如我们看到的，人们开始在大规模部署容器方面取得了更大的成功，正如我们看到的，组织找到了能够扩展基于服务的架构的方法，使用诸如服务网格之类的东西，甚至使用一些事件驱动的构造。

模式变得更加清晰，这意味着通过实现那些先行者所讨论的模式，落后者可以在先行者之后开始行动。

所以，net net，我认为我们将会看到更多的关注。这里载入流行语，…本地云架构，无论是混合云还是公共云。我认为我们将会看到很多关于prem上的混合云架构的实验，特别是当组织开始释放一些他们正在尝试现代化的核心工作负载时。

这意味着像openshift，像tonzu，甚至anthos这样的ag凯发k8国际的解决方案，是很多组织都在努力推动的东西，看看他们能从这些ag凯发k8国际的解决方案中得到多少，因为他们开始进行现代化。

把东西装进容器是第一步。你宣布胜利，然后你开始你的扼杀者图案或你的正面，并开始打破那些巨石。也许不是所有的微服务，也许以迷你列表作为起点。

但很多阻碍和解决这些问题都必须成为2022年实施工作的一部分。这就是我们认为的服务网将展示他们的一些能力，在执行绞死巨石的过程中提供帮助。

bill detwiler:那么开发者在2022年应该关注什么呢?现在是2020年11月，我们还有两个月的时间。开发者在2022年真正应该期待什么?我的意思是，我们已经说了很多了，但是如果你必须说一些事情的话。你坐在那里，你在想，“嘿，我在考虑我自己的职业或这个行业的发展方向的不同可能性。”

我们谈论学习语言，但如果你从更大的角度思考，你会发现哪些大的趋势是…有一两件事情你认为开发人员应该真正注意、研读并为明年做好准备吗?

jeffrey hammond:如果你对容器在开发和交付软件中所扮演的角色没有一个很好的把握，我认为你需要尽快到达那里。这并不一定意味着您必须完全使用kubernetes并开始学习yaml的所有复杂性，从而成为一名网络专家。

你可能，我的意思是，有很多这样的需求，但至少，你需要了解容器如何成为默认的切换。无论是kubernetes世界还是ecs世界，甚至是其他运行时。

另外，我认为了解前端是如何发展的也是值得的。你现在有很多有趣的事情正在发生，无论是react native, react in view还是flutter框架，以及它们在移动和web开发中所扮演的角色。

在我们考虑用jamstack之类的东西写前端的方式上，您已经有了令人兴奋的变化。所以有很多机会来提高你的技能，看看在这个领域有什么组织在做。我认为，随着我们进入2022年，在一些云本地架构中，将计算和存储放到边缘的想法将会出现爆炸式增长。

我们将在即将到来的wave中看到它，这对我来说非常令人兴奋。所以我认为，在你们考虑2022年以后我应该学习什么技能的时候，有很多机会来创造你们的技能集的差异性，从而满足对你们人才的需求。

文章来源：超级架构师

原文链接：https://mp.weixin.qq.com/s/ctioxebqv03r_nsn4wbpja