避免不必要的任务配置

在迁移过程中使用 help 任务作为基准。
help 任务是衡量迁移过程的完美候选。在一个仅使用配置回避 API 的构建中，构建扫描显示在配置阶段没有任务被创建，只有被执行的任务才会被创建。

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

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

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

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

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