TypeScript在微控制器上：嵌入式开发的革命

轻松学习Python，无需理论负担。在浏览器中直接解决带自动检查的实践任务，无需安装任何东西。

引言：为什么你的 TypeScript 代码审查看起来像控制面板上的红灯？

你是否曾经提交过一个拉取请求，一小时后收到了一位高级开发者的20条评论，其中一半以"这里可以做得更好"开头？听起来很熟悉吧。如果你用 TypeScript 编写代码，但你的代码仍然让同事想要从头重写——这篇文章就是为你准备的。

在 PythonLib，我们经常遇到这样的情况：开发者即使知道 TypeScript 语法，也会犯同样的错误。这些错误不会破坏代码，但会使代码变得不可读、不安全且难以维护。今天，我将向你展示高级开发者在TypeScript 代码审查中常写的10条典型评论，以及如何避免它们。准备好重构吧！

1. "Any"——你的敌人，不是朋友

在任何 TypeScript 代码审查中，最常见的抱怨就是使用any。写const data: any = await fetch(...)似乎比处理类型更简单。但高级开发者会将其视为一个危险信号。

糟糕的写法：

function processUser(user: any) {  console.log(user.name.toUpperCase());}

良好的写法：

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

为什么这很重要？如果你使用any，TypeScript 就失去了所有意义。你实际上是在禁用类型系统。如果数据来自 API——创建一个接口。如果类型很复杂——使用unknown并加上检查。这是主要的TypeScript 最佳实践之一。

2. 忽略严格模式

许多项目在tsconfig.json中禁用了严格模式，因为"这样更快"或者"类型很烦人"。高级 TypeScript 开发者会立即注意到你的代码没有检查null和undefined。

糟糕的写法 (strict: false)：

function getLength(str: string) {  return str.length; // str 可能为 null，这会导致崩溃}

良好的写法 (strict: true)：

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

提示：在你的tsconfig.json中启用strict: true。这会迫使你编写更安全的代码。在TypeScript 代码审查中，这会是加分项，而不是减分项。

3. 类型魔法：过度复杂

有时开发者试图炫技，编写出连高级开发者都要挠头的类型。例如，使用嵌套泛型的条件类型，而简单的接口就能解决问题。

糟糕的写法 (过度工程化)：

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

良好的写法 (简洁)：

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

高级开发者重视代码可读性。如果你的类型可以用一个包含三个字段的接口替代——那就这样做。不要不必要地复杂化。

4. 错误的错误处理

在TypeScript 代码审查中一个典型的错误是使用了any的 try-catch 或者空的 catch 块。高级开发者会立即指出这一点。

糟糕的写法：

try {  const data = await fetchData();} catch (e) {  console.log('Error');}

良好的写法：

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('未知错误', error);  }}

为错误使用unknown。这是