TypeScript 中的代码审查：检查什么以及如何提供反馈

TypeScript 中的代码审查：检查什么以及如何在实际中提供反馈

代码审查不仅仅是一种形式，更是提升代码质量的强大工具。在拥有丰富类型系统的 TypeScript 中，审查尤其有效。在本文中，我们将分析检查 TypeScript 代码时应注意什么，以及如何提供有用且不伤人的反馈。所有示例均基于真实代码。

1. 类型和注解：避免使用 `any` 并严格化

在 TypeScript 代码审查中，首先映入眼帘的是类型。TypeScript 旨在编译阶段捕获错误，因此 any 是一个危险信号。

检查什么：

• 是否存在 any。 每个 any 都应有正当理由。如果是从 JS 迁移，可以接受；但在新代码中则不行。
• 类型的正确性。 不要在需要 enum 或 union type 的地方使用 string。
• 过度类型化。 TypeScript 能够推断类型。不要写 const x: number = 5，而应写 const x = 5。
• 严格设置。 检查 tsconfig.json 中是否启用了 strict: true、noImplicitAny、strictNullChecks。

糟糕代码示例：

function processData(data: any) {  return data.name.toLowerCase();}

如何修复：

interface User {  name: string;}

function processData(data: User): string {  return data.name.toLowerCase();}

如何提供反馈：

不要直接说“你用了 any，这不好”，而要说：“这里的 any 关闭了类型检查。让我们定义 User 接口——这能提高代码的安全性和可读性。”

2. 处理 null 和 undefined：strictNullChecks 能救命

Cannot read property of undefined 错误是经典问题。TypeScript 配合 strictNullChecks 有助于避免此类错误，但前提是开发者正确处理了可为空的值。

检查什么：

• 在访问属性前检查 null/undefined。
• 使用可选链 (?.) —— 现代且安全。
• ! 运算符（非空断言） —— 仅在 100% 确定值不为 null 时使用。最好替换为显式检查。
• 正确使用 ??（空值合并运算符） 代替 || 来设置默认值。

糟糕代码示例：

function getCity(user: User | null): string {  return user!.address!.city; // 危险！}

如何修复：

function getCity(user: User | null): string {  return user?.address?.city ?? 'Unknown';}

如何提供反馈：

“这里使用 ! 有风险——如果 user 为 null，会抛出错误。让我们改用 ?. 和 ?? —— 这样既安全又可读。”

3. 泛型和工具类型：不要无谓地复杂化

泛型是一个强大的特性，但很容易过度复杂化。审查者应关注灵活性和可读性之间的平衡。

检查什么：

• 过度复杂。 如果泛型只使用一次，可能并不需要。
• 正确使用 extends —— 限制泛型，避免它们接受任何类型。
• 工具类型（Partial、Pick、Omit、Record）—— 使用它们可以简化代码。
• 返回值类型 —— 带有泛型的函数