在前端团队的那些日子(初见)

在现在这个团队待了也有将近一年的时间, 基本上是看着它一步步成长的, 我也深受这个过程的影响, 翻看过去的日记, 有不少可圈可点的地方, 特此分享给那些在前端路上的新朋友

文章里面的日期时间不要太过于关注, 因为很多都是当时日记里面写的, 在文章中我并没有去改, 另外文章中的一些观点和现在也发生了许多的变化, 但我觉得还是保持之前的, 不去做更改, 毕竟这是一个成长过程, 关于总结性的话我会写在最后一篇中, 这是<>中的第一篇, 还有几篇之后会更新, 喜欢的朋友可以关注下本博客

初见

刚到现在这个公司时,压力很大,很多都不会,和之前公司用的不是同一个技术栈, 很多都得从头学起, 那段时间经常睡不好觉,做噩梦, 刚开始我以为和睡觉的位置有关系, 因为那段时间, 朋友和我调换了个睡觉的位置, 之前睡里面的, 之前都不会, 而现在却突然做起噩梦来, 然后我就和朋友说, 我要睡里面, 但是换回去后的几天里, 还是会做噩梦, 有天晚上朋友说, 我看你是因为去了xx公司后压力比较大吧, 心想还真可能, 那段时间也经常会梦到公司

那段时间都想离职了,但还是咬咬牙坚持过去了,那时总觉得公司流程太多,会议太多,真正写代码的时间太少,但几个月后也渐渐习惯了

现在这公司不需要打卡,但反而比在之前公司的工作时间更长,主要有以下原因,其一现在公司有食堂因此晚上可以在公司吃完饭接着干,其二工作气氛比之前公司好,其三对于我来说,你有打卡我反而会有个时间概念,到点了就想去打卡下班

公司给配了台mac, 但由于是第一次使用, 所以用着并不太顺手, 用了一个星期差不多习惯了, 之后自己也买了一台, 因为mac确实比window系统好用很多, 尤其是在效率方面, 不说别的, 之前用window系统打开个webstorm都要好久时间, 而用mac打开就几秒钟, 我想程序员应该拥有最好的电脑, 不要再去为了打开某个软件慢而去费太多心思

人的适应能力真的很强,之前说用不习惯mac,现在不还是习惯了吗,很多不习惯的现在不也慢慢的习惯了,也许真正在于你想不想去习惯,或者说有没有被迫习惯

来了大公司才知道自己以前对大公司的理解是有问题的,以前以为大公司里面都是大牛,平时都在交流技术,来了才发现不是这样的,只是比其他小公司好点,就好比上过大学和没上过大学,相对来说上过大学的比没上过大学的文化素质会更高点,但不能认为上过大学的人就都比没上过大学的人素质高, 只是比例问题

大公司有点不好的就是流程太多,原本花10分钟能完成的事,在它这就要花30分钟, 但也有好的地方, 比如: 能够有更多的时间去思考问题,而不总是在写代码, 这样才能去总结过失, 避免未来再次发生

分享会

下午去参加公司分享会,但基本没听懂,主要是他们讲的都是他们自己写的东西,且分享的人始终自我感觉良好,没有把上下文说清楚,把听众当成理解他代码的人了

分享会这件事,我觉得还是不要去分享太过于复杂的东西,也不要太过于具体,毕竟分享的时间比较短,你很难讲明白

对于听者来说,一定要有一种心态,分享会不是说别人分享的你都能有收获,也许它能给你的,只是告诉你有这么个东西,当然也有可能他讲的你一点都没听懂,但至少他给了你一些压力,让你去学习

沟通的必要性

老大说永远是沟通的时间多,写代码的时间少,因为一些需求往往是有问题的,有时产品经理会把方案想的很完美,而当你去做的时候就会遇到很多的问题,比如说一个列表它有可能有数据也有可能没有数据,但产品经理有可能想的很完美,并没有考虑到没有列表的情况,而如果你没有事先去吕一遍,直接按照产品经理的要求去写,那结果就是不断的返工

在改代码的时候发现有两处很类似,就把一个给删了,结果被老大批评了,因为那两个都是有用的,老大说你要自己去分析它们的意思,实在不懂就问,别自做主张

不要怕写日报

今天写日报发现其实写这东西有很多好处,比如说方便写周报,还有简历,也可以当做时间管理来用,再者不会忘了哪些没做,看来还是你怎么去看待它

