避免不必要的任务配置

在迁移期间，使用 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，则这些 API 可能会被禁止。
例如，在配置使用新 API 注册的任务时，不能调用 Project.afterEvaluate()。由于 afterEvaluate 用于延迟配置 Project，因此将延迟配置与新 API 混合使用可能会导致难以诊断的错误，因为使用新 API 注册的任务并非总是被配置，但 afterEvaluate 块可能总是被期望执行。

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

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

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