我在美图这几年

从2015年1月算起，我来美图已经快4年了。写这一篇文章，是希望对我在美图学到的东西进行总结,激励自己不要马齿徒增，一事无成。另一方面，希望给背景相似的同学一点参考,避免和我犯一样的错误。与君共勉。:)

蒙昧使我造Bug,责任使我成长

2015年1月来美图实习，在此之前我没有一点儿大数据经验，甚至没有多少写代码的经验。当时应聘的是算法岗位，1月～4月底，在陈力大神的帮助下，学习了awk、sed、grep这些工具和工程知识，完成了特征提取相关的文本处理和统计工作。因为有这一段经历，让我敢在小伙伴面前自称“shell脚本小能手”:P。5月回校写毕业论文。6月转岗数据架构。

我已经记不清领导们是怎么和我谈的了。事情大概是这么发生的：毕业论文的课题和微博有关，所以我需要利用爬虫采集数据写入到solr作数据准备。领导看到了问我："你还会用solr呀，看来动手能力挺强的嘛。"（领导真是很擅长鼓励人呢 :P）。就这样，转岗到了数据架构。当时也有考虑过两个方向哪个前景好,哪个更适合我。这个过程并不纠结，因为我是个萌新，啥也不懂，做什么对我来说都是挑战。数据架构看起来也很有意思的样子呢:)

在接下来的半年里，我变得忙碌起来。害怕一直写业务代码没有长进? 可能因为起点太低了，我没遇到这样的问题。可能因为部门组建初期，遇到的挑战多，除了写业务代码，还要兼运维、测试多职。可能因为领导比较负责，交待需求时也会引导思考容量规划、系统调优方面的问题。 比如基于storm和redis实时统计业务数据时，顺便学习redis key设计最佳实践、kafka consumer各参数的作用，storm通信组件disruptor...

压测、容量评估、关于Disruptor的组内分享、bitmap-query的第一个版本、离线统计、实时统计，这些东西对我来说都很新鲜。任务一到手就想马上写完，当时没有代码规范、上线规范、基础运维组件等。我常常跑偏，一边改bug一边造bug , 边学边做，晚上要背电脑回家，因为可能会收到线上告警。

萌新日常

蒙昧使我犯错，犯错使我学习，学习使我成长:P。如果在入行初期能养成良好的编码习惯能少犯错，少走很多弯路。入行第一年是精力最旺，好奇心最重的时期，积极地揽活使我获得更多实践机会。那时领导问过我一个哲学问题：“你不会有不想上班的时候吗？” ，当时还真的没有。能在自己喜欢的方向持续学习,并且解决一些难度逐渐增加的问题让我很有成就感。不仅没有不想上班，甚至可以说，是沉迷于上班。

从Implementer到Solver

2016年，是从Implementer到Solver的跨越。工作内容从"在既定的代码框架上实现上级交代的业务逻辑"变成了自己设计一些小项目。这一年造了些轮子，写了很多bug，也犯了很多错。
年初写了配置式通用离线统计组件，这个组件的初衷是解决类似"hive sql查询后把结果写到hbase"这一类重复性任务。因为看kafka源码学习了scala语法，尝到了scala语法糖的甜，我用scala实现了一个版本。结果是毫无疑问的。烂尾了。
bitmap-query的第二个版本，设计成JDBC+DSL的方式,完成语义解析和JDBC驱动,两个月后因为其它更重要的业务插入，最后也烂尾了。在这两个项目中，我犯了一些错误:

1. 过分独立的工作习惯，从不主动让别人参与和帮助。没有及时向上级汇报实现方案和进度,请求意见。如果多向别人请教能提早发现一些不切实际的想法。
2. 为了技术而技术: scala、DSL对我来说都是时髦的东西。但一个团队的编程语言的选型没有那么简单，单纯追求时髦的新语言新技术是不负责任的。程序的价值除了实现功能外还有可维护性、稳定性。但是除了我，没人愿意维护它们。
3. 缺乏对项目的准确估计和规划: 陷入设计细节中，写好一点是一点。没有明确的实现代价估计和规划。

