開始接觸 Gradle 的原因

身為一位 Kotlin 開發者，每天需要接觸的就是 JVM 生態系的工具。相依管理一直是各個程式語言都得處理的基本需求，而建置工具更是 Java、Kotlin 這類編譯式語言不能少的麵包與奶油（Bread and Butter）*。在 JVM 生態系裡，相對比較多人使用的建置工具有 Gradle、Maven、sbt…等。

不過自從 Google 的 Android 團隊選擇 Kotlin 及 Gradle 這個組合，而 Kotlin 團隊也針對 Gradle 推出 Kotlin DSL 的寫作風格後，許多 Kotlin 開發者（包括後端）都開始轉而使用 Gradle 做為他們的建置工具。

筆者開始接觸 JVM 生態系的時間相對較晚，對過往的工具已難恭逢其盛。因此在一開始學習 Kotlin 時，就決定使用 Gradle 做為主要的建置及相依管理工具。不僅可以滿足自己在後端開發的需求、同時也能將經驗延伸到 Mobile 開發上。

Gradle 的入手難度

Gradle 很棒！至少看別人使用起來好像都很順，但自己使用時卻完全不是這麼一回事。我原本以為這是因為接觸時間不長導致，但問過身邊開發圈的朋友後發現，原來我不孤單，不少開發者都跟我一樣掙扎於 Gradle 的入手難度。

Gradle 真的有這麼難嗎？我覺得這是因為 2 個原因：

1. 太過強大：雖然 Gradle 的原始目的是一個建置工具，但 JVM 生態系對建置工具的需求不僅止於此，從相依管理、各式自動化指令以及為了共享而有的外掛系統，再再提高了 Gradle 的複雜度。

2. 使用 Groovy 語言：Gradle 是用 Groovy 實作的。雖然 Groovy 程式語言也是 JVM 家族的一員，但畢竟不是主流大眾熟悉的語言。對於一位 JVM 開發者來說，除了要熟悉自己專案使用的語言外，還要多接觸一個相對陌生的語言，無疑又再次墊高了 Gradle 的入門門檻。

令人羞恥的壞習慣

雖然我們都知道把生產力工具摸熟、摸透的重要性，但往往就敗在短缺的時間及人類的惰性。

所以即便我知道應該花時間把 Gradle 官方文件好好翻一遍，把所有設定、指令都搞清楚，但往往屈服於時間壓力及惰性，最後都是在 Google 或上 StackOverflow 找別人的答案胡亂貼一把，出錯了就再換一個答案直到可以解決問題為止。

其實內心非常清楚，與其花時間找「可能的答案」，這種重覆試誤所花掉的時間，累積起來其實都足夠自己好好把 Gradle 說明書看完一遍。在深切的反省之後，我問自己，還要用這種「瞎子摸象」的方式多久？

不，我想做出改變！

我想好好把 Gradle 搞清楚，就算我不見得能 100% 搞懂 Gradle 底層原理的實作細節，但至少 build.gradle.kts 裡的每一行我要清楚知道它的作用，當別人請我解釋時，我要言之有物。

你遲早要把 Gradle 搞清楚的，為什麼不現在就做呢？

如同愛因斯坦所言：「假如你不能用很簡單的方式來闡述一個觀念，那表示你並不是真的理解這門知識。」抱持著相同的理念，我覺得一邊學習一邊就把剛學習到的知識整理並教給別人，是一個讓自己快速成長的捷徑。

在這 30 天的鐵人賽裡，我將從一個新手小白的觀點出發，從 Gradle 在 JVM 建置工具裡的角色、環境及安裝設定、常用指令等基礎開始，接著會以幾個常見的實務情境為範例，實際使用 Gradle 來完成任務，以及如何客製 Gradle Task，讓 Gradle 可以幫我們做更多瑣碎的小事。最後，也會討論擴充 Gradle 的方式及 Plugin 架構。期望透過 30 天的努力不懈，重新把 Gradle 學好。

希望大家在看完這個系列文後，可以抬著頭跟別人說：「Gradle 我也略懂略懂（挑眉）」。

筆者註

• 「Bread and butter（麵包與奶油）」在英文的意思裡指的是每日不能少的生活需求。