停止过度工程化：如何在不削弱动力的情况下构建可扩展的应用

Source: Dev.to

真正的问题（不仅仅是过早优化）

我们都知道过早优化有害。但还有一种更隐蔽的情况：

过早的架构设计。
你实际上在为尚不存在的问题设计解决方案。

• 为“可扩展性”添加层级，而你只有 12 位用户
• 构建一次性就会被使用的可复用组件
• 为待办列表过度思考状态管理

代价： 开发变慢、调试更困难、以及不断的事后猜测。

没有人告诉你的事

可扩展的系统不是设计出来的——它们是演进的。
看看任何成功产品的早期代码：它往往凌乱、甚至让人尴尬，但已经上线。重构会在痛点真实出现时进行。你无法预测哪些会出问题；只能在问题出现时快速响应。

直接这么做

步骤 1：让它能工作
硬编码。跳过抽象。直接交付功能。

步骤 2：等到它让你痛苦
当你感到“改动这块很痛苦”或“这块慢得要命”——这就是信号。不要提前。

步骤 3：再重构
此时你已经清楚哪些需要复用、哪些慢、哪些痛苦。架构才有意义。

实际案例（React 文件夹）

从极简开始

src/
  components/
  pages/
  utils/

可以正常工作。

当文件太多时的后期结构

src/
  features/
    auth/
      components/
      hooks/
      api/
    dashboard/
      components/
      services/
  shared/
    ui/
    hooks/

这是你赚到的结构；一开始并不是这么做的。

过度设计的警示信号

如果你发现自己在说：

• “我们以后可能会需要这个”（其实不会）
• “把它做得超级可复用”（其实只用一次）
• “这个应该支持多种情况”（实际上只有一种情况）
• 组织结构比实际编码更多

停下来，深呼吸，交付点东西。

真正有效的规则

• 为今天构建，而不是为“如果我们有 1000 万用户”而构建。
• 代码重复两次后才考虑抽象第三次。
• 不要添加你几乎不懂的库。
• 只有在能够衡量问题时才进行优化。
• 交付速度要快于重构速度。

如果你正在构建某个东西……

你不需要微服务、花哨的状态机或企业级架构。
你需要的是可用的功能、反馈和速度。其他一切只是戴着华丽帽子的拖延。

最好的开发者不是设计完美系统的人，而是知道何时该闭嘴、直接把东西搞出来的人。