这一路过得相当坎坷,让我明白了自己的代码写得有多烂。当时有一个梗:如果要计算每个人的行代码工资，我的行代码工资肯定是最低的。大概是说我的代码又长又臭吧:< ，往好的方面想，大概是我的同事都比我优秀吧:)。因为察觉了自己的代码质量堪忧，也因为部门开始重视规范。我总结了一些提高代码质量的方法，希望有参考价值：

1. 多看高质量的书：《敏捷软件开发》,《代码大全》，《代码整洁之道》
2. 挑选体量小、质量高又和工作相关的开源代码来学习。例如：jdk的Collection 、 logback、Flume
3. 多练习：模仿别人的例子,思考应用这些编码原则的理由
4. 和别人讨论：code review别人的代码,邀请同伴来帮你code review

可靠是最重要的品质

2016年中,数据中心迁移，迈了一个很大的步子。我们在迁移的同时升级了storm和kafka集群。这次升级重写了所有实时统计任务,封装通用的组件，用上了storm flux，为了兼容kafka 0.10, 自己实现KafkaSpout。

虽然做了很多调研和准备，但是还是出了问题。因为我在做代码兼容的时候没有测试完整,这一次迁移让我们看到了凌晨三点的厦门。

这一段经历让我明白可靠是一个技术人员最重要的品质。值得庆幸的是我有一群可靠的同事。因为我的过失，大家在公司守到凌晨，直到代码修复上线。得益于这个可靠、开放、包容的团队，我获得了很多试错的机会，野蛮生长。虽然说是金子都会发光，但我觉得环境对一个人的影响也不小。

发展软技能

2017年我开发了一个体量稍大的工程Arachnia。整个工程2人设计开发，从设计到全面替换旧日志采集器，断断续续花了大半年。项目完成后组织了一次对外的技术沙龙分享。一开始很抵触对外分享，原因很简单：怂和懒。我觉得工程部署上线了，开发工作就完成了，分享、写PPT都是虚的，花时间做这些事情性价比很低。何况Arachnia还有很多不完善的地方,当众分享也让人恐惧。领导们是这么跟我说的：1. 代码之外还有其它软技能 2. 你看那些创业者靠PPT融到了好多钱，说明这个软技能很重要 3.分享能提高个人的技术影响力和公司的影响力，从而吸引到更多优秀人才加入。还举了个例子:P。所以我去了。

分享后，有人加了微信问我：“为什么你的表达能力这么好？”。当时我对这个问题很惊讶,我觉得我的表达能力说不上好，但是一次良好的表现就能给别人“表达能力好”的错觉,真的很划算:)。我很想告诉他我的诀窍，但是做不到，因为我没有找到什么诀窍，只有笨方法。

沟通表达能力的范围太广，不太好量化，下面的总结只针对上台分享这一种场景中的表达能力提升。

1. 目标明确: 怎么叫提高，怎么衡量提高了多少？ 对于上台分享，可以定义为达到：讲话流畅(语速、语气、音量)、逻辑清晰(一页ppt只讲一件事、ppt衔接是否连贯)、动作自然(不要挠头、身体晃来晃去)
2. 刻意练习: 有了明确目标的基础上，针对上面的几点，刻意地练习，自己录音、录像，记录目标达成进度。
3. 寻求反馈：多做试讲，找有经验的人指导，并且随着进步修正自己的目标..
4. 遇到瓶颈时试着换一种方式 : 写ppt稿然后一张张ppt地背稿这种方式老容易忘词,练习起来非常慢,打击自信..改成多张ppt连着说，说错了也不重复，把所有ppt讲完再从头来一遍。程序员的自学能力都很强，希望每个人都找到最适合自己的学习方法:)。

分享上还有人问我：“你为什么成长得那么快？”，当时回答的大概是我觉得自己非常幸运，在美图快速上升的时期加入，同时团队给了我很多信任和机会。没有人在背后推我一把，我肯定完成不了。听起来很官方，但这是事实。

快速摆脱问题的方法

2017年是公司发展最快的一年，数据架构团队成员也快速增加,从10人到了28人，划分了数据平台、数据平台产品、数据基础、数据统计、算法工程五个组。有了数据产品经理，项目经理这些角色。2017年也是我发展最快的一年，我变成了“倩姐”，开始带人，参与招聘,开发Arachnia，参加技术沙龙。也是这种快让我有点无所适从。17年底领导告诉我产品经理和项目经理都不敢来问我进度，原因是我太暴躁了。手上的事情变得更多，越来越无法掌控。我甚至控制不好自己的情绪。被事情推着走，再也不是单纯写代码了。为了能更快速地“摆脱”问题，我总结出了一套方法。

