避免不必要的任務設定

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

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

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

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