面试题答案
一键面试代码结构方面评估可维护性
- 层次清晰:代码应具有清晰的层次结构,例如MVC、MVVM等架构模式。如果不同功能的代码相互混杂,比如视图逻辑与业务逻辑大量耦合在同一个类中,可维护性就差。例如在一个Activity中既处理复杂的UI渲染,又进行网络请求和数据处理逻辑,这会使代码难以理解和修改。
- 类与对象职责明确:每个类和对象应该有单一、明确的职责。若一个类承担过多不同类型的任务,像一个“万能类”,既要负责文件读取,又要进行数据库操作,还要处理用户界面交互,可维护性就低。
函数设计方面评估可维护性
- 单一职责:函数应只做一件事,这样的函数易于理解、测试和修改。如果一个函数既要验证用户输入,又要进行复杂的业务计算,最后还更新数据库,一旦其中某一部分逻辑需要修改,整个函数都可能受到影响,可维护性差。
- 参数简洁合理:函数参数数量不宜过多,过多参数会增加函数调用的复杂性和出错几率。例如一个函数接收超过5个不同类型且关联不大的参数,调用者很难清楚每个参数的用途,可维护性不佳。
模块划分方面评估可维护性
- 高内聚低耦合:模块内部的功能应该紧密相关(高内聚),模块之间的依赖关系应该尽量少且简单(低耦合)。若模块之间相互依赖复杂,牵一发而动全身,如模块A大量依赖模块B的内部实现细节,当模块B发生变化时,模块A很可能需要大幅修改,可维护性差。
- 功能完整性:每个模块应该提供完整的、独立的功能。如果模块功能不完整,需要依赖其他模块的非公开实现来完成任务,会增加维护成本。
辅助度量可维护性的工具或技术
- SonarQube:可以分析代码的复杂度、重复代码、潜在的Bug等指标,通过设定规则来评估代码的可维护性。例如它能检测出一个类中方法数量过多、方法复杂度超标等问题,帮助开发者发现可维护性风险。
- Ktlint:这是Kotlin的代码格式化和 lint 工具,通过强制执行一致的代码风格,使代码更易读,间接提升可维护性。它可以检查出代码缩进、命名规范等问题,不符合规范的代码可能影响可维护性。
可维护性差的Kotlin代码表现举例
- 超长函数:一个函数代码行数几百行,包含多种不同逻辑,没有合理拆分。例如:
fun complexFunction() {
// 复杂的用户输入验证
var input = readLine()
if (input.isNullOrBlank()) {
println("输入不能为空")
return
}
// 复杂的业务计算
var result = 0
for (i in 1..100) {
result += i
}
// 数据库操作
val connection = getDatabaseConnection()
val statement = connection.prepareStatement("INSERT INTO table (value) VALUES (?)")
statement.setInt(1, result)
statement.executeUpdate()
connection.close()
}
- 深度嵌套的条件语句:多层if - else嵌套,逻辑难以理清。例如:
fun nestedIf() {
val a = 10
val b = 20
val c = 30
if (a > 5) {
if (b < 25) {
if (c == 30) {
println("满足所有条件")
} else {
println("c不满足条件")
}
} else {
println("b不满足条件")
}
} else {
println("a不满足条件")
}
}
- 缺乏注释和文档:代码逻辑复杂但没有任何注释说明,他人很难理解代码意图。例如:
fun mysteriousFunction() {
var num = 1
for (i in 1..10) {
num *= i
}
println(num)
}
这里的函数实现了阶乘计算,但没有注释很难看出意图。