什么2017还是看2018
去年年末看到好多小伙伴在写年终总结，有关生活的，有关工作的，对来年(2018)的展望的，没有丝毫的想法，不知怎的没有动笔的冲动。直到今天(开年第一天上班)，头哥给大伙开了个会，讲了很多关于工作上的规划和以及每个人在团队里的定位，内容很多，并不能完全消化，但确实给了我很大的启发，让我动了写这篇总结的念头。
其实我一直是个有规划的人，大学四年的所有资料、文档、代码，我都会挨个儿根据科目、学期分文件夹。这一次，也要细细来讲，但并不想确保条理清晰。
虽然说是2017-2018，其实应该是2017的春节-2018的春节。那么，开始吧。
2017.3中
带着刚毕业的傲气，仗着笔试题简单，拿了个高分；面试时说话，人就有点飘了，还班门弄斧地“指点”了大风车的热补丁方案。现在想想真是蠢。因为当时的面试官就是我现在的师父。总觉得我那种绣花枕头一包草的形象已经在我师父眼里根深蒂固了。每每想到此处，都想跳槽跑路，真是没脸待下去了。
2017.3下
入职时刚好是无线部拆分成无线业务部和无线架构部的时候，当时还不知道有什么区别也不知道自己被分在架构部。后来才知道架构部都是大佬(除了我)，一般来说p级都是比业务组要高的。（后来还从测试同学那听来，测试同学都不太会给架构组同学提bug，因为都是大佬，说话都是恭恭敬敬的。）
那我可能是个假人。
刚入职可能想展现一下实力吧。师父给了我一个日期范围选择控件(自定义View)任务, 本来给了两周时间，结果我3天就完成了基本功能。但师父似乎并不怎么满意。后来证明，确实可扩展性太差了，业务组的小伙伴也反应这个组件太难用。这又是后话了。
2017.4
趁热打铁，分享了一波Android7.x新特性。因为原本在税友就分享过一次，这次分享得游刃有余，不仅介绍了新特性，同时还提到了多处兼容问题，需要在编码过程中注意的。而且都是大多是亲身经历，比较有说服力。
2017.5
年会。抽了个华米运动手表。用了半年左右，电池电量撑不了一天，废了。
正式接手聊天库。当时在做的需求是xxx(app名)的“xx交易2.0”。(比较讽刺的是，在后来的某个版本里，整个群聊交易系统都被砍了。)此时，聊天库至少经手了3个人的维护，我是第4个。未曾料想，我可能一不小心就成了这4个人里维护时间最长的维护者。
很膨胀，提了提前转正申请。也成功了。
2017.6-8
聊天库也不总是有需求，期间师父让我做了”图片加载包装库&webp”和”网络接口流量统计”。
前者，一直找不到好的处理方式，尤其是fresco使用的不是ImageView而是Fresco特有的SimpleDraweeView。不知该如何处理各个图片加载引擎的切换。我简单地理解成，包装好后不用关心当前使用的是什么图片加载框架，用相同的代码就可以实现图片加载。似乎并不是这么简单，但我想不到，我第一次感受到我的知识储备限制了我的能力施展空间。
后者，也做了几个月。让我较为深入地了解了http协议。学会了抓包和计算报文大小。本来测试都通过了。最终因为数据库相关的操作，被打了回来。后来说是修复好后，等下个版本再上。
2017.9
内推了女朋友。通过了笔试，技术面，hr面。在最后hr将要给offer的时候。
“你和内推人是什么关系？” “他是我男朋友。”
因为一句话毁了所有努力。
工作上不顺利，对公司制度也充满了失望。
2017.10
又是一波聊天、消息相关的需求。匿名xxx需求、进群xx通知、xx上拍播报、动态卡片定义、消息重新归类。这些没什么挑战性，也算是拾回了一些信心，却开始被一些外界因素所影响。杨总做iOS端开发，基本上跟我接的都是一致的需求。但他对工作的懒散态度，让我很不习惯。师父也教导我不要学他(杨总)，他(杨总)是要走(离职)的人。
2017.11-12
业务组那边有每周一次的代码review会议，每次都会叫上一名架构组大佬。这一次轮到了我，本来想好好参与其中，粗心的自己却犯了好几处错误，真是给我们架构组丢人。
易诚拍相关的业务，大佬们忙不过来了，扔了一小部分给我(和杨总)。分别是“xxx扫描”和“消息库接入xxx(app名字)”。有时候真的不是很好界定任务的归属，消息库确实没话可说，跟聊天库一起都归属于消息中心，所以消息库也归我维护，自然归我接入。但是行驶证扫描本就是业务组同学写的库，现在需要接入易诚拍，需要我在他的库基础上修改，这种改动有些不合常理。
又接到一个比较富有挑战性的自定义View的任务，日历任务管理(仿钉钉日历)。本来完成得挺好的，但是…说来话长。iOS端原本是杨总实现，但他找了第三方的日历控件，实现后无法满足业务场景，又因为要离职的事情。所以任务直接压到了成哥那边，成哥本来就有其他任务在身，也来不及自己实现，只好又找了一个第三方的日历控件(但比杨总找的好)，又自己实现了和RN的事件回调。而我对自己的能力还是很有信心的，所以一切从头撸。不过我的实现与他截然不同，导致了两端实现的控件在RN中使用时不统一，这我就很烦。我承认我的实现不够人性化，甚至有点Android布局的思想在里面。(正确的做法应该倾向于‘提供给RN使用’的角度去设计控件)。但是，我做的日历组件性能好啊~滑动开合毫无阻塞。也说不好两端不统一的情况下应该让哪一端改。不过我确实很不想改，毕竟辛辛苦苦实现了这么久，iOS端只是copy+paste。后来师父跟我谈心，提及此事，略加批评。我也认为做法不妥。改不改都该给个回音，不应该在上级要求改之后，并不改动也不向上级请示能否不改。凡事都可商量，凡事都该有个回响。
2018.1-2018.2
复活xxx聊天xxx·一期
又是消息中心的一个大需求。背景是大风车的微信机器人屡次被微信封杀，现在需要将机器人业务迁移到xxx(app名称)上。但是之前的聊天相关的业务都不成功。聊天中也存在很多bug。故一期主要是为了优化原来的聊天库。
前期开发很顺利。后期由于杨总的盲目乐观和不根据设计稿、需求文档开发，导致大家等他一个人修bug、打包。我也算尽心尽力提醒他了相关的注意点，但他似乎心不在焉。我无话可说，只是希望以后给我派个靠谱的搭档。
后来发现我想多了，因为杨总的离开和聊天库的业务化，聊天库将交给业务组打理。有点舍不得，毕竟维护了这么久。算了算了，先做完复活xxx聊天xxx·二期吧。一切向前看。
最后说几句
刚入职时，大搜车才B轮，结果在春节前已经完成了C、D、E轮融资，这融资速度有点惊人。但是对员工的福利的一点儿也没涨。年前发的年货还不如我在税友当实习生时拿的多；年后的开门红包也缩水严重(据同事透露，往年是今年的3倍)；还有亲属不得内推的规定也是让人恼火，一点也没有阿里系的大气作风。
2017一年工作上对自己的打击其实挺大的。一度认为自己待在大搜车没什么价值，不是没东西学，而且做了东西没什么用。
2018年，希望可以多完成一些有挑战性的任务吧。把失去的找回来！
