避免不必要的任务配置

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

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

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`。