代码可读性真的比性能更重要吗？

在一次代码审查里，我把同事写的循环改成了更直白的写法，结果大家一眼就看懂了，却意外地把执行时间推迟了几毫秒。于是我不禁想，究竟是可读性更重要，还是那点性能提升值得我们牺牲代码的清晰度？

可读性带来的隐形收益

把函数名、变量名当成路标，后来的维护者只要跟着走，就能快速定位问题所在。比如把calc改成calculateTotalPrice，即使多写了几个字符，也能省下新人调试时的百次点击。更重要的是，清晰的结构让自动化工具更容易做静态分析，潜在的 bug 也更容易被捕获。

性能瓶颈的真实场景

在高并发的交易系统里，毫秒级的延迟会直接影响用户体验，甚至导致金钱损失。此时，位运算、内存池的微调往往比代码排版更关键。一次对热点函数的微优化，让每秒处理请求数提升了 5%，这在业务报表上立刻变成了可观的增长。

寻找平衡的艺术

其实两者并不一定是对立的。可以先写出易读的版本，再用基准测试找出真正的热点，针对性地进行优化。团队规模、项目生命周期、部署环境都是决定权衡点的因素。小团队的项目往往更倾向于可维护性，而大型分布式系统则必须在关键路径上打磨性能。

“代码是写给人的，机器只是顺从它的指令。”

所以，当你在编辑器里敲下下一行代码时，是否会停下来思考：这段实现是为谁写的？如果是为明天的自己或同事，那可读性或许真的值得我们多花一点时间。否则，若是为毫秒争夺战，那性能的刀锋就不可回避。你会怎么抉择？