一年一篇
又到了一年一篇时间了，今年真的有很多话想要说，也经历了很多很多很多，这些事是我在2013年完全想不到的。
但是没想到，我还是做了！
学习，学习，学习
阅读和写作
流水账事件到了，当然是先列出书单了：
- Groovy in Action
- Apache Cordova 3 Programming
- 卓有成效的程序员
- 程序的未来
- Java程序员修炼之道
- 打造Facebook
- HTTP权威指南
- 深入理解JAVA虚拟机
- Spring实战
- Java并发编程实战
- Effective MySQL Replication Techniques in Depth
- Mybatis
- Hibernate
- Java解惑
- Maven实战
- AngularJS实战
- Java核心技术
- Java NIO
- Netty in Action
没什么特别的，如果你非要我推荐的话，那我一定会推荐《Java并发编程实战》，读过此书，如获珍宝！1/3都是有价值的书，而另外2/3真的，已经忘记内容了。
另外学习的方式也有了一些改变，看了一下在线课程。学习一些新东西看视频教程还是会更快一点的，国庆用了几个小时看了一个 AngularJS 视频教程，很快就会上手写了。
博客也一直在写，每年的量都差不多，坚持原创，一个月1-2篇。
技能学习
今年下半年开始，我从原来的部门转到了架构组，开始了一段新的工作状态。所有的工作内容也发生了质的变化。
就在这个过程中，我的 java 水平真的是有了突飞猛进，现在自己的 java 水平已经远超 C# 了。
这半年来主要学到的有这几个方面：并发、JDBC、Socket、NIO
以前总觉得这几块是高深莫测，因为做业务根本不会碰这些东西，用用框架就行了。而半年的实践后发现，花时间钻研后，这些也都没有那么难。 可如果还在原来的部门，可能我真的永远不会去触达这些东西了… 想想就很可怕！
忽然想到了雷军的那句话：站在风口浪尖上猪都能飞。
所以，这也是我今年最想说的：我为什么想到风口浪尖去和我怎么到了风口浪尖。
最初的梦想
还记得三年前的校招 VP 面，VP 问我将来的目标是什么？为了实现目标还要做点什么？
进入 DP 后，每次做总结老大也都会问我你的目标是什么，还缺什么，后面要怎么做？
我的答案一直是希望可以深入技术，往架构师努力。
以前我一直觉得这个答案不需要质疑，这就是我的答案。
直到换岗的那段时间，我和各个 Leader 沟通的时候，有人问了我一个问题： 你真的觉得那边（架构组）更好吗？那边真的有你想要的东西吗？他们做的都是用户看不见的东西，做好了没人知道，做烂了就被人骂，你会有成就感吗？
这几个问题非常好，也正好让我思考了一下，经过一番思考后，我的答案是：是的，我就是想要这个。
其实做业务和做架构没有孰优孰劣，真的是个人喜好的问题。
有的人不关心技术细节，把各种框架用的非常熟练，分分钟就能做出一个可用产品，得到用户们的一致好评。这是他们的成就感。
有的人就喜欢去扣技术细节，出了问题非要去搞明白底层原理，大部分时候可能用不上他们，但是一旦遇到诡异问题别人忙的焦头烂额的时候，只要他一出现，分分钟便解决了。这是他们的成就感。
所以，被这么一问后，我还是坚持我的梦想。不，应该说是更坚定了我的梦想。
梦想不易
一开始进公司为什么没直接追随梦想呢？
原因主要就是当时学的是 .Net，这边只有一个部门在用 .Net，而且当时想要一直做 .Net 的，所以便呆在了业务部门。
工作之初，对于一个应届生来说，真的是每天都有各种收获，但时间久了我也慢慢地发现在时间和稳定性的压力下，你不得不去使用各种你熟悉的东西，不得不去又快又好地做出东西来。
所以到最后也无非是对某些东西更熟练，了解更深入罢了。遇到了难题，上班时间你也根本没时间去深入研究，也只能网上搜一下解决方案，改个配置或者用别的方式绕开就结束了。
这里好像一个死循环：因为“工具”差所以效率低，因为效率低所以没时间学习使用新的“工具”，因为没时间使用新的“工具”所以只能用原来的“工具”。
难道就要一直这样子下去了？
这里，我真的是非常感谢我以前大部门的 Leader 和最开始小团队的 Leader，他们俩会和我做各种总结，和我聊未来的规划，告诉我应该怎么做，提醒我还差什么。
我长久以来的积累离不开他们的帮助！
我也特别敬佩这样的 Leader，因为他们以我个人意愿和未来为重。他们一定知道，如果我做好了将来一定会离开业务团队，而且学得越快走的越早。
最后如果你问我：现实残酷，梦想不易，如何做到？
那我就会回答：首先一定要做好本职工作，这是你的口碑，一屋不扫何以扫天下；然后利用空余时间学习，积累。努力去打破那个死循环！
为什么是在 2014
非常庆幸 DP 能有换岗机制，因为很多人的离开不一定是不爱这家公司了，换个部门依然可以找到真爱。
虽然这看上去会造成一个团队损失一名人员，但这种人员流动最终会让合适的人到达合适的岗位，发挥出更大的价值。
而且这种换岗的成本真的比离职重新招人低多了。
我选择在今年做这件事情是没有任何计划的，我完全是被逼出来的。
2014 年一开始，发生了很多很多事情：
第一件大事就是部门拆分，Leader 更换，这里的细节我就不吐槽，心受委屈了，不会再爱了。
第二件大事就是团队中，我喜欢的三位小伙伴分别换岗、离职了，这个团队基本上也不再有值得我学习的榜样了。
所以这里也没任何值得我留恋的东西了。
虽然我一直想着将来要换岗，但是我一直没计划做这件事情。因为在 2014 年之前，我整体的工作情绪是非常好的；另外，我也一直觉得自己还没准备好，毕竟 java 刚学没多久，心里没底气。
所以，2014 年初发生了一系列看似灾难的事情，反而把我逼上了绝路，这也是为什么是在 2014 的原因了。
新岗位日常
肯定有很多人想了解一下这边的工作状态是怎么样的，那就来一段新岗位日常吧：
早上过来打开电脑，把相关新闻，技术文章看一遍。
打开监控，如果最近上过项目，那把最近上过的项目看一遍。 必须做到无任何疑点，如果有任何疑点就必须排查。例如 GC 多了，某个日志多了，某个日志少了。 任何现象必须是可以被解释的，如果你自己都解释不了，很有可能会有问题。
这里没有产品经理，没有 QA，没人催你进度，和 Leader 定完大方向后，细节基本都是小团队（我们是2个人）自己把控。
然后自己有一份计划，每天和按照目标去做。每周和 Leader Review；小团队内部时时刻刻都在交流和讨论方案、进度、成果。
这边思考的时间远多过实干的时间，代码写了一会儿停下来思考一下很重要。这么做真的好吗？还有更好的吗？很多细节可能会被推倒重来好多次。
对了，工作的同时也要常常关注着我们的客服群，因为整个公司的开发都是我们的“客户”，所以他们有了问题就要去帮忙解决。 有些是一句话搞定的，也有些是要过去直接帮人家 debug 才能解决的。
最后，一整天就过去了。“什么？你们不开会吗？你们没邮件吗？”，这边会议的确非常少，邮件也非常少。 因为一个中间件从头到尾就两个人；一个项目从上到下涉及的人也都是个位数，沟通成本超级低。
另外，除了有节奏地工作了一天外，还有很多无节奏（不是无节操…）的日子。 半年内有那么几周，为了排查隐秘的 bug，花了一周多；为了阅读老项目的源码，花了两周多；为了写一个项目而花了一周多时间去学习新的东西。
要是放到从前，我这么干的话肯定完蛋了，一周没产出啊！你这是不想干的节奏吗？所以以前这种事只能“偷偷”回家做。
总体来说，这里的工作状态比我之前的理想多了。
因为这里所有东西都把控在你手中，不像业务部门成败往往和技术无关。
然后就是这里没有 deadline，做东西也不再会被催着赶着了，因为一旦时间紧程序员都会用上他们的法宝（不写单元测试，开发完自己不验证，复制粘贴代码等等）。 现在做东西考虑的主要就是质量、性能、稳定。所有的项目都有完善的单元测试，自己还要编写自动化测试脚本，在这边没 QA 的情况下，我们半年内上的很多大规模项目都没出过影响业务的 BUG（小 BUG 还是会有的）。
我不是把之前团队做项目的方式批判地一无是处，但在这块也应该改进一下。我知道以前的团队是想要快：敏捷开发、快速迭代、快速试错。 但是最后大家也都看到了，真的敏捷吗？你们真的是在迭代吗？快速试错都试了几年了还在试？理论知识竟然成了无能的替罪羔羊了。
最后整个项目毁掉了就又启动一个新的项目把原来的从头再做一遍。然后还是那么快，什么都没想清楚就快马加鞭地做起来了。 几个月以后一个残缺的新项目上线了！又可以出去邀功了！我们用了新技术，我们用了新架构，太 NB 了，比以前的好多少多少！但是时间有限还不太稳定，有些功能还没实现，大家体谅一下。
这真的是太可笑了！
2014 年的不足
因为环境的变化，我也发现了一些新的问题。
新的环境中，我可以把研究工作在工作时间完成，所以回家后再去学习和研究的时间少了很多。我不知道现在对我来说是好事还是坏事。 虽然没有答案，但是还要继续去思考，直到想明白为止。
还有一个问题是新的环境没有产品经理给你安排任务了，被蹂躏习惯后，忽然有那么一点点不习惯了呢。 当手头工作完成后，我缺少那种自己去找问题解决的能力，这是我后面需要好好锻炼的一个能力！
最后，祝大家新年快乐！
本作品由 Dozer 创作，采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可。