500 位软件开发工程师的声音：微服务和 CI/CD 依旧是最爱

近日，Atlassian 发布软件开发相关调查报告，本报告收集了 500 多位软件开发人员的意见，对软件开发的部署、测试等发展现状进行总结。结果表明，软件开发工程师的价值意识已经觉醒，开始注意客户价值的重要性。

近几年，软件开发领域的声音似乎渐渐被人工智能、物联网、云计算等新兴技术遮掩，软件开发工程师这一群体的话语权越来越少。本周，InfoQ 曾就“软件开发是否有价值”展开讨论(《一个沉重的问题：软件开发到底还有价值吗？》)，传统的开发方式束缚着不少软件开发工程师的发展，软件质量和价值在逐渐降低。

本次调查，93％的开发工程师表明比其他任何人都重视客户满意度，但是，其中 60％工程师表示虽然重视，但客户满意度几乎无法准确衡量。正是这种意识的觉醒，让软件开发领域开始不断以更高效，可衡量的方式一次又一次提高软件价值。

在现代软件开发过程中，开发新功能会优先考虑客户体验，这与新功能的发布时间一样重要。73％的软件开发团队会花费 10％到 50％的时间更新和升级自托管软件。当团队不处于维护模式时，92％的团队必须每周（甚至更频繁地）提供状态更新。平均而言，Jira 客户依赖较少的状态更新工具，平均为 2.3 种，非 Jira 用户大概会使用 3.3 种。

软件开发新趋势

微服务：单体应用 monolith 在下降

平均而言，软件和 IT 团队使用 4.3 种工具将代码从开发转移到客户生产环境，这个数字其实已经很多了。大规模的单片代码库会让连续交付变得非常困难和耗时，monolith 方式会限制团队速度，集成不同的服务和功能可能导致难以识别的错误，开发人员通常不会密切了解彼此的工作，扩展构建和测试也可能会使部署速度变慢。

研究表明，71％使用微服务架构的软件和 IT 团队认为，测试或部署过程比较容易，这是因为，当团队利用 PaaS 服务时，其中一些重要部署功能会直接进入平台。基于微服务的架构允许小型自治团队独立开发、部署和扩展其服务。

CI/CD：手动测试已经过时，自动测试正在进行中

众所周知，我们生活在一个消费者期望技术不断更新的时代。如果团队做不到，他们将会很容易被取代，想想自己在过去几年换了多少部手机就明白了。

软件开发出现早期，团队无法经常更新的主要原因之一是手动测试，自动测试覆盖率不足，额外的手动流程以及缺乏构建和部署管道自动化导致手动测试出现问题的团队占比 62%。

进入持续集成和持续交付时代，团队可以自动从源代码到生产环境发布高质量软件实践。CI/CD 正迅速成为满足不断增长的客户期望的重要手段，47％的团队通过 CI/CD 解决方案更快地发布变更并接收客户反馈，另有 57％的受访者表示采用 CI/CD 解决方案可以减少错误或中断，实时提供有关部署和发布状态的信息工具允许团队定期发布客户满意的功能。

Feature Flagging：降低风险，提高客户满意度

软件开发团队面临的另一个障碍是以安全，增量和可衡量的方式推出新功能，75％的软件和 IT 团队在调查中表示会在发布时遇到错误、缺陷或延迟问题。相反，63%使用 Feature Flagging 的团队在调查中表示，拥有更好的功能测试或更高质量的软件，这在很大程度上是因为大多数团队习惯同时为所有客户推出新功能。

Feature Flagging 允许团队向少部分客户（例如 25％）推出新功能，以便将问题和错误风险分散，并在将其推广到整个客户群之前评估客户反馈。

结果驱动型开发：客户价值优于团队成果

几乎所有软件开发团队都希望提供能够提高客户满意度的功能，但缺乏跟进该目标的方法，这种困境反映了按产出衡量工作的悠久历史，而不是客户结果（即客户价值）。

事实上，结果驱动型开发的概念已经被提出多年，软件开发团队正在逐渐将焦点从开发速度和功能交付转移到所创建的客户价值上，希望采用以结果为导向的实践团队应该考虑提供实时构建和部署工具，围绕客户采用数据分析以及内置 Feature Flagging，这一方法预计在未来会被更多 IT 团队采用。

参考链接：https://www.atlassian.com/blog/software-teams/modern-software-development-trends