前端开发可以借助 JRebel 和 Nodemon 之类的工具使前端开发预览的体验更流畅，实现前端代码的“所见即所得”，避免重复的编译、打包、部署和重启步骤，以此提高开发过程的流畅度。
选择适合项目的代码分支策略对提升效率也大有帮助。
构建高度自动化的 CI 和 CD 流水线将大幅提升价值的流转速率。
选择合适的发布策略也会对效能和风险之间的平衡起到积极的作用。比如架构相对简单，但是集群规模庞大，优选金丝雀，如果架构比较复杂，但是集群规模不是太大，可能蓝绿发布更占优势。
引入 DevSecOps 与 DevPerfOps 实践，使安全和性能不再局限在测试领域，而是形成体系化的全局工程能力，让安全测试成为安全工程，性能测试成为性能工程。
...
研发效能的“罗生门”好了，理解了研发效能的正面观点后，我们再回来看看研发效能在实际落地过程中又是一番什么样的景象。
可以说理想很丰满，但是现实很骨感，下面就我一起看看国内研发效能的各种乱象。
01 迷信单点局部能力，忽略全局优化和拉通的重要性研发效能的单点能力其实都不缺，各个领域都有很多不错的垂直能力工具，但是把各个单点能力横向集成与拉通，能够从一站式全流程的维度设计和规划的研发效能成熟平台还是凤毛麟角。现在国内很多在研效领域有投入的公司很多其实还在建设，甚至是重复建设单点能力的研效工具，这个思路在初期可行，但是单点改进的效果会随着时间收益递减，企业往往缺少从更高视角对研发效能进行整体规划的能力。很多时候局部优化并不能带来全局优化，有时候还会是全局恶化。
02 具有普适性的通用研发效能工具其实没有专属工具来的好用既然打造了研发工具，那就需要到业务部门进行推广，让这些研效工具能够被业务部门使用起来。其实，很多比较大的业务团队在 CI/CD、测试与运维领域都有自己的人力投入，也开发和维护了不少能够切实满足当下业务的研发工具体系。此时要把新打造的研效工具来替换业务部门原来的工具，肯定会遇到很强的阻力。除非新的工具能够比老工具好10倍，用户才可能有意愿替换，但实际情况是新打造的工具为了考虑普适性很有可能还没有原来的工具好，再加上工具替换的学习成本，所以除非是管理层强压，否则推广成功的概率微乎其微。即使是管理层强压，实际的执行也会大打折扣，接入但不实际使用的情况不在少数。
03 用“伪”工程实践和“面子工程”来滥竽充数如果你去比较国内外研发效能工程实践的差距，你会发现国内公司和硅谷公司的差距还是相当明显的。但是当你逐项（比如单元测试，静态代码扫描，编译加速等）比较双方开展的具体工程实践时，你会惊讶地发现从实践条目的数量来说，国内公司的一点都不亚于硅谷公司，在某些领域甚至有过之而不及。那为什么这个差距还会如此明显呢？我们认为这其中最关键的点在于，国内的很多工程实践是为了做而做，为的是“政治上的正确”，而不是从本质上认可这一工程实践的实际价值。这里比较典型的例子就是代码评审和单元测试。虽然很多国内互联网大厂都在推进代码评审和单元测试的落地，但是在实际过程中往往都走偏了。代码评审变成了一个流程，而实际的评审质量和效果无人问津，评审人的评审也不算工作量，也不担任何责任，这样的代码评审能有什么效果，结果可想而知。单元测试也沦为一种口号，都说要贯彻单测，但是在计划排期的时候压根没有给单测留任何的时间和人力资源，可想而知这样的单测是否能成功开展。所以，国内公司缺的不是工程实践的多少，而是工程实践执行的深度。不要用“伪”工程实践和“面子工程”来滥竽充数。
04 忽略研发效能工具体系的长尾效应再回到研效工具建设的话题上，很多时候管理团队希望能够打造一套一站式普遍适用的研发效能平台，希望公司内大部分业务都能顺利接入，这和想法的确非常好，但是不可否认的，研效平台和工具往往具有非标准的长尾效应，我们很难打造一套统一的研效解决方案来应对所有的业务研发需求，各种业务研发流程的特殊性是不容忽视的。退一万步说，即使我们通过高度可配置化的流程引擎实现了统一研效解决方案，那么这样的系统会因为过于灵活，使用路径过多而易用性变得很差。这两者的矛盾是很难调和的。
05 盲目跟风