没有气氛, 就不要学习了吗

下班时,一女同事说,不管在家还是公司都没有气氛,心想也是,但怎么说呢,现在我也已经过了啥气氛不气氛的了,自己能控制自己学习就OK了,要说公司没气氛呢,也不是,只是没有那么有罢了,也可能是我们对公司的要求太高了吧

团队模式

今天分享会上, 老大分享了如何管理已有知识和待办事项以及团队合作问题,记忆比较深刻的是,为什么要管理已有知识,以及为什么有些东西是没有必要的,之所以要管理已有知识是为了不再去踩已经踩过的坑,这样我们才有更多时间去做有意义的事,我们之所以要总结是因为将来有可能还要用到这个东西,而如果有些东西你记了却再也没有用过,那么那些记的东西就没有任何意义,还要学会随手记笔记的习惯,不要想着用大脑来记,比如你刚刚解决了一个项目中的bug,如果你想着等这个项目做完了再去总结,往往会出现的情况是,当你去写总结的时候,就已经不知道如何下手了,因为你已经忘了很多细节.人的大脑所能记住的东西真的是很有限的,刚刚讲的东西不用1,2小时你就忘了一大半了

开发模式

当我们拿到一个项目时,首先要去做的是,找到项目地址,项目文档,相关人员是谁,UI图放在哪,项目涉及到哪些技术,在本地如何把项目跑起来,安装相关依赖

团队合作

我们知道一个项目是不可能一个人来完成的,既然不可能一个人来完成,那么就会涉及到团队合作问题,你完成的 + 团员完成的 = 结果,如果涉及到后端,那么就需要和RD进行协作,而这种协作,有些事是不需要你本人来做的,但是它又和你相关,这时就涉及到推进了,比如说某个需求, RD给你说, 他等下给你做,但是很长时间都还没做,那么你就需要每隔一段时间就去骚扰他一次,这样他就肯定会去做的

摆正心态

由于项目太多,难免有些人会被分配到一些老的项目中,但是不管说是用的react还是jquery,要想学其实都能学到东西,我还是比较赞同这句话的,因为我就被分配到了一个老项目,但这些天还是学到很多的,其实吧还是看你想不想学和心态了,就像老大今天说的你永远教不会一个不想学的人,也不需要教一个想学的人,因为你只需要给他一些资源他就会像一台永动机一样

我们需要有审美观,但不是说的外貌,同一个设计,有人看到样式有问题,马上去修改,有人看到了也当做没有看到.一段好的代码,有人看到会收藏起来,有人看了觉得确实是段好代码,然后没有了然后

真的实现不了吗

回顾前段时间,自己在个别方面表现的不太好,比如说PM让改的一些需求自己老说做不了,可事后又做完了,这样的结果很容易让他们想成其实都是可以做的,有次中午去吃饭时我跟PM说那个点击显示的改成了hover显示了,PM说已经看到了,接着QA说, 我让他改的就不改, 你让他改的他就改, 然后PM笑着说, 他不弄我就捏他, 你要捏他啊

那天中午我把QA的那个问题解决了,之前觉得不可能解决是因为没有想到解决方案,事后我笑着跟QA说, 这以后还是不能说做不了, 不然被你们觉得能做的被我说成做不了

不要带有情绪

和PM吵了一架,原本我是想回家再做,因为太晚的话就没地铁了,然后我给PM说我先回家了,但PM不让我回,非要我弄完再走,我说我回去弄也是一样的,可PM说那哪一样,在这里有问题可以马上提,你走了我们还怎么测试,我说那上面不还有验证中的, 你们可以先测那些,但PM说, 那些没一个是好的…后面说的什么忘了,然后我发火说那我今晚不回去了可以吧…后来想着不太对,就和PM道了下歉

做一个值得信赖的人

某次PM看我写的页面,每次都会报一个错,让我过去看一下,我说应该是我这边的问题,然后PM说让我测试完了再让她看,我说你测,于是她就说这是你工作的态度吗,然后又和我说,如果让她来测试,测出了bug她是要记到本子上的

确定需求没问题吗

上午写代码的时候突然想起目前的功能只给一个页面加了,那么其他页面会不会也需要添加呢,于是去问PM,结果一问PM说需要,但她之前也没有说,关键还不知道还剩哪些页面需要添加,PM说去找XX,她对这个项目比较熟,心想现在坏了,如果那些页面都要写,这个星期肯定完成不了

