为变更优化，而非应用性能

# 开发者体验是一项性能特性 | Christian Rackerseder 来源：https://www.echooff.dev/blog/developer-experience-is-a-performance-feature ## 很多性能讨论优化错了方向\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#many-performance-discussions-optimize-the-wrong-thing) 团队花了几周时间把渲染性能提升了几毫秒，而工程师却不敢碰代码库。 工程讨论往往把大量精力放在： - 渲染基准测试 - 打包体积 - 水合速度 - 不必要的重渲染 - 微优化 性能确实重要。 但很多团队优化错了维度。 技术层面更快的系统，并不自动让整个组织变得更快。 尤其是当： - 测试很痛苦 - 调试很痛苦 - 入职培训需要数月 - 部署让人压力山大 - 堆栈跟踪难以阅读 - 没人再理解那些抽象层的时候 在许多组织里，真正的瓶颈不是应用性能。 而是工程吞吐量。 ## 性能不仅仅用毫秒来衡量\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#performance-is-not-only-measured-in-milliseconds) 我不在乎一个框架重渲染是否稍微快一点，如果： - 我无法妥善测试它 - 调试变得极其痛苦 - 那些抽象层变得无法理解 - 工程师不停地和工具链作斗争 - 架构越来越难以维护 测试依赖浏览器环境的前端架构，常常需要越来越复杂的环境模拟。 我在这篇文章中更详细地讨论过这个问题：为什么不应该直接访问浏览器全局变量 (https://www.echooff.dev/blog/avoid-direct-browser-globals)。 一个难以协作的系统，整体速度会变慢。 CPU 或许更快了。 但组织往往没有。 现代工程营销喜欢用“极速”这个词。 通常衡量的是运行时基准。 很少衡量调试体验、可维护性或工程信心。 性能不仅仅是毫秒。 它也在于工程吞吐量。 它体现在： - 工程师能多快**安全地**交付功能 - 修复 bug 有多快 - 重构能多自信地完成 - 新工程师上手有多容易 - 部署变得有多可靠 长期的产品质量，通常反映了其背后的工程体验。 ## 开发者体验会随时间产生复利\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#developer-experience-compounds-over-time) 良好的开发者体验不仅仅是“好用的工具”。 它直接影响： - 交付速度 - 可维护性 - 可靠性 - 入职上手 - 事件响应 - 重构信心 - 工程满意度 而这些东西会随时间累积增长。 一个易于理解的代码库会变得更容易维护。 一个易于维护的代码库会变得更容易优化。 一个工程师不害怕修改的代码库，演化得更快。 从长远看，这比赢得那些合成的渲染基准测试重要得多。 ## 真正的瓶颈往往是工程信心\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#the-real-bottleneck-is-often-engineering-confidence) 我见过团队花了巨大精力优化运行时性能，而与此同时： - 持续集成流水线要跑 30 分钟 - 端到端测试经常不稳定 - 本地开发环境不可靠 - 部署时总是提心吊胆 - 工程师回避重构，因为他们不信任系统 渲染性能并非瓶颈。 缺乏工程信心才是。 恐惧会让一切慢下来： - 功能交付 - bug 修复 - 重构 - 事件响应 - 入职上手 团队很少会去优化他们害怕碰的系统。 我在这篇文章中更详细地讨论过：为什么你的单元测试感觉很脆弱 (https://www.echooff.dev/blog/why-your-unit-tests-feel-fragile)。 ## 良好的开发者体验常常间接改善性能\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#good-developer-experience-often-improves-performance-indirectly) 颇具讽刺的是，良好的开发者体验往往最终还是能提升应用性能。 因为工程师更愿意去优化他们能理解的系统。 清晰的架构。确定性的行为。可靠的工具链。易理解的状态管理。良好的可观测性。快速的反馈循环。 这些都能增强信心。 而信心赋能改进。 一个更容易理清头绪的系统，通常日后也更容易优化。 ## 复杂性有其代价\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#complexity-has-a-cost) 很多优化会引入隐藏的复杂性。 额外的构建步骤。编译器魔法。激进的记忆化。自定义缓存层。框架特定行为。 有时这些性能提升是值得的。 但通常并非如此。 特别是当付出的代价是： - 更差的可测试性 - 更差的调试体验 - 更差的可维护性 - 更高的认知负荷 - 更低的可靠性 一个理论上更快但更难演进的系统，最终往往会让业务整体变得更慢。 ## 快乐的工程师构建出更好的软件\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#happy-engineers-build-better-software) 这听起来很简单，但以我的经验来看的确如此。 快乐的工程师通常会： - 更用心 - 更多尝试 - 主动改善系统 - 更早修复问题 - 协作更好 - 更自然地承担责任 良好的开发者体验会减少挫败感。 而更少的挫败感，意味着有更多精力去解决真正的客户问题，而不是去和开发环境作斗争。 或者用更简单的话说： > 快乐的工程师 = 快乐的客户 至少我的经验是这样。 ## 为长期的工程速度优化\# (https://www.echooff.dev/blog/developer-experience-is-a-performance-feature#optimize-for-long-term-engineering-speed) 作为工程师，我们当然应该关注性能。 但我们应该全面地优化。 而不仅仅是面向运行时性能。 也要为以下方面优化： - 可测试性 - 可维护性 - 可靠性 - 可观测性 - 清晰性 - 运维简洁性 - 开发者幸福感 因为最快的代码库，往往是工程师不害怕去修改的那个。 而快速的工程师，通常最终也会构建出快速的应用。