马上就要过年了，回顾一下2016的成长。
简述
- react全家桶太复杂，不能听任大厂任意吹逼，缺点也是技术选型的关键；
- spring boot隐藏的细节有点多，不看文档不知道的东西太多；
- checkstyle, findbugs和sonar都是好东西，帮助你写出bug free的代码；
- Intellij很好很强大，经常更新版本吧，惊喜不断；
- 使用依赖注入时，不要用field injection，应该配合lombok使用constructor injection；
- rabbimtq是用来处理CPU密集型的场景，不适合IO密集型的场景；
- GC的核心是如何做到异步的GC，以及自动调优，期待G1；
- java不适合做客户端应用，如android。GC严重影响使用，只能期待程序员好好写代码；
- 同理go不适合写android。引申，go不能做android开发的话，就不会持续的发展；
- 正确学习java的路径：语法>基础>集合>io>多线程>内存模型>GC>JIT>JVM。
先说前端
2016年的前端应该是前端开发的元年了。这一年发生了好多。。。我从来没想过做专职的前端开发，我不喜欢js这个语言，不喜欢css。但是我不排斥开发前端。毕竟作为最直接的交互界面，前端是很重要的。这一年有一段时间一直在搞前端，用了react全家桶。。。总感觉facebook很不负责任的说，大厂吹的很好听，但是一旦入坑就不是那么回事了。react的难点在于如何一开始构建一个框架，全家桶里的东东实在太多了。。。影响开发体验。不过框架搭起来就好了，模块化代码还是挺好的体验。但是我写前端的时间越长就越排斥前端。心中bgm是：哎，只要把xxx做成xxx就行了，可是好烦啊，不想搞啊，asfjoqwekfhnjr…..还是赶紧搞定去搞别的吧。。。还是喜欢写java。
java
曾几何时，我还是挺不喜欢java的。那时的我还是php神，嗯，PHP is the best language!现在不那么想了，java真的是能接触到的最优秀的语言，而且是最能提升自己对整个计算机系统理解能力的语言。java足够高层，可以对实现做抽象，同时java又足够底层，可以让你放手去实现底层的构建，这一切都需要你去深入到os、cpu、内存中去，去窥探那个奇妙的世界。几个月前开始订阅java社区开发的邮件，期间逐渐证实了我之前的一个猜想——java做了太多努力在跨平台上。跨平台绝对是黑科技！因为跨平台不仅仅跨的是操作系统，还在跨cpu。java要针对不同的os和cpu去订制实现，真的是订制！现代cpu想跑的快，硬件上只能多加core，软件上尽可能的在单个core上完成任务，每个core都有自己的寄存器，实现新的reorder、barrier，但是多线程编程一定要跨线程上下文，阻止reorder，合理的打开barrier。不同的os和cpu有各自不同的实现标准，然而java却要综合所有平台的特性，一再强调跨平台。如果一上来，没有把跨平台作为java 的首要特性，我相信java一定会发展的更好，不过话说回来，如果没有点噱头，估计java都活不下来。
我觉得2016年，我真的是跌跌撞撞地把java打通关了，我可没说我精通，但是精通是早晚的事，2017年差不多可以，2018年以后我就可以放开手脚研究os和硬件了。我发现学java最好的途径还是读specification和官方文档。thinking in java、effective java、JCIP都是很优秀的书，但是有一个问题，这个问题特别像是读技术博客。在博客中，博主对技术的阐述，只是自己的理解，等到读者再读的时候，那仅仅是读的博主的理解而已。这些优秀的技术书籍只能帮助你理解java，但是本质上那都是作者们自己的理解以及他们的宝贵经验。想要了解java真实的一面，还是要下狠功夫读晦涩的说明和相关论文。
一个理论
关于技术，今年我还得出了一个理论：对于客户提出的需求，如果程序员认为这个需求要超过3天才能完成，有三种可能：
- 需求不合理，不是说不能做，只是不合理，比如设计的功能不应该包含在该系统A当中，应该放在系统B上；
- 系统架构不正确；
- 程序员没能力。
这个理论是我从自身出发，并参考其他同事的日常工作得出的结论。需求肯定永远都是对的，只不过提需求的人多种多样，很有可能用户没有受过专业训练，用户其实并不理解自己真正想要的是什么。这种问题慢慢沟通，提供自己的建议就好。第二种可能是灾难性的，架构上缺乏思考，扩展性不够，程序员的锅啊。今后可能因为这个问题出现各种各样的bug，慢慢你就是救火队长了。第三种情况很微妙，很少人会承认自己的能力上限。特别是在工作中，有kpi考核呢。平常开玩笑的时候可以说说，你不行啊，你个弱鸡，你没能力啊。但是大家都是码农，有些事不必戳穿。
要做正确的事
我经常说：要做正确的事。不论是做人，还是做技术。做技术的没有不踩坑的，踩坑了不怕，就看你怎么走出来，怎么解决问题。经常说，哎呀，系统出bug了，要是想彻底修好应该从底层xxxx，但是这样太费时间了，还是先hotfix一下吧。。。我觉得这时候就是体现一个程序员能力的时候，这时候就应该分析清楚应该怎么解决这个问题，然后贯彻执行力，解决这个难题，只有不断的自己跟自己较劲，技术才能不断提升。有时候在修很恶心的bug 的时候，我也很想放弃，换个捷径走，但是我自己是知道的，这个时候恰恰是提升自己能力的时候。因为你在做你不熟悉的事，而做不熟悉的事是最能锻炼人的，你在突破你的瓶颈，冲出你的舒适区。
代码质量
Dijkstra曾经说过一句很有意思的话，大意是：
测试只能测试出测试出来的bug，但是不能测试出没有被测试出来的bug。
那怎么才能找到那些藏在代码中的没能被发现的bug呢？
不断的看自己写的代码，不断看别人写的代码，这就是一个重构的过程，你总会发现之前想的不周到的地方，开发不是一蹴而就的。而是不断迭代不断重构的过程。程序员不应该把功能开发完之后就万事大吉了，后面随便测测就再也不看了。出了bug甩给别人那简直就是可耻了。。。
最后
自己还有很多不懂的地方，2016再见，2017加油！做一个快乐的傻缺技术男。。。