奥利给！前端程序媛妹妹 9 点总结入职半年的成长史

作者 | 辣椒炒肉来源 | 码农翻身（ID：coderising）
【导读】本文的故事主人公“辣椒炒肉”是一个前端程序媛，毕业半年成长很大，她的经验总结非常值得职场新人借鉴。

先自我介绍一下，我是前端程序媛妹妹，应届生，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 会面对更多的挑战，加油~

本文为程序人生转载文章，作者“辣椒炒肉”投稿于「码农翻身」公众号，转载请联系原作者。

热 文 推 荐 

☞我国自主开发的编程语言“木兰”是又一个披着“洋”皮的红芯浏览器吗？

你点的每个“在看”，我都认真当成了喜欢