前言Kotlin是开发服务器端应用程序的理想之选，可以让您编写简洁而富有表现力的代码，同时保持与现有基于Java的技术栈的完全兼容和流畅学习曲线：表现力：Kotlin的创新性语言特性，例如支持类型安全的构建器和委托属性，有助于构建强大且易于使用的抽象。这是kotlin推广网站上对这门语言的介绍的节选。IntelliJ作为最懂程序员的公司推出了kotlin语言。使用一段时间后，我觉得kotlin有资格对得起这个评价。非常适合开发服务端表现力兼容java强大易用通过这段时间对kotlin的探索和理解，想表达一下自己对kotlin改造对个人和企业的意义。转型第一步：学好java如果你是一个对java语言不是很了解的新手，不建议一开始就深入了解kotlin的工作原理。kotlin语法本身就是对java中很多写法的封装，将java繁琐的写法转化为简洁的kotlin写法，最后将kotlin转化为java类。举个简单的例子：valstr=user?.id把上面简短的kotlin语句转化成java，即：Stringstr=nullif(user!=null){str=user.id}最后kotlin还是有回到上面的java。Java本身支撑着一个庞大的生态。绝大多数企业和开源库还在使用java进行开发。kotlin要做到与java本身的最大兼容并不容易。在可以预见的未来，java依然是开发界的基石，有着不可替代的地位。所以，作为一个真正的kotlin语言学习者，java还是一门必修课。转型第二步：用心理解kotlin。对于一个刚刚接触kotlin的用户来说，各种符号和关键字的使用绝对是一个不小的阻力。如果你想快速了解kotlin真正的强项，那么你必须了解kotlin为什么要这样做？为什么kotlin使用问号“？”在写java的过程中最常见也是最难的就是处理空指针问题。对于一个系统的输入，为了考虑鲁棒性，需要定义哪些变量可以为空，哪些变量不能为空。当变量为空或者不为空的时候，怎么处理，上游代码给我的变量到底是不是空的。相信只要是考虑问题比较全面的程序员，写代码的时候都会有这样的顾虑。kotlin的目的是为了消除程序员的后顾之忧。第一个目的是在源头上直接控制变量是否为空，让程序员放心，在每一步写代码的时候，我的变量肯定不会为空。如果它是空的，我已经有解决方案了。第二个目的是对可能为空的变量进行非常友好、简单和可读的处理。varuserName=user?.name//当user不为空时，将属性name复制到变量userNameuser?.let{//当user不为空时，打印name属性的值println(it.name)}user？。name?.let{//当user和user.name不为空时，打印name的值println(it)}?:println("nameisempty")//否则输出name为空user?.name="kotlin"//当用户不为空时，可以在这里暂停给属性赋值，想想java中如何实现这样的逻辑。这种写法足以让任何一个在java中多次处理过空指针问题，或者代码运行一段时间就莫名其妙出现空指针异常的程序员留下深刻印象。如果kotlin吸收了stream，如果你是一个对程序编写有一定追求的程序员，相信你不会错过jdk1.8语法中的stream和lambda。当我想将List中V的一个属性作为key转换为Map时，stream已经提供了一种非常简洁的写法：Mapresult=choices.stream()。collect(Collectors.toMap(Choice::getName,Function.identity()));java已经很简洁了，但是每次想做这样的操作都得翻遍代码或者上网搜索用法每次。当你用过kotlin方法后，相信你永远不会忘记它的写法：valresult=choices.map{it.nametoit}.toMap()对于一些复杂的stream写法，你可能需要知道java是怎么写的改成了kotlin，不过一般的写法只需要你把stream()删掉就行了。可以说kotlin已经完全吸取了stream的精髓，在此之上，蓝胜于蓝。忘了lombok和getsetlomok是java世界里不可忽视的补充力量。他让简单的getsetdefinition不再被程序员所需要，但同时其对类的直接修改也让很多深入使用它的程序员为之诟病。归根结底还是java中封装的概念，控制了有限字段的暴露。因此，在kotlin中，不再有getset的概念，只有赋值和直接获取，只需要使用关键字private、val、var就可以实现控制字段的可见范围。验证名称：字符串？=null//可以获取，不能修改varname:String?=null//可获取，可修改privatevalname:String?=null//不能获取，不能修改springboot中也常用lombok注解@RequiredArgsConstructor可以用简单的构造函数直接生成字段来代替。lombok本身的注释对kotlin代码无效。切换到kotlin时，去掉lombok也是水到渠成的事情。少即是多当你能理解kotlin的三个主要用途并运用自如，那么你至少会节省三分之一的代码。在代码的世界里，少即是多。减少冗余代码，就是为自己争取开发时间，降低出现问题的概率，提高出现问题时排查问题的速度。这可能是kotlin日积月累为程序员积累的真实经验。转化的第三步：实践。当你成功被kotlin简洁干练的语法所吸引，并征得团队中进步人士的同意，当你希望用kotlin替换它时，请注意kotlin是完全兼容java的，不仅仅是kotlin的努力方向，责任在于用户。更换本身是令人愉快的。之前的代码在你手中被一行一行地缩短，每一个空指针判断都在被一个简洁的问号代替，但是风险也在一步步增加。更换的每一步都要准备充分。对于回归测试，没有人能预料自动java-to-kotlin代码转换器是否可以让逻辑推理如此严密。在替换的过程中，可能会遇到java接口中的java静态方法不能很好的兼容kotlin的默认方法，以及mybatis中无法应用到mapper接口的各种意想不到的困难。但在这些困难的背后，解决的意义远大于困难本身，所以是值得的。现代语言中kotlin和swift3kotlin语法的诞生不是偶然因素，而是代码不断发展的必然结果。对比一下kotlin和swift3，你会发现两者惊人的相似，或许是因为两种语言的设计者有些重叠。但这些重叠点并不是世世代代人使用后积累的产物。总会有人会不断追求更高效、更便捷、更快捷的开发方式。这些方法也将不断被现代语言所吸收，这些优点最终会保留下来，直到新一代计算机的出现。展望kotlin的未来，希望kotlin语言能够被更多的人、更多的企业所接受。对于个人来说，不一定非要使用kotlin进行开发。需要接受的是，kotlin在设计过程中总结了闪闪发光的思路，不断要求自己在原有的java技能上进行提升。对于企业而言，降低错误成本、错误率和开发时间始终与效率有关。了解kotlin带来的价值并合理应用是重中之重。同时，也希望kotlin本身在未来能够更上一层楼，不再以java作为中间语言，而是可以一步到位，有自己的编写、编译、编写体系。跑步。
