“简单胜于复杂。复杂胜于繁琐。——Python 之禅”

你是否曾盯着你的 TypeScript 代码，心想：“肯定有更好的办法”？

我每天都这么想。

作为一支不断壮大的团队的资深开发人员，我目睹了我们的代码库逐渐变成一个由可选链和问号构成的迷宫。但问题是，我们遵循了所有的“最佳实践”。

那么，为什么感觉这么不对劲呢？

问题：问号引发的混乱

让我们看看一些代码。这看起来熟悉吗？

这看起来还算正常，对吧？只是一些安全的属性访问。

但是等等。让我们放大来看。

这是我们的类型定义：

看到那些问号了吗？每一个都在说：“也许这个存在。也许不存在。”

我们以为我们很小心。很有防范意识。很安全。

我们错了。

隐藏的代价

这种“安全”的代码让我们付出了代价：

• 时间（大量的时间）
• 精力
• 对无错误的信心
• 开发者的理智

但最糟糕的是？

我们甚至不需要那么多的“安全措施”。

灵光一闪💡

在一次代码审查中，一位新团队成员问道：

“为什么我们把所有东西都设为可选，而每个用户都需要这些设置？”

沉默

更长时间的沉默

然后我恍然大悟。

我们不是在用类型来定义我们的需求。我们是在用它们来表达我们的恐惧。

解决方案 - 类型即需求

这是我们所做的改变：

注意到了吗？

没有问号。

没有也许。

只有清晰、明确的需求。

那默认值呢？

我们把它们都放在一个地方：

现在我们的应用程序代码变得美观了：

干净。简单。清晰。

“但是那……”

我听到你的疑问了。现实中的代码是混乱的。以下是我们如何处理常见的挑战：

1. API 响应

外部 API 是不可预测的。我们在边界处理它们：

2. 确实可选的数据

有时，数据确实是可选的。明确表示：

3. 部分更新

更新需要灵活性：

结果？比预期更好

• 代码审查速度提升 50%
• 新开发者上手时间从几周缩短到几天
• 运行时错误几乎为零
• 开发者满意度大幅提升

想试试这个？

从小处开始：

• 选择一个功能
• 列出其真正的需求
• 创建没有问号的类型
• 添加明确的默认值
• 见证奇迹的发生

重要的教训

TypeScript 的类型系统不仅仅是为了捕获错误。

它是为了讲述故事。

确保你的类型讲述了正确的故事。

接下来？

这种模式改变了我们的代码库。但这只是冰山一角。