刚工作那几年，我做技术决策时有一个执念：
这个方案够不够优雅？
架构要干净、代码要解耦、设计模式要标准、命名要完美。 但这几年下来，我发现自己越来越少为了“技术优雅”去做决定了。
不是我不在乎技术了，而是我开始在乎更重要的东西。
一、技术优雅，往往不是问题的核心
在真实项目中，大多数问题并不是因为“不够优雅”。
而是：
- 需求变得太快
- 时间窗口非常短
- 上线压力远大于技术理想
你花三天时间设计一个“完美架构”， 但业务可能一周后就推翻方向。
优雅 ≠ 有价值 至少在那个时间点不是。
二、系统的第一目标，是“活着”
后来我慢慢接受一个现实：
系统的第一目标不是优雅，而是可运行、可迭代、可止损
很多项目：
- 架构不完美
- 代码有历史包袱
- 命名不统一
但它们：
- 稳定
- 能快速响应需求
- 能被新人接手
这类系统，在现实世界里，反而“活得更久”。
三、过度追求优雅，常常带来隐性成本
我踩过不少这样的坑：
- 为了“解耦”，拆了过多模块
- 为了“扩展性”，引入复杂抽象
- 为了“设计感”，写了没人敢改的代码
结果是：
- 调试成本变高
- 新人理解成本极高
- 线上问题定位变慢
优雅只对设计者友好，对维护者未必。
四、我现在如何做技术决策
现在我更多问自己这几个问题：
- 这个方案 3 个月内会被推翻吗？
- 有没有人能在 30 分钟内读懂？
- 出了问题，能不能快速定位？
- 是否真的需要为“未来”提前设计？
如果答案不理想，我宁愿：
- 写普通一点
- 简单一点
- 可控一点
五、我不是不追求优雅，而是更克制了
说清楚一件事： 我不是反对技术优雅。
我只是明白了：
- 优雅是“锦上添花”
- 可交付、可维护、可演进才是“地基”
真正成熟的技术人， 不是写最漂亮的代码， 而是知道什么时候值得优雅，什么时候该克制。
结尾
如果你也发现自己：
- 越来越务实
- 越来越在意稳定和节奏
- 不再执着于“完美设计”
恭喜你， 你可能正在从“技术爱好者”， 走向“工程负责人”。
