共计 2831 个字符，预计需要花费 8 分钟才能阅读完成。
深刻应用 Kotlin 后的感触
之前写过一篇对于 kotlin 较为粗略的感触，简略的形容了一下 kotlin 的几个长处，例如对空对象的判断等。
在通过一段时间对 kotlin 的摸索后，我发现这些长处远不是 kotlin 的全副，于是再深刻的写一篇对于 kotlin 的应用感触。
最近一个我的项目，开始全面的应用 kotlin 这门语言，也有了更多的机会去体验 kotlin 的新个性。
大量应用 kotlin 的感触就是，每当在设计一个问题的解决方案时，你突发的独特灵感都可能被 kotlin 满足，能极大的进步你的编程体验，这是之前应用任何语言都未成有过的感触。
可能被设计的代码
kotlin 的应用，让我感觉本人不是被语言所操控的，你本人就可能操控语言自身。
当你须要设计本人的工具时，kotlin 对你的帮忙是微小的，它能让你随时随地发明进去一种好用的独特的，又不会让你感觉突兀的工具。
例如，当你厌倦了上面这种写法时
val isError = true
if (isError) {throw Exception("")
}你能够
fun Boolean.ifThr(message: String) {if (this) {throw Exception(message)
}
}
val isError = true
isError.isThr("")从此你就领有了一个间接通过 Boolean 对象抛出异样的工具。
或者你还想在抛出异样时，打印一个日志。
fun Boolean.ifThr(message: String, func: (() -> Unit)? = null) {if (this) {func?.let { it() }
throw Exception(message)
}
}
val isError = true
isError.isThr("") // 不打印日志，间接抛出
isError.isThr("") { // 打印日志，并抛出
log.error("")
} 你甚至能够让 Boolean 值为空的时候，可能不加判断的执行抛出异样。
fun Boolean?.ifThr(message: String, func: (() -> Unit)? = null) {if (this == true) {func?.let { it() }
throw Exception(message)
}
}
val isError :Boolean? = null
isError.ifThr("")也能够扩大 List 的办法，判断一组后果是否全为 true。
fun List<Boolean>.allTrue(): Boolean {
this.forEach {if (!it) {return false}
}
return true
}下面一个办法展现了好几种个性，他们单个应用或者威力不大，但当组合起来时，你会诧异于它的表现力、便捷性之强，可能让你的代码在大量缩小的同时，兼顾到可读性、优雅实现、实用性的联合。
这就是 kotlin 弱小的中央，如果你违心，你能够先优雅的设计，再优雅的编码。
当然，优雅只是一个副产物，它真正的作用是。
让你以一种低成本的形式，设计出一种编码模式，可能帮你更好的解决掉业务需要实现的细节，从而专一于业务需要的实现，大量缩小逻辑谬误的产生，同时显著升高纠错老本。
编码过程不再被打断
你可能遇到过这样一种状况（以 elasticsearch 为例）
val searchRequestBuilder = SearchRequest.Builder()
.source {it.filter { it.includes("id") }
}
.index(modelIndexNames)
.query(query)
.sort {it.field(FieldSort.Builder().field("id").build())
}
.size(10000)
sort?.let {searchRequestBuilder.searchAfter(it) }
searchRequestBuilder.build() 你能够看到，本来 SearchRequest 的设计思路是应用过程间断不中断的，然而一旦碰到两头须要判断的中央，就不得不打断这一过程，尽管不影响整体性能，但可读性稍差一些。
能够优化成上面的写法
val searchRequest = SearchRequest.Builder()
.source {it.filter { it.includes("id") }
}
.index(modelIndexNames)
.query(query)
.sort {it.field(FieldSort.Builder().field("id").build())
}
.let { searchRequestBuilder ->
sort?.let {searchRequestBuilder.searchAfter(it) }
searchRequestBuilder
}
.size(10000)
.build()这样，一段在 java 中必然会被打断的代码，在 kotlin 中可能被晦涩的写进去。
应用过程中的疑虑
在我看来，kotlin 浑身都是长处。
然而随着我对 kotlin 了解和写法上的深刻，我开始逐步放心起来。
每当我写了一些 kotlin 的高级写法时，我并不确定这些写法能不能够被高级工程师齐全排汇或者了解。
当然这也可能仅仅是业务逻辑简单的缘故，简略需要不会应用那么多高级个性，与其放心语法问题，不如放心其他人能不能了解其中的业务逻辑。
次要想探讨一下将来
我认为 kotlin 相对有被宽泛承受的资格，在绝大部分场景上来齐全的替换 java 不是问题。
然而在我将这个我的项目齐全 kotlin 化的过程中，联合我目前所处公司的见闻和一些网上的论坛所看，我对于国内编程行业的可能大规模使用 kotlin 这个将来，并不是很乐观。
首先就是，我认为国内的大厂自身，java 大规模合作的代码业余程度的确不高，至多不是顶尖程度，在我刚开始工作头两年，被网上阿里巴巴 java 开发手册所吸引，感觉国内大厂出品不会差，自身这个手册也没什么问题。
直到 2021 年，我开始深刻框架序列化，钻研 fastjson 时，我才开始明确，流传度高的货色并不一定就是好的。在我目前写这篇文章时，github 上 fastjson 的 star 数量是 24.9k，而 jackson 只有区区的 7.6k。
连阿里巴巴自家的 nacos 我的项目都不应用 fastjson，当然 nacos 的源码比 fastjson 好一点，然而和国外顶尖的开源我的项目比，还是差了很多。
在国内呢，前有百度这种曾经躺平的搜寻平台，后有 gitee 这种一开始叫码云蹭热度，页面设计很落后，莫名其妙塞了很多性能的国内第一开源平台。
让我不得不有这种乐观的忧愁，期待着这样的互联网公司构建的技术环境推动新事物，是十分艰难的。
更别提在很多小公司外部，对于技术不求进取，只求疾速实现需要，没有内部大型互联网企业的推动，接触新事物就更加艰难了。
然而我还是抱有一些心愿，心愿当前得国内环境诞生出一个酷爱技术的环境，不再被固有思维解放，勇于探索新的境界。
