避免不必要的任务配置

在迁移过程中使用 help 任务作为基准。
help 任务是衡量迁移过程的完美候选者。在一个仅使用配置避免 API 的构建中，构建扫描 显示在配置期间没有创建任何任务，并且只创建了执行的任务。

仅在配置操作中修改当前任务。
由于任务配置操作现在可以立即、稍后或从不运行，因此修改当前任务以外的任何内容都可能导致构建中的不确定行为。请考虑以下代码

val check by tasks.registering
tasks.register("verificationTask") {
    // Configure verificationTask

    // Run verificationTask when someone runs check
    check.get().dependsOn(this)
}

def check = tasks.register("check")
tasks.register("verificationTask") { verificationTask ->
    // Configure verificationTask

    // Run verificationTask when someone runs check
    check.get().dependsOn verificationTask
}

val check by tasks.registering
val verificationTask by tasks.registering {
    // Configure verificationTask
}
check {
    dependsOn(verificationTask)
}

def check = tasks.register("check")
def verificationTask = tasks.register("verificationTask") {
    // Configure verificationTask
}
check.configure {
    dependsOn verificationTask
}

优先考虑小的增量更改。
较小的更改更容易进行健全性检查。如果您破坏了构建逻辑，分析自上次成功验证以来的更改日志将更容易。

确保制定了验证构建逻辑的良好计划。
通常，简单的 build 任务调用应该足以验证您的构建逻辑。但是，某些构建可能需要额外的验证 - 了解构建的行为并确保您拥有良好的验证计划。

优先考虑自动测试而不是手动测试。
使用 TestKit 为您的构建逻辑编写集成测试是一种良好的做法。

避免按名称引用任务。
通常，按名称引用任务是一种脆弱的模式，应避免。虽然任务名称在 TaskProvider 上可用，但应努力使用来自强类型模型的引用。

尽可能使用新的任务 API。
急切地实现某些任务可能会导致其他任务级联实现。使用 TaskProvider 有助于创建间接层，防止传递实现。

如果您尝试从新的 API 的配置块访问某些 API，则可能会被禁止。
例如，Project.afterEvaluate() 在配置使用新 API 注册的任务时无法调用。由于 afterEvaluate 用于延迟配置 Project，因此将延迟配置与新 API 混合可能会导致难以诊断的错误，因为使用新 API 注册的任务并不总是被配置，但始终预期 afterEvaluate 块执行。

迁移影响所有任务（tasks.all {}）或按类型划分的子集（tasks.withType(…​) {}）的任务配置。
这将导致您的构建急切地创建更少的由插件注册的任务。

迁移按名称配置的任务。
这将导致您的构建急切地创建更少的由插件注册的任务。例如，使用 TaskContainer#getByName(String, Closure) 的逻辑应该转换为 TaskContainer#named(String, Action)。这也包括 通过 DSL 块进行的任务配置。

迁移任务创建到 register(…​)。
此时，您应该将任何任务创建（使用 create(…​) 或类似方法）更改为使用 register 代替。