从商业视角来看，现在 toC 产品已经趋向饱和，过去大量闲置时间等待被 APP 填满的红利时代已经一去不复返了，以前业务发展极快，那么用烧钱的方式（粗放式研发，人海战术）换取更快的市场占有率达到赢家通吃是最佳选择，那个时代关心的是软件产品输出，研发的效率都可以用钱填上。而现在 toC 已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈了，节流就应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出。
03 部分企业存在“谷仓困局”从组织架构层面看，很多企业都存在“谷仓困局”，研发各个环节内部可能已经做了优化，但是跨环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度正是研发效能在流程优化层面试图解决的一大类问题。
研发效能真的能够提高吗既然如此重要，那接下来的问题是研发效能是否真的能提高？
很不幸，我们的观点比较悲观。我们认为研发效能的绝对值随着以下因素的增长必然会变得越来越差，就像我（声明一下，这里没有张乐老师）的头发一样，随着时间的推移必然会越来越少一样。
软件架构本身的复杂度提升（微服务，服务网格等）
软件规模的不断增长（集群规模，数据规模等）
研发团队人员规模不断扩大引发沟通协作难度增长
所以，我们能做的不是提升研发效能的绝对值，而是尽可能减缓研发效能恶化的程度，使其下降的不至于太快，努力保持现状就是成功。
研发效能的鸿沟
减缓研发效能恶化我们能干啥看清了本质后，关于如何减缓研发效能的恶化，我们能做点什么呢？
可以说研发效能的涉猎面是很广的，软件研发的每个阶段都有研发效能需要关注的问题，腾讯提出的“研发效能双流模型”可以说很好的诠释了这一概念。双流模型从软件研发的各个阶段提出了研发效能提升的各种工程实践，并且倡导需求价值流和研发工程流的自动联动。
研发效能的双流模型
这里我们列举一些实践给大家抛砖引玉一下，下期的文章我会更系统地来说明其中的最佳实践。
可以通过 All-in-one 的开发环境降低每位开发人员开发环境准备的时间成本，同时又能保证开发环境的一致性。更高级的玩法是使用云端集成开发环境 IDE，实现只要有浏览器就能改代码，这一领域国内典型的代表就是腾讯云 CODING 旗下的 Cloud Studio 以及 Github 目前处于 beta 测试阶段的 CodeSpaces。
可以借助基于 AI 的代码提示插件，大幅度提升 IDE 中代码的开发效率。输入一段相同的代码，不借助 AI 代码提示插件，需要敲击键盘 200 次，启用插件可能只需要 50 次键盘敲击，这样可以更容易让开发工程师进入“心流”状态，实现“人码合一”。
代码的静态检查没有必要等到代码递交后由 CI 中的 Sonar 流程来发起，那个时候发现问题再修复为时已晚，完全可以通过 Sonar Lint 插件结合 IDE 实时发起本地的代码检查，有问题直接在 IDE 中提示，直接修复，这样开发工程师会更愿意修复问题，因为成本更低，也不会引起修复后的再次发版。
单元测试比较耗费时间，可以借助 EvoSuite 之类的工具降低单元测试的开发工作量。
对于规模较大的项目，每次修改后编译时间比较长。可以采用增量编译，甚至是分布式编译（Distcc 和 CCache）提升效率，对于 Maven 项目还可以通过缓存 pom 依赖树进一步降低编译时间。