使用编程代理创建内部工具的速度变得快得多,但《Future of Platform Engineering 20现》报告的数据表明,构建的容易并不一定意味着拥有清晰的愿景。在379名平台工程专业人员中,在其大部分功能中采用从零开始构建的团队,将缺乏清晰策略视为障碍的可能性高出约3.5倍。
这一结果并没有证明从零开始构建是错误决定,但它揭示了平台能力的提供方式与团队运作方向的明确程度之间存在关联。
现成工具是最常见的选择
51.3%的受访者表示,使用基础现成工具是他们支持平台功能的主要方法,相比之下,31.2%的受访者依赖现有模板,17.5%的受访者从零开始构建。被归类为高性能团队对工具的依赖度更高,达到58.8%,而模板为47.8%,从零开始构建为33.3%。
例外情况出现在与特定技术路径直接相关的环境中,例如本地开发环境、一键创建的项目以及临时环境。在这些情况下,模板可以提供通用工具不易轻易提供的与已批准路径的兼容性。
临时环境是平台成熟度的指标
提供临时环境的团队更有可能报告人工智能对软件交付速度和稳定性、代码覆盖率以及成本控制产生积极影响。在将影响描述为非常积极的团队中,超过四分之三的人使用了临时环境。
但这种关系并不一定意味着临时环境本身导致了改善。提供临时环境的团队通常在包含多种自动化功能的更广泛平台内运作,这可能使平台的扩展和成熟度成为吸收人工智能产生的变化量而不牺牲稳定性的更重要因素。
为什么这条新闻很重要?
实际发生的最重要变化是,人工智能降低了编写代码的成本,但并没有消除拥有代码的成本。快速构建的工具需要维护、升级和治理,并且随着开发路径中变化量的增加,可能会增加运营负担。
数据支持了这种区别:在主要从零开始构建的团队中,57.9%的人表示缺乏清晰的策略是一个障碍,而在依赖模板的团队中这一比例为15.6%,在使用基础工具的团队中为16.7%。从零开始构建的团队也更多地将人工智能用于更新遗留系统和语言迁移,这表明这种使用的一部分用于维护团队自身造成的复杂性。
问题不仅仅是构建还是购买
成本效益分析是构建或购买决定的最常见原因,占29.6%;其次是对开源的偏好,占28.6%;然后是对适宜性和要求的评估,占22.4%;对商业工具的偏好占22.4%;为实现核心卓越而构建占16.3%。
该文章提出了数据未最终定论的两种可能解释:策略可能先于构建或购买决定,或者构建本身可能成为尚未成熟的策略的临时替代方案。但最清晰的编辑结论是,问题不在于从零开始构建,而在于在没有特定原因的情况下默认采用它。独特的功能应该围绕组织的环境构建,而解决标准问题的工具应该高效购买或采用,并计算维护和长期依赖的成本。
新闻来源
The New Stack - Software Development
查看原始来源 ↗