2.1 策略

當我們第一次將Kotlin代碼引入Java代碼庫時，我們還只是一個小團隊中的成員，團隊包括6個開發人員，正在建立一個“綠地項目”（譯者注：指全新項目）。我們已經用Kotlin部署了一些Web應用，但我們的企業架構師堅持用Java 8編寫新系統。那是在Kotlin 1.0發布后不久，但在谷歌宣布Kotlin成為安卓的官方語言之前，所以架構師對一個預計會存在幾十年的戰略系統選用一種前景不明的語言持謹慎態度，是可以理解的。

在Java中，我們傾向于采用函數式方法，將核心應用的領域模型設計成可由管道轉換的不可變數據類型。然而，我們不斷遭遇Java的局限性：實現不可變值類型所需的冗余性（樣板代碼）、原始類型和引用類型之間的區別、空引用以及Streams缺少常見的高階函數。與此同時，我們看到Kotlin在整個行業甚至公司內部的采用率都在不斷提高。當我們看到谷歌宣布Kotlin成為安卓的官方語言時，我們決定開始將Java代碼轉換為Kotlin代碼。

我們判斷從核心領域模型起步會給我們帶來最大的收益。Kotlin的數據類大大縮減了代碼，在某些情況下，只需一個聲明就能取代數百行代碼。我們小心翼翼地開始，使用IntelliJ轉換一個小小的值類型，除了標準庫中的類之外，它沒有依賴其他類。我們還檢查了這對Java代碼庫其他部分的影響，最后發現它完全沒有影響。在這次成功的鼓舞下，我們加快了步伐。每當一個新功能需要改變Java領域模型類時，我們就會先將其轉換為Kotlin數據類，提交轉換后的代碼，然后再實現功能。

隨著越來越多的領域模型邏輯變成純Kotlin編寫，我們便能夠更好地利用Kotlin的特性。例如，我們用Kotlin中關于集合和序列的標準函數取代了對Streams API的調用。但最大的改進是用可空引用取代了對Java Optional類型的使用。這簡化了我們的代碼，使我們對空指針的安全性信心倍增。

公司的另一個項目采用Kotlin是出于不同的原因。公司有一個成熟的Java系統，建立在一個依賴注入框架之上。開發人員發現，該框架對反射和注解的使用使得代碼在IDE中難以理解和瀏覽，而Kotlin的輕量級閉包語法提供了一種方法來定義應用程序的結構，并從對象圖中區分出哪些是為整個應用程序實例化的，哪些是為每個HTTP請求或每個數據庫事務實例化的。我們逐步重構了系統的底層框架，從一個架構層次隱晦的框架轉變成一種由函數組成并使架構在代碼中可見的風格。這項工作導致產生了后來的http4k（https://http4k.org）網絡編程工具包。

正如這兩個例子所示，你對起點的選擇應該取決于很多因素，包括團隊為什么要采用Kotlin，代碼庫有多大，以及代碼庫的變更頻率。了解你的項目并決定什么是最重要的改變。

如果你選擇Kotlin是因為它的語言特性，那么你將最常使用的類進行轉換是有意義的，就像我們在第一個項目中所做的那樣；如果你選擇Kotlin是為了使用一個特定的庫，那么針對其API編寫Kotlin是有意義的，為了方便你的Kotlin代碼被應用程序其他部分的Java代碼使用，對它進行注解，然后從那里繼續。

在小的團隊中，很容易為系統建立Kotlin編碼風格（比標準風格指南更進一步），例如錯誤處理約定、如何組織代碼的文件結構、什么應該是頂級聲明、什么應該在一個對象中等等。

但當團隊超過一定的規模時，你就會面臨Kotlin代碼變得不一致的風險，因為人們會在系統的不同部分建立自己的約定。因此，也許更適合從一個小的子團隊開始，在系統的一定范圍內工作，建立約定并建立一個樣本代碼庫。一旦有了一些既定的約定，你就可以把這項工作擴展到團隊的其他成員和系統的其他部分。

我們將在本書的其他部分詳細研究如何開展這項工作、如何在引入Kotlin代碼的同時保持Java代碼的可維護性，以及如何在IntelliJ完成其轉換操作后利用Kotlin的特性進一步簡化代碼。但所有這些都是在邁出最初的一小步之后才能開始。