那个时候，我只想好好的学习web前端技术，恨不得把有限的时间和精力都放在提升技术上。
然而，让自己在坑里茁壮成长，要先适应坑内的环境。
首当其冲我们要弄明白的事情有：
- 团队成员的技术能力和状态
- Leader的风格和对团队的要求与期望
- 我在团队中的定位和价值
- 这里会给我带来哪些提升
- 在这里工作期间还可以学到什么
这样，在接下来的工作中，就能更好的适应团队。比如和哪些人多聊技术，和哪些人在一起多听少说，和哪些人多聊段子，哈哈哈…
真正到了分配工作任务的时候，我估计多半新同学的内心和我一样，都是一万只草泥马奔腾而过，心乱如麻。
- 这需求太奇葩/不明确了
- 卧槽，我不会
- 日了狗，要加班了
- 这么多功能都需要数据业务接口，这都TMD找谁去
- 没有UI设计？
这个人就开始不好了，再抬头去看Leader，我的眼神无比幽怨…
内心在咆哮：“没搞错吧，我只是个web前端工程师，不是manager，也不是leader…”
然而另一个声音在说：“准备工作既然这样不充分，那只能自己去做，抱怨再多，也只能让Leader认为自己不堪大用。”
内心翻江倒海地挣扎过之后，只能老老实实地去尽可能多的收集有限的项目相关信息。
我开始怀疑人生：
- 卧槽，不是要这样干三年吧
- TMD，这能学到啥
- 哎我去，产品经理真是吃翔的
- 唉，Leader也真是心宽
- 这帮人咋都不表示啥意见呢，这些活哪个不都是拖泥带水的
负面情绪爆棚了有木有…
即使再多的抱怨，也要含着泪把分配的任务按时做完，毕竟事关饭碗。
我开始请教比我先来的同事，特别是做过类似项目的，以一顿烤串为诱饵，换来领自己略感宽心的友情提示云云。
经过焦头烂额的一段时间，终于还是完成了需要做的工作，最大的收获就是明白了：但凡是遇到了自己短时间内克服不了的困难，要不介意丢人的追根究底问下去。
回头看看自己一路走来踩过的坑，和交付的代码量，又开始心虚了：
- 这总共没多少行代码啊
- 也不知道Leader会说啥
- 不会写得太差被鄙视吧
等Leader召唤我过去，第一次正面谈对个人工作的具体评价时，懵逼了…
因为Leader说：
- 有现成的lib你怎么不用，还自己写这么多代码
- 这function命名不准确，要用动词加名词
- 这代码规范还要多注意
- 这种写法有问题
- …
等话说完的时候，我提交的代码被删得寥寥无几，惨不忍睹，眼看Leader键盘噼里啪啦一顿响，把我的代码几乎改完了…
“你看，我们这样做就行了，你多看看，多学学…” Leader 按下ctrl+s，并提交了代码。
而我除了点头说是，心里面是空白一片的…
回到工位上，定了定神，去fetch了最新的代码，看着那陌生的一行行，心里是不甘，无奈，心灰意冷。
一顿腹诽之后，默默收回这些负面情绪，开始仔细研究“为什么他要这样做”。
等大概理解了这样做的原因之后，我开始重新整理心情。
- 从一开始拿到这份任务的时候，我就觉得这个活不好做，为什么呢？
那是因为自己的定式思维，以前的团队工作风格，能够提供很明确的需求，有文档有设计…但是这里没有。
- 大家也和我一样觉得这种工作方式有问题吗？
没有，大家都适应没有文档没有设计的去开发了。
- 我用了这么多时间去做的工作，为什么在Leader手上，几分钟就搞定了？我什么时候才可以和他一样？我的时间都用在哪里了。
经过分析，这里的每个任务都要牵涉到复杂的业务逻辑，必须对业务和后端逻辑都比较清楚，才能更快的解决问题。
什么时候我对这边的业务也熟悉了，那就会更快更顺手了吧…
- 这样的工作方式，我能接受吗？我喜欢吗？
我不喜欢，因为我的时间不是用在了技能提升上，而是大多在熟悉业务，不停的踩业务逻辑的坑。
大概总结了一下第一次任务的心得，更加清晰的认识到了自己和团队问题所在。
作为一个有理想的上进青年，我需要认真规划一下，如何更好的在团队生存，并同时提升个人价值。
怎么做才能改变自己处境，让自己快速成长，且听下回分解。