• 明确拒绝: 举例: “kafka这个参数是什么意思，为什么我传了没用？” “不知道，你google看看？” "好吧，那你有kafka consumer的demo么？" "没有，你查下官网?" 如果再纠缠，可以用更暴力的方式:发脾气,把别人当成人肉搜索引擎是不尊重人的，可以不以礼相待。这样下次也不敢找我了。当然这种做法政治不正确，因为1. 总有求别人办事的一天,到时会很难堪 2. 有人来咨询说明对自己能力的认可，不帮显得格局小 3. 每个人都有当新手的时候，换位思考下是应该帮助的。 权衡下代价，酌情使用:P
• 拖延回复: 闪动的消息提醒背后可能有一个焦急等待的人,但事情或许没有看起来那么紧急。拿捏一下紧急程度，不要着急于解决眼前的问题。在自己忙得焦头烂额或专注于某项事务时，也容易表露出不耐烦的情绪,没法很好地服务:)。
• 给别人做: 你自己厌恶的工作对于别人来说可能没有那么难以忍受。如果自以为“己所不欲勿施于人”，最后只感动了自己，更可怕的是这么做可能剥夺了别人成长的机会。那些谁都不愿意干的活，能匀一下就更好了,毕竟老薅一只羊的毛,是会变秃的。
• 自动化/文档化/专业化：重复性问题写文档/让别人写文档， 培训/让别人培训。虽然这一步比较难，尝试和上级反馈，争取资源做自动化吧，万一实现了呢。

人微言轻，不是所有问题都能按自己的心意来解决, 遇到不如意的时候，只能调整下自己心态吧,沟通真的是一件很难的事情呢 :P

“不想做”和“不会做”

2018年，由于我对自身的职业发展没有规划和对自身专业水平的不自信，我陷入了自我怀疑。"自己变得不可靠了"，这种想法让我很难过。我知道应该要对自己的工作负责，但是不明白应该怎么负责。怎么和产品经理沟通、怎么和业务方沟通、怎么推进自己想做的项目、怎么做需求评审、怎么保证团队项目的质量和进度这些问题都让我很是头大。有段时间，我觉得自己要燃尽了。觉得不管我怎么努力，还是学不会，还是达不到很好的效果。

以前上过的一门宗教课说:藏传佛教的成佛过程是be-do-have,即找到适合自己的本尊，以本尊方式思考，最后你就会成为本尊，拥有本尊所拥有的。8月份之后,我看了很多书，希望能从更厉害的人那里得到“神谕”。关于整洁架构、敏捷开发、项目的估计与规划、有效需求分析、团队合作...大概有二十几本。我以为没有什么是我做不了的，做不了就装，装着装着就像了。但这不是一个励志故事，最后没有以“我成功得到了什么”为结尾。因为这些问题不像“如何开发一个数据库”、“如何学习JVM原理” 一样有非黑即白的方法和理论。看了那么多我还是很迷茫,想不明白是谁出的题这么的难，到处全都是正确答案。

为什么看了那么多方法论我还是学不会，为什么我工作得那么不开心，控制不了自己的焦虑情绪，我思考了背后的原因:

1. 道理都懂了，但是做不到。因为改变是需要时间的，没有一蹴而就的事情。
2. 不愿意冒险。但风险是长期存在的，“最佳实践”是不存在的。
3. 有些事情不需要理由,不想做就是不想做。

可能我需要的是Take it easy。没有人生下来就会做各种事情，分清楚“我不会”和“我不想”，果断一点吧，不要因为害怕做不好而拖延甚至放弃,同时也要接纳自己的"无能"。做不好不能说明我不行,可能还不够天时地利人和呢。 每个人都经历过迷茫期，很少人能坚信自己的选择是正确的。

最后

这一次离职也让我收获了很多建议，比如多抬头看看世界，不要沉迷于看书获得的假充实感，不要沉浸在自己的情绪里多和其他人沟通...希望大家都能得到心中所想，获得更多成就感。
最后，感谢你能读到这里。:)