从 Maker 到系统架构师：设计可交付、可扩展且持久的软件

Source: Dev.to

为什么会有这篇文章

大多数技术文章解释要构建什么或如何使用某个工具。而本文则阐述经验丰富的创作者在系统不再“小”时是如何思考的。

我多年在设计、前端、后端以及产品所有权之间穿梭——常常是同时进行。构建 Screenity 和其他产品迫使我面对一个残酷的事实：

在规模化时，最难解决的问题不是技术原语——而是决策系统。

如果你曾经感觉教程在你的产品拥有用户后就不再有用，那么这篇文章适合你。

我的背景（以及它在技术层面的重要性）

我并不是从“纯粹”工程师开始的。我来自于：

• 设计界面
• 交付粗糙的原型
• 负责从想法 → 用户 → 失败的完整生命周期

这很重要，因为：

• 设计师关注表面复杂性
• 工程师关注结构复杂性
• 创始人感受到系统性风险

真实系统需要同时具备这三种视角。

核心原则：在优化之前先约束

大多数代码库会腐烂，因为它们过早进行优化，却过晚设定约束。

我的规则：
每个系统在扩展之前必须明确回答三个问题：

1. 什么是被允许的？
2. 什么是不可能的？
3. 我们如何知道它何时出现故障？

如果你的架构无法明确回答这些问题，复杂性将悄然累积。

架构即决策卫生

在构建 Screenity 时，早期版本发布迅速——但演进风险大。转折点在于把架构视为决策卫生，而不是单纯的结构。

变化内容

Before

• 隐式流
• 共享可变状态
• UI 逻辑泄漏到数据层

After

• 明确的边界
• 单向数据流
• 可审计的副作用

这降低了：

• 回归缺陷
• 上手时间
• 情绪疲劳（是的，这很重要）

我依赖的具体模式：约束优先模块

每个非平凡的模块设计都遵循以下顺序：

1. 定义不变量（绝对不能发生的情况）
2. 定义输入/输出
3. 然后才实现行为

示例（简化版）

• 记录状态可以是 idle | recording | processing
• UI 不能触发 processing
• 后台工作线程不能触碰 UI 状态

这些约束比任何框架的选择都更有价值。

为什么作为女性创始人改变了我的技术严谨性

作为科技领域的女性，交付产品会改变你的构建方式。你会学会：

• 积极记录
• 让决策可审计
• 设计能够自我说明的系统

因为假设会受到质疑。

结果？

我构建的系统：

• 解释其意图
• 大声失败
• 抵制误用

这不是关于性别——而是关于防御性的清晰。

大规模调试：停止追逐 bug，开始追踪责任

一旦用户规模扩大，bug 很少是孤立的。

我的调试流程

1. 确认是哪一层违反了其契约
2. 追踪第一次非法状态转变
3. 修复约束，而不是症状

如果只修复症状，系统会产生新的问题。

工具不如姿态重要

人们常常问我推荐哪套技术栈。

我的诚实回答：
约束严格的平庸栈胜过边界薄弱的完美栈。

我希望更多技术文章能说的

• 复杂性并未被解决——它被管理
• 干净的代码是干净决策的副作用
• 发货是一个设计问题

如果你从这篇文章中只记住一点：

设计你的系统，使得未来的你能够安全地与过去的你产生分歧。

结束

制造并不在于工具。工程并不在于聪明才智。
它在于构建能够经受现实检验的系统。

如果这引起了你的共鸣，我将更深入地探讨以下内容：

• 约束驱动的 UI 架构
• 创始人级别的技术决策
• 无畏的故障设计

感谢阅读。