下载掌阅APP，畅读海量书库
立即打开
当我们第一次将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的特性进一步简化代码。但所有这些都是在迈出最初的一小步之后才能开始。