回顾2016，寄语2017、2018

回顾2016

职业生涯中的2016年是一个让人百感交集的年份。

2015年底，我来到了现在的这家公司，鉴于刚开始只是做一些杂七杂八的东西，所以2016年才算得上真正意义上的第一年。

这一年的时光，依据工作内容大体可以分为三段。

第一段：EAMS系统数据流方案改造研究
EAMS系统是一个电子档案管理系统，其管理的档案便是各个业务系统和各类产品的电子数据。
电子档案数据的大体流程涉及：源业务系统Mysql库 -> 源业务系统大数据平台 -> EAMS系统对应的大数据平台 —> EAMS系统对应的Mysql库
该流程虽然采用是常用的标准流程，但是存在两大不足之处。
1.随着对接的业务系统和产品越来越多，EAMS系统的Mysql库肯定会膨胀得越来越大，这必将抬升数据的存储成本，而且会降低数据的查询性能。
如果增加EAMS系统Mysql库对应的数据清理策略，那这将会影响到数据的查询效果。
虽然档案查询为低频操作，但我们的数据对象是重要的档案数据，是专门另外保存下来以便将来查验的，所以对数据的全面性则有一定的要求。
2.整个数据流程虽然采用的是标准的数据流程，但是对接大量的业务系统，而各个系统数据推送的时间又有很大差别，所以数据的实时性得不到保证。

基于上述两大不足之处，考虑裁减和缩短数据流程。
四个数据流程节点当中可以考虑合并最后两个节点，或者干脆合并后三个节点。
基于数据的隔离性考虑，选择合并EAMS系统端的两个节点，接下来则是依据实际应用场景研究选择最佳的技术实施方案。

参照常用的搜索引擎方案，初步筛选了Impala、ElasticSearch、SolrCloud三种方案。
由于在Impala方案中，对硬件内存有一定的要求，而且存在查询失败的可能性，所以首先排除。
ElasticSearch、SolrCloud是当下最流行的两种搜索引擎方案，大体能满足我们的改造需求。
Elastic、Solr两种技术均源于Apache Lucene，只是后续发展各有侧重。
SolrCloud方案是传统的企业级搜索引擎解决方案，而ElasticeSearch方案是新近流行起来的互联网级别的搜索引擎解决方案。
两种技术方案表面上看起来不相伯仲，所以得从他们的实现原理、实践部署、性能优劣以及与应用程序之间的交互性方面进行深入研究和比较。
最终选择了SolrCloud方案。
虽然ElasticSearch方案实践起来更简洁、易上手且性能更好，但是最新版本的ElasticSearch不支持查询已有HDSF文件中的数据，只能将HDFS文件作为快照文件备份数据。
而SolrCloud方案，虽然性能略逊于ElasticSearch方案，但是作为一款成熟的企业级搜索引擎方案，其足以满足我们查询需求。最为关键的是它可以直接查询我们现有HDSF文件中的数据，最大程度兼容已有系统。

说实在的，这次数据流改造研究对于我来说，可以算做一次尖端技术探索之旅，它带给了我一些不同于撸码的感觉。
第一次积极的去探索一些未知的东西，那些未知的东西确实让人有些小畏怯。
刚开始的拦路虎便是全英文参考文档，自打毕业之后，我的英文阅读能力算是荒废了，而这次不得不强迫自己去重拾对英语的信心。虽然刚开始步履维艰，但到后来也能从容应对。
接着是各种前沿技术，大数据的各种关联技术，像是打开了一扇知识的天窗，我看到了里面各种高大上的技术，虽然知道了自己的无知，但却很高兴，因为认识到自己无知的同时也找到了自己的方向。
原理学习，集群部署，外部交互，性能测试，应用开发……

虽然探索的过程中小畏怯一直如影随形，但是探索出来之后的感觉却是爽、很爽、非常爽。
那种学习后有所收获的满足感，大大的满足感，这才是作为一个幸福程序猿的真谛与追求。
当下次再遇到这种技术方案研究的课题，我想我不会再有小畏怯，但成长的满足感却会依旧伴随而来。

知道了自己的不足，明确了自己的方向。
大数据应用、架构设计！

第二段：EAMS系统功能需求开发
这一阶段则是EAMS系统正常的需求功能开发。谈需求，定功能，然后撸码开发，接着测试、发布，还有各种Bug修复、迭代开发……
功能需求说不上复杂，技术难点也没有多少。至少对于一个快三年工作经验的程序猿来说，没有什么问题是搜索引擎解决不了的。

唯一能拿得出来说道的便是系统权限体系的改造。
起因源于用户管理中心(UM)想要集中管理所有系统的用户数据。
当然不止是对应的用户数据，还包括用户对应的角色数据、角色对应的权限数据等。
解析EAMS系统现有的权限控制体系，分析实际应用场景中的权限控制需求，梳理调整现有功能权限控制模块，
参照UM提供的权限体系框架模型，设计出合理的EAMS新权限体系框架。

对比“低智”的功能需求开发，这种自下而上的体系设计与开发更对我的胃口。
这需要细致的了解，深入的思考，良好的设计，谨慎的开发……
而不是一股脑的撸码。

