Code Review 时同事说"这里用单例模式更好"，我反驳了，然后吵了半小时

上周 Code Review，同事看到我写的一个工具类，说："这里应该用单例模式，每次 new 太浪费了。"

我不同意，然后两个人在会议室吵了半小时。最后 TL 过来打圆场，说"先用现在的方案，后续有性能问题再优化"。

但这件事让我反思：我们在 Code Review 里争论的，到底是技术问题，还是面子问题？

争议的代码

一个日志格式化工具类，每次处理日志时 new 一个实例。同事觉得应该用单例，减少 GC 压力。

我的观点是：这个类无状态、创建成本极低、且不是热点路径。单例模式引入的同步锁和全局状态，反而增加了复杂度。为了省一次 new 操作，值得吗？

我们吵的核心

同事的理由："单例模式是最佳实践，你这里明显不符合。"

我的反驳："最佳实践是有前提的。一个每秒调用 10 次的工具类，和每秒调用 10 万次的，能一样吗？"

最后谁都没说服谁。TL 的决策是"先跑起来，有数据再说"。

后续的数据

我加了监控，跑了两周。这个工具类的创建次数日均 5000 次，占整个应用的 GC 时间不到 0.1%。

把同事叫来看数据，他说："哦，那确实没必要。"

但如果没有这个数据，我们的争论会永远停留在"我觉得"和"你觉得"。

我的反思

Code Review 里很多争论，本质上是缺少度量。如果双方都能拿出数据，争论会少 80%。

但现实中，我们更愿意相信自己的经验，而不是花时间验证。

另一个反思是：设计模式不是圣经。单例模式在特定场景下是反模式（比如测试困难、隐藏依赖）。

但很多人学设计模式时，只记住了"什么时候用"，没记住"什么时候不用"。

你们团队 Code Review 吵过吗？

是技术争论多，还是风格争论多？有没有因为"最佳实践"四个字吵起来的经历？

我现在的原则是：任何优化建议，必须配数据。没有数据的优化，都是耍流氓。