避免不必要的任務配置

在遷移期間使用 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 註冊的任務時，無法呼叫 Project.afterEvaluate()。由於 afterEvaluate 用於延遲配置 Project，因此將延遲配置與新 API 混合使用可能會導致難以診斷的錯誤，因為使用新 API 註冊的任務不一定總是配置的，但 afterEvaluate 區塊可能總是預期執行。

遷移影響所有任務的任務配置 (tasks.all {}) 或按類型劃分的子集 (tasks.withType(…​) {})。
這將導致您的建置急切地建立較少由外掛程式註冊的任務。

遷移依名稱配置的任務。
這將導致您的建置急切地建立較少由外掛程式註冊的任務。例如，使用 TaskContainer#getByName(String, Closure) 的邏輯應轉換為 TaskContainer#named(String, Action)。這也包括透過 DSL 區塊進行的任務配置。

將任務建立遷移到 register(…​)。
此時，您應該將任何任務建立（使用 create(…​) 或類似方法）變更為改用 register。