这段时间也还算有些收获吧，不过与之前的工作相比，还是有蛮大落差的，所带来的满足感也远远不够。
不过另一方面，却是有足够的时间来学习公司内网上的一些技术文档，拓宽自己的技术和知识面。
但是，这样整天通过看文档来学习新技术新知识总感觉不够深刻和全面，毕竟书上得来终觉浅。

第三段：EAST系统数据脚本开发
一天，很突然的，Boss找我谈话。
原来另一个项目组进度吃紧，想调我过去支援。
刚开始没多想，既然Boss安排，还特意征询我的意见，自然没有拒绝的理。

紧急抽调支援，自然没有轻松的理，加班，加班，再加班，加得昏天暗地，加得思绪耗尽……
加班也就算了，关键是所做的工作内容一点儿也没有成就感、满足感。
撰写数据脚本，进行相应数据处理，生成符合指定格式的数据。说白了就是对数据进行ETL操作。
数据脚本有固定的格式，主体是一些数据处理的SQL，SQL复杂不到哪里去，更谈不上性能优化啥的。
技术含量低，自然没什么成就感。更何况还需要苦逼的加班赶工，情绪低落到无处发泄却又不得不坚持下去。
这对于一个底层程序猿来说，真是莫大的痛苦！

这个项目唯一的收获便是沟通能力的提升了。
由于对接多个业务方，自然沟通频繁。
谈数据需求，定数据接口，反复验证修复，历史数据追批兼容，都是靠一场场会议，一通通电话给谈清楚谈明白的、

虽说有收获（沟通能力的提升），但总感觉有些自欺欺人。
或许是我程序猿思维太重，毕竟这个项目带给我的收获感和成就感没有之前的那么大。

总结：
2016年于我而言，是一个很特殊的年份。因为这一年的7月份，是我正式踏入职场的三年届满之期。
虽然这三年我一直在很努力的提升自己，但很惭愧，至今仍感觉到以自己现有的技术实力还不足以带给我安全感和自信心。

回想2015年7月辞职旅行之前，自信满满，摆脱了毕业后初入职场的迷茫，积累了初步的专业能力以及职场素养，对自己的未来有清晰明了的规划。
一转眼踏过三年之期，经历了第三个项目的折磨，一切自信便烟消云散了。
伴随着自信心的逐渐弥散，焦虑感却与日俱增。
对于程序猿的职业生涯来说，三五年，七九年是个很尴尬的时间节点，如果没有足够的积累与成长，那种不安全感便会一直如影随形。
只有两种选择：要么就此逃避，沉醉于已有的能力与环境，从此被环境推着走；要么主动冲出迷茫和困境，重新踏上追寻自信的道路。
还好，我熬过了焦虑感对我的折磨。
在无数个日夜的折磨中，对于目标和方向的思考与追索也变得愈发清晰，接下来便是迈开双脚，阔步向前进了。

职业素养：
提高工作效率
提升沟通能力（尤其是与上级之间的沟通能力）
主动承担责任
深入理解工作
积极反馈情况
让周围的人感受到与你合作很愉快
积极彰显自己（平时太过低调）
积极参与讨论
积极参与分享

专业能力：
Java基础能力（自我项目实践）
高并发多线程
设计模式学习
Spring原理
Mysql、Oracle
Shell、Python
大数据应用
架构设计

寄语2017、2018

我一直渴望快速成长，像海绵吸水式的快速成长，但现实一遍遍的打击我，告诉我这不可能。
虽然这三年走过来，成长也有，困惑也有。但成长的步伐总不及自己的心理预期，成长的困惑却周而复始。
成长的是，现在所用的技能和知识都是这三年学到的。
困惑的是，为什么成长那么慢？为什么对自己都没有安全感？我何时能成为一个大牛一样的存在？

“这十年中我至少浪费了五年时间，这五年可以足够让自己成长为一个优秀的程序员，可惜我错过了，我用这五年时间和很多程序员一样在困惑和迷茫中找不到出路！
以前我一直被公司和技术牵着走，并不是自己在选择技术，而是不自觉地被推到了这个位置上。……”
这是一位大牛的自我总结，他觉得自己浪费了很多时光。
但我觉得，他也是幸运的，被公司和技术牵着走，走着走着成为了大牛。
有的人，却一直陷在困惑和迷茫当中，找不到出路，也没有什么人牵引着他们走出来。

2017、2018是我职业生涯的第四年、第五年。我知道这意味着什么，对于一个程序猿来说，接下来的两年将面临一个很艰难的坎。
很多人利用五年的时间从一个菜鸟炼就成了一个厉害项目经理，更多的人利用五年的时间成为了一个技术达人，不过也有人一部分人始终在原地踏步。
我希望两年后，再回首现在，自己得到的不会是那最惨的结局！
所以，从现在开始，我不能再陷于困惑和迷茫当中，我要努力去追赶，去弥补之前因为迷茫所浪费的时光。

我知道自己从不缺乏主动学习的精神，但自我感觉却始终收效甚微，
或许是成长的节奏还没有到达质变的临界点，仍需继续积累量变；
或许最好的成长方式是“被动”+“主动”，被环境推着压迫着快速成长，然后依靠自身的主动，调整成长的节奏和步伐，始终走在环境的前面。

自我努力很重要，成长环境也很重要。
但无论如何，
要想不被某个空间所束缚，那你就必须和时间赛跑！在赛跑的途中，练就一身行走天下都不惧的本领！