避免不必要的任务配置

在迁移过程中使用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用于延迟配置 a Project，因此将延迟配置与新 API 混合可能会导致难以诊断的错误，因为使用新 API 注册的任务并不总是被配置，但afterEvaluate可能总是期望执行一个块。

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

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

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