例会后找到leader, 跟他说之前项目估的是9天,但现在PM的需求有变更,还有几个页面之前也没说要做,现在按照那个时间肯定不够,leader让我确定一下还有哪些页面,让我重新估一下时间,一到姑时间就比较烦,姑少了吧到时完不成又得负责任,姑多了吧PM又嫌多

leader在群里说以后有需求改动和他说一下,PM说没有需求改动啊,还是之前的,然后leader说了几个例子,PM说那几个需求改动应该不是很大,觉得没必要说。我看PM的脸色都变了,PM和我说这些改动大吗,我说你的这些需求不是很大,但是我也是刚刚接触这个项目,对它里面的很多代码还不是很熟,所以改起来就需要比较多的时间

PM下去找leader,PM和leader说来请罪来了,心想原本没什么事,她这样一说倒真像有什么事似的,谈话中说到那个弹层的问题,说这个弹层还有问题,如果说用户已经看了很多次了,还用提示他吗,这些还真没考虑到,这之后有时间一定得写一个避免此类问题的文档

由于工作内容的增加按原计划可能就做不完了,因此PM让我把代码拆开,之前PM说写在一起,现在去拆也是件麻烦事,以后还是要自己做决定

和PM过需求的时候,又发现一个之前没有考虑到的事,到今天为止,算是又搞了一遍了,突然觉得我们的时间更多的是花在不断反工上,如果在一开始我就去仔细分析PM的需求也许最终就不会花那么多时间在无意义的事情上了

今天PM给领导展示了一下这期的迭代成果,从中又发现了很多的问题,突然觉得有些事就不能听PM的,其实很多时候她们也不知道什么方案好,有些流程她们也不一定会考虑到

开会时间真的很多,但如果不开会的话,很多问题一下子想不到,这或许是开会的好处吧,只是有些浪费时间,但觉得很多一开始就可以考虑到的,只是说没有用心去想,说来忏愧自己更没去想过,以前觉得这是PM或领导的事,我只负责去实现,可现在发现如果真的那样的话, 自己反而要做很多无意义的事,最后还会被搞的焦头烂耳,想想还是自己也多参与一下,多想想使用流程

要学会融合

中午吃饭时, PM谈到找对象的事, PM说一定要找能够适应社会, 能够改变的人, 不要找不懂得融合的人, 那样生活会很痛苦, 是的要懂得融合, 因为我们都有缺陷, 如果不会改变自己, 那怎么和他人相处, 自己在这方面也还是有很多做的不太好的, 不能完全的接受别人的缺点

努力的意义

今天才感觉到努力其实是有意义的, 当我们自己变的完美时所遇到的人也是更好的, 当我们遇到很多自己不喜欢的人或不同价值观时, 其实是我们的努力还不够

原文地址:https://www.cnblogs.com/pssp/p/9164466.html

时间: 2024-11-13 07:56:32

在前端团队的那些日子(初见)的相关文章

前端团队成长计划(一):基础知识梳理

一个月前我开始了前端团队的成长计划,主要主语两方面的考虑:校招应届生能快速进入工作的状态达到一个能支撑业务的技能水平,提前学习主流前端技术,为未来的业务代码重构做储备.5月是整个计划的第一个阶段,主要的任务是,梳理常规前端基础知识和开发技能. 5月的计划如下:(偏基础) 1.js和css的一些规范以及常规功能如何实现: 2.了解现有业务工程的开发,部署,上线流程以及原理,做到可交叉维护: 3.初步了解gulp,为下一阶段做准备. 4.了解PC开发中常见的问题以及IE浏览器的兼容方式(IE8+)

Miox带你走进动态路由的世界——51信用卡前端团队

写在前面: 有的时候再做大型项目的时候,确实会被复杂的路由逻辑所烦恼,会经常遇到权限问题,路由跳转回退逻辑问题.这几天在网上看到了51信用卡团队开源了一个Miox,可以有效的解决这些痛点,于是乎我就做了一些尝试,确实很不错,star增速也表明了业界对其的认可!由于自己能力有限,不能很好地解读Miox,于是我就把Miox作者的文章给搬过来了,希望对大家有所帮着.(跟作者聊过之后,了解到作者团队开发了2年多,沉淀了很深,后来选择了开源,如果大家觉得好的话,可以去点一下star!) github地址:

005_解密饿了么大前端团队

