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

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

代码审查不仅仅是一种形式或发现错误的方法。它是知识共享和提高代码质量的关键过程。在 Kotlin 中，凭借其富有表现力的语法和强大的功能，审查需要特别关注细节。在本文中，我们将分析在检查 Kotlin 代码时应注意什么，以及如何提供有用而非冒犯性的反馈。

1. 检查什么：Kotlin 开发者清单

开始审查时，不要试图一次性涵盖所有内容。最好按关键类别逐一进行。以下是 Kotlin 的结构化清单。

1.1. 空安全与可空类型的使用

Kotlin 解决了 NPE 问题，但前提是开发者不滥用 !!（非空断言）。这是主要的危险信号。

• 检查内容：在生产代码中使用 !!。几乎总是可以用 ?.let、?:（Elvis 操作符）或安全转换 as? 替代。
• 不良代码示例：

fun processUser(user: User?) {    val name = user!!.name // 潜在的 NPE！    println(name)}

• 良好代码示例：

fun processUser(user: User?) {    user?.let { safeUser ->        println(safeUser.name)    } ?: run {        println("User is null")    }}

1.2. 集合与 Stream API 的使用

Kotlin 提供了丰富的集合操作函数。检查它们的使用是否高效且可读。

• 检查内容：在可以使用 map、filter、groupBy 的地方使用多余的 for 循环。以及如果可以使用不可变集合（List）却使用了可变集合（MutableList）。
• 不良代码示例：

val names = mutableListOf<String>()for (item in items) {    if (item.isActive) {        names.add(item.name)    }}

• 良好代码示例：

val names = items    .filter { it.isActive }    .map { it.name } // 不可变列表

1.3. 扩展函数与作用域

扩展函数是一个强大的工具，但很容易在项目中“分散”。检查它们的使用是否恰当。

• 检查内容：改变对象状态的扩展函数（尤其是当这种改变不明显时）。那些本应是类方法，但为了“美观”而写成扩展函数的代码。
• 向作者提问：“为什么这是扩展函数，而不是 User 类的方法？”

1.4. 使用 when 替代 if-else

Kotlin 鼓励使用 when 作为冗长 if-else 链的更可读替代方案。

• 检查内容：包含 3 个及以上条件的 if-else 阶梯。应将其替换为 when。

// 替代方案：if (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }

// 更好的方式：when (status) {    Status.ACTIVE -> { ... }    Status.PENDING -> { ... }    else -> { ... }}

2. 如何提供反馈：从批评到协作

技术部分只是成功的一半。另一半是沟通。糟糕的反馈可能会打击团队士气。良好的反馈可以增强信任。

2.1. “为什么，而不是什么”原则

不要只说“这很糟糕”，而要解释为什么它糟糕以及如何修复它。

• 糟糕的反馈：“这里用了 !! —— 重做