点击上方 "程序员小乐"关注, 星标或置顶一起成长
每天凌晨00点00分, 第一时间与你相约
每日英文
Sometimes there is no next time, no second chance, no time out. Sometimes it is now or never.
有时候,没有下一次,没有机会重来,没有暂停继续。有时候,错过了现在,就永远永远的没机会了。
每日掏心话
其实,痛是很难分享出去的,你复述一次你就伤一次,别人没共鸣,你就更受伤。隐忍不说,只是做事,时间会让痛过去。
来自:码农翻身 | 责编:乐乐
程序员小乐(ID:study_tech)第 802 次推文 图片来自百度
往日回顾:小米回应暴力裁员:已提前三个月通知不续签合同,并且给了N+1补偿
正文
本文来自“辣椒炒肉”的投稿,她是一个前端程序媛,毕业半年成长很大,她的经验总结非常值得职场新人借鉴。
先自我介绍一下,我是前端程序媛妹妹,应届生,2019 年 7 月份入职到 2020 年 1 月已经工作半年,这半年里自己以肉眼可见的速度成长,写写这半年的经历,回顾总结一下,希望我的经历能给你带来不一样的“鸡汤”。
入职的每个应届生会分配一个导师,工作内容大致和导师方向一致。刚入职的一个月,主要就是熟悉公司的一些基础建设、用什么技术栈、跟导师一起开需求评审会、改改小 bug、调调样式或增加小功能。
最开始的工作比较轻松,没有具体工作的时候我就结合系统功能和代码,梳理系统逻辑,绘制脑图。这件事还是很有用的,对我后来快速定位 bug、迭代小功能起了关键性的作用。
第一次独立做一个完整的需求
第一次做一个完整的需求是入职两个月的时候,当时还是挺慌的,感觉自己还没有摸清门路就要开始一个人做事了,而且还是一个倒排期的移动端需求,这无疑又为我添加了一份紧张感。
每天根据需求文档疯狂写代码,天天压力大到梦里都在写代码、解 bug,早上七点钟自然醒,最担心的事情就是功能实现不完。
就在这时导师很忙,完全只能靠自己,遇到什么技术难题,都要自己来解,我迎来了前所未有的恐慌。
尽管后来功能上线了,但依然很虚,时刻都在担心线上会不会有 bug。每天会不定时打开公司的APP几次,实际操作一下自己上线的功能,验一验有没有什么bug ;同时关注产研群,看是否有 bug 反馈。
过了大概 2 周的时间,功能在线上很稳定,没有任何 bug 反馈,这才放心下来。
由此我对自己的技术水平也有了新的认识,实际上并没有自己想的那么差。压力最大、问题最多的时候也是成长最快的时候,做完整个需求以后,前后端怎么配合、什么时间节点该做什么事,需求从评审到上线的链路也渐渐清晰了。
面对压力
做这个需求的时候我感觉到了非常大的压力,感觉每天自己就是一个高压锅。对压力的思考,也正是这个需求给我带来最大的成长。
压力来源于什么?压力来源于自己认为自己的能力不足以 hold 住整个事。因为自己没有做过,面对未知的恐惧人就会不自觉产生压力。有什么好办法面对压力吗?
正视、面对、突破。
1. 首先不能给自己增加压力的砝码,切记不要思考是不是自己能力不行,我怎么这么菜。越是思考负面情绪因素,越让自己头脑不清晰,压力越大自己越紧绷,这时候如果出现一点额外的差错,就感觉天要塌了,越是压力大越容易出差错。
2. 有压力的时候,也就是成长最快的时候。按部就班处理每天遇到的难题,不会什么就学什么,不要担心它、也不要因此而焦虑,把该做好的事情做好,当做好之后压力也就解除了,同时自己也成长了。
3. 做事情的时候要给自己信心,不断地给自己加油打气,抗一抗,努努力加把劲就过去了。当下次同样难度的事情到来时,已经经历过一次便不会紧张焦虑。想想看,能力是不是这样增长起来的呢?
换业务方向
在工作差不多两个月的时候,整个前端大组计划根据业务方向划分成 4 个小组,我现在的工作属于 A 组,趁这个时期,我想要在划分方向前调整到 B 组去。
为什么要换到 B 组?
简单说说 A 组。A 组的业务,由于因为历史项目较难维护困难,作为新人的我很头疼,我每新增一点功能都感到紧张,毕竟线上无小事。
再说说B组。1. B 组同学经常做 code review,基本上每周都会看到他们 code review 的会邀,作为新人我对 CR 这件事还是很向往的;B 组业务复杂、系统功能多,但是却有一套规范,多人写的代码十分接近像一个人写出来的。
2. B 组同学的能力成梯队,有资深的老员工负责一个项目,带着几个同学一起做,看他们平时工作很 happy。
我有了初步的想法后,直接找到 B 组的 leader,先了解下 B 组有关的业务。听听这组的老大怎么说。(下文 B 组 leader 直接简称老大)
让我非常意外的是,约到了 B 组 leader 后,他在会议室非常认真地给我讲了一个多小时,还写了板书,把多个业务之间的关系讲得明明白白;
不仅介绍了 B 组当前做的事,还介绍了未来的规划,规划包括了业务需要和技术驱动。
我和 B 组 leader 在此之前没有任何交集,但是就冲这认真程度,我已经决定来 B 组了,我仿佛已经看到了未来的光明,哈哈。
我和 B 组的 leader 表达了我想来 B 组的意愿,他表示欢迎。接下来就是和大组的 leader 沟通了,在此次沟通之前,我认为这是一件很难的事,因为我担心:
如果 A 组人力不足不允许我去 B 组怎么办? B 组真的需要我吗?大组 leader 会不会觉得我这刚工作两个月的新同学,想法有点多啊?
认真地准备了自己的说辞,带着诸多疑点,和大组 leader 沟通了一次。
没有想到,结果如我所愿!大组 leader 不仅同意了,而且还非常高兴我能主动表达自己的想法。
主动反馈
事后总结了一下,主动反馈在职场中非常重要。主动可以改变你看似不能改变的事实,主动反馈也是站在别人的角度去考虑问题。
你的上级大概率不会了解每一个人,如果你能主动 push 消息给你的上级,和上级有一个良性的互动,那么他越了解你、越了解你手上的工作,也就越能帮助你,一旦你出了什么岔子或者有什么疑惑,他能切中要害给你解答。
除了和你的上级反馈,也要与自己合作的产品、任何角色的开发、运营同学等及时反馈,有消息及时反馈给对方,在对方的心里你更靠谱。
反馈什么样的问题呢?我大致分了几类:
1. 可能延期上线的风险
2. 自己近期的工作进展和疑问
3. 对团队建设的想法
4. 发生变化、会影响结果的消息。
独挡一面的时刻
由于 B 组业务多,人力不足,刚来一个月,老大直接扔给我了一个 P0(项目优先级的排序方法:P0、P1……)的项目,我一个人负责。
我特别兴奋,自从独立做了一个完整需求以后,自己信心大增,发现自己是有能力独自完成一个需求的,而且技术能力也没有自认为的那么差,有了上次的积累,我相信自己这次会做得更好。
这次是我第一次独自负责一个项目,检验自己能力和展示自己能力的时刻到了。
从零开始一个项目,遇到的挑战还是很多的。平时只是在原有项目上迭代功能,现在从建仓库、申请域名、搭建测试环境、申请上线机器等一系列事情开始,写代码只是其中一个环节了。
每天赶着做赶着做,还是遇到了一个大风险,距离上线还有两天,有一个关键的功能没有实现。
这时候我已经完全没有了办法,心里甚至有点崩溃,归因于自己能力不足导致没有开发完成,只能去问老大现在该怎么办。
老大和产品沟通,结论是没做的功能后续再迭代,问题解决了。
这件事让我非常震惊!
因为在我的心里认为已经走投无路,这该怎么处理呢?老大和产品的沟通过程我是全程在的,我发现老大是知道这个风险的,时间紧很可能完不成,每天站会的时候产品也在,他提前和业务方沟通过,在约定的时间点不一定会完成全部功能,业务方也给出了最小可用版本的要求。
原来业务方的要求并不是一成不变的,他们在开发前期也是了解到时间紧的,在摆明了客观条件下出现问题,他们也会给出一些让步,并不是咬得死死的要上线全部功能。
在这次需求完成后,有了很多新的认识,大致分为以下几个方面。
态度
永远采取对解决问题最有利的态度。
开发过程中可能会出现预料不到的状况,当问题出现的时候,首先要摆正的就是自己的态度,不甩锅、不带情绪,采取对解决问题最有利的态度,缺少什么资源、产品有什么问题、接口哪里不合理就及时和对方沟通解决,以最短时间解决出现的问题。
对需求的思考
在做本次需求之前,很少思考为什么做这个需求。这个产品设计的合理吗?在需求评审的时候大脑也不够活跃,很少提出问题,通常是拿过来设计稿直接做,做完了上线。
但是这一次情况完全不同,我不假思索去做这个需求,结果就给自己留下了坑,在做的过程中才发现有问题,在开发中去改的成本远大于开发前想好。
这一次非常深刻提醒了我,开发前要主动思考需求,甚至说在某些时候细节的考虑要做得比产品还充分,做之前和产品充分交流,随时提出问题,解决问题,开发前是万万不能少了思考的,要培养自己产品思维。
对于需求的思考和几位前辈交流过,结合前辈给出的建议我给自己提出了开发前 5 问。
每次在拿到需求的时候我会问自己以下几个问题,思考并尝试回答,如果回答不清楚就问产品或者其他前辈。
1.首先了解为什么要做这个需求,它的背景是什么,能带来多大的价值?
2.这个功能在当前的系统是否已经实现了?如果实现了,是否可以复用,如果不能复用,差别在哪里?
3.这个功能除了满足当前的需求,还可以举一反三用到别处吗,是否可以抽出公用业务组件?
4.这个需求是一次性的需求还是长期的,后期会怎么发展?
5.技术上实现的成本高不高,如果高的话,是不是可以选最痛的、优先级最高的做,然后小步迭代?
提前暴露风险
有问题、不能如期上线要提前报给上级。
提前是一个什么样的时机呢?暴露风险最好的时机是每天站会,如果没有站会,就及时和上级说明情况,让他提前知晓,而不是上线前才让他知道。提前暴露风险就是在为自己争取时间,暴露风险后可能的解决方案是延期上线、或者上线一部分功能。最初我很怕暴露风险,怕上级认为我能力不行,其实这都是以自己的角度思考问题,风险的成因是多方面的,自己的能力只是其中一个。
了解业务
曾经很不理解老刘在公众号提出的了解业务,也不明白自己的上级、部门 boss 经常提醒大家去了解业务,现在我有一点点感受了。
了解业务所涉及的名词、流程、相关的功能、各业务之间的关系,可以使自己在开发过程中更加游刃有余,预测可能出现的问题,产品遗漏的逻辑分支,争取做一个信息量最全的人。
在业务上常问自己,这是什么?这个业务的背景是什么?有什么价值?尝试落实到纸面上,如果写不清楚就继续了解、去问,直到写明白。
这是目前我认为了解业务比较好的一个方式,问了解它的人,他也乐于给你讲清楚相关信息。
写在最后
我发现,对于刚工作的小白来说,在工作中学习是最快的方式。每做一个需求,都会碰到一些技术难题,边学习边解决问题,能力嗖嗖嗖地就上来了,技术成长的速度远远超过自己周末默默啃源码、看书本。
这半年是收获颇丰的半年,自己成长了很多,由衷感谢这半年来帮助过我、给我解答诸多疑问的前辈。
2020 会面对更多的挑战,加油~
欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,学习能力的提升上有新的认识,欢迎转发分享给更多人。
欢迎各位读者加入订阅号程序员小乐技术群,在后台回复“加群”或者“学习”即可。
猜你还想看
必须要掌握的 InterruptedException 异常处理
Github 3.4k星,200余行代码,让你实时从视频中隐身
一次SQL查询优化原理分析(900W+数据,从17s到300ms)
关注订阅号「程序员小乐」,收看更多精彩内容
嘿,你在看吗?