Kotlin中的Code review：检查什么以及如何给新手提供反馈

Kotlin中的Code review：检查什么以及如何提供反馈

Code review（代码审查）不仅仅是一种形式，更是提升项目质量和团队成长的强大工具。对于Kotlin新手开发者来说，审查过程常常令人恐惧：“万一我漏掉了bug怎么办？”，“如何告诉同事他的代码写得不好？”。在本文中，我们将探讨审查Kotlin代码时需要注意什么，以及如何提出既有帮助又不伤人的意见。

我们不会教你语法基础——假设你已经能用Kotlin编写代码。相反，我们将重点关注新手代码中常见的典型问题，以及如何在不破坏团队氛围的情况下提供反馈。

1. Null safety 与可空类型的处理

Kotlin以其类型系统为傲，该系统在编译阶段就消除了大部分NullPointerException。然而，新手经常滥用 !!（非空断言）运算符，或者错误地处理可空值。

检查什么：

\n
• 是否在没有充分理由的情况下使用了 !!？如果你看到 something!!，可以问作者：“你为什么确信这里不会是null？也许最好使用 ?.let 或 ?:？”
\n
• 通过 ?. 进行的调用链是否处理得当？例如，user?.address?.city 是安全的，但如果需要city，最好使用 ?: 来提供默认值。
\n
• 是否忘记了在使用前初始化 lateinit var？检查所有lateinit字段是否在首次读取前确实会被初始化。
\n

// 糟糕的写法\nfun getUserCity(user: User?): String {\n    return user!!.address!!.city // 存在NPE风险\n}\n\n// 良好的写法\nfun getUserCitySafe(user: User?): String {\n    return user?.address?.city ?: "Unknown"\n}\n

如何提供反馈： 不要说“你写了糟糕的代码”，而要说：“这里可能为null，我们改用安全调用替换!!，以避免运行时崩溃。” 提供替代方案——这能起到教学作用，而非批评。

2. Kotlin的惯用写法：集合、作用域函数和密封类

Kotlin不仅仅是“另一种语法的Java”。许多新手写Kotlin时仿佛还在用Java：使用 for 循环而不是集合函数，忘记 apply、let、run，并且不使用 sealed class 来表示状态。

检查什么：

\n
• 是否使用了集合函数（map、filter、firstOrNull）而不是手动循环？这能让代码更简洁、更易读。
\n
• 是否存在多余的临时变量？例如，val result = list.filter { ... }.map { ... } 比拆分成三步并使用可变列表更好。
\n
• 是否使用 sealed class 来表示需要处理所有情况的层次结构（例如Result、UiState）？这是现代Kotlin项目的强制性要求。
\n

// 糟糕的写法（Java风格）\nfun getEvenSquares(list: List<Int>): List<Int> {\n    val result = mutableListOf<Int>()\n    for (i in list.indices) {\n        if (list[i] % 2 == 0) {\n            result.add(list[i] * list[i])\n        }\n    }\n    return result\n}\n\n// 良好的写法（Kotlin惯用写法）\nfun getEvenSquaresIdiomatic(list: List<Int>): List<Int> {\n    return list.filter { it % 2 == 0 }.map { it * it }\n}\n

如何提供反馈： 指出具体的惯用写法：“可以用filter + map代替for循环，这样更简短、更清晰。需要我给你演示一下吗？” 不要强加——建议讨论。

3. 架构与可测试性

即使项目很小，code review也是检查