最近,"大前端"这个词被频繁提及,很多团队也在重新思考"大前端团队"和"移动团队+前端团队"这两种模式的优劣.而在大家还在热火朝天地讨论概念的时候,饿了么大前端团队已经茁壮成长,有了很多先人一步的实践了.InfoQ 特别邀请了饿了么大前端部门负责人林建锋,请他结合饿了么大前端团队的实践,向大家分享如何落地和管理一个大前端团队.    平时大家会叫我小鱼或 Sofish,尴尬的是只有屈指可数的同行知道我真名叫林建锋.曾经,为了逃离数学,大学我选了法

006_饿了么大前端总监sofish帮你理清前端工程师及大前端团队的成长问题!

作者|Sofish编辑|小智 & 尾尾本文是前端之巅向 sofish 的约稿<什么样的人可以称为架构师?>.采访< 饿了么大前端团队究竟是如何落地和管理的?>以及 sofish 做客大咖说直播节目的总结和整理,希望能帮助各位淀粉更清晰地理解 sofish 的观点.获取大咖说视频下载链接,请关注前端之巅并回复"鱼老板",查看饿了么大前端更多实践请回复"饿了么".视频回顾 程序员成长之:跨界.困惑与架构师1. 如何看待"大跨度入

if 我是前端团队 Leader,怎么制定前端协作规范?

万字长文,继续刷新我的文章长度记录,涉及前端开发的方方面面.本文将持续更新和完善, 文章部分观点可能比较武断或不完整,欢迎评论和补充,一起完善该文章. 谢谢 笔者长期单枪匹马在前端领域厮杀(言外之意就是团队就一个人),自己就是规范.随着公司业务的扩展,扩充了一些人员,这时候就要开始考虑协作和编码规范问题了.本文记录了笔者在制定前端协作规范时的一些思考,希望能给你们也带来一些帮助. 一个人走的更快,一群人可以走得更远,前提是统一的策略,还要不断地反省和优化. 以下是目录概览, 看出这是一篇浩浩荡荡

国内10大前端团队网站

原文链接:bigezhang.com 为了方便更多用户可以基于 Agora SDK 快速实现多种在线教学场景,我们现已开源声网云课堂 Demo,大家可在文末获取源码.juejin.im 1.淘宝前端团队(FED) 网址:taobaofed.org/ 阿里巴巴淘宝前端团队网站,一群崇尚极客精神的人正在用技术为体验提供无限可能.在这里,可以涉及“无线”.“全栈”.“工程”.“安全”.“架构”等多方面的技术. 2.FEX 百度前端研发部 网址:fex.baidu.com/ FEX 是百度「Web 前端

第八章 交互技术,8.3 2016双11前端突破(作者:天猫前端团队)

8.3 2016双11前端突破 前言 2016 年天猫前端相比去年有了非常多不同维度的突破,主要可以分为四大类大类: 稳定性.监控 极致的性能优化 业务创新 / 平台建设 技术创新 / 互动 1. 稳定性.监控 商品到每个用户浏览的每个环节都有监控,尤其在针对消费者体验上的 TES,让前端在消费者真实浏览的过程当中也能够有更进一步的分析在不同环境下消费者实际的体验.以及从服务器 Wormhole 渲染层进行了一系列的稳定性.监控. 1.1 Wormhole双11会场稳定性保障 Wormhole承

前端团队开发工具

### Sublime 代码检查 http://www.sublimetext.com/3 下载合适的portable version https://nodejs.org/download/ 下载 node并且安装 安装jshint $ npm install jshint -g 如果没响应(GFW,使用cnpm和npmreg都是不错的选择 ),使用淘宝的源,下面cnpm换成jshint. https://packagecontrol.io/installation 按照说明配置sublime

转载:淘宝前端团队的干货《论版本号的正确打开方式》

引用原文评论的一句话:条理清晰, 如此甚叼! 论版本号的正确打开方式 作者: 法海 发表于: 2016-08-04 版本号广泛运用于开发的各种场景:NPM 包的版本定义.对 NPM 包的特定版本的依赖指定.git 的 daily 版本号分支…… 面对如此多的场景,版本号的命名却存在很大问题.举些例子: 开始写一个新项目 / 模块时,不管三七二十一,都从 0.0.1 起版本,直到项目不再维护时,版本还停留在 0.0.48,前两位永远都是 0. API 变化巨大,而版本号雷打不动一步一个脚印.一个二