React
-
介绍一下react
-
React单项数据流
-
react生命周期函数和react组件的生命周期
-
react和Vue的原理,区别,亮点,作用
-
reactJs的组件交流
-
有了解过react的虚拟DOM吗,虚拟DOM是怎么对比的呢
-
项目里用到了react,为什么要选择react,react有哪些好处
-
怎么获取真正的dom
-
选择react的原因
-
react的生命周期函数
-
setState之后的流程
-
react高阶组件知道吗?
-
React的jsx,函数式编程
-
react的组件是通过什么去判断是否刷新的
-
如何配置React-Router
-
路由的动态加载模块
-
Redux中间件是什么东西,接受几个参数
-
redux请求中间件如何处理并发
开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
本文作者:刘博文(Berwin),花名“玖五”,畅销书《深入浅出Vue.js》作者、知名技术博主、讲师、阿里巴巴淘系技术部前端技术专家,现负责淘系618、双11等超大型营销活动主会场的终端渲染架构。
回想起年初刚来杭州那会,是疫情正严重的时候,那时候刚来杭州要住半个月的酒店,然后才能进入阿里巴巴溪西园区(后续简称”园区”),时间过得飞快,一晃已经来杭州半年了,这半年经历了很多,也学到了很多,写一篇文章总结下这半年来自己的成长。
勇于挑战权威
==========
要勇于挑战权威,发现现有技术体系的问题,并解决它。
记得当时刚来杭州时,心情是非常忐忑的,对未来非常憧憬,能和那么多很厉害的工程师一起工作是一件特别爽的事,再加上我们团队是做双十一大促会场的,技术人都知道双十一对工程师来说意味着什么。入职后,一大堆技术名词和各种技术体系铺面而来也确实让我感受到了技术的强大,所以就一直以学习的心态在了解和接触现有的技术体系。
进入园区后第二个月就开启了618战役,感谢主管墨冥的信任,当时我承担了一个非常重要的专项PM(Project Manager),它在整个618战役里都算是风险和挑战都非常高的专项,也是因为这件事干的还不错,上线后非常稳定,因此我获得了618战役奖励优秀PM的一个“厉害了Work哥 - 此时此刻非我莫属”奖,奖状在淘宝楼里挂了三四个月,入职不到3个月就获奖应该算是比较值得自豪的事了。
说这个当然不只是为了显摆,就在我以为自己表现非常好的时候到了转正面试的时间,虽然通过了试用期,但得到的反馈是对我的表现没有超出预期,我的执行力虽然很强,但我**“没有对现有技术体系带来变化”。**
换句话说,招我来的目的不是来当资源的,618战役虽然打的不错,但说实话换个人上去又能差到哪里去?大家对我的期望是对现有比较成熟的体系带来变革。
那怎么对现有体系带来变革?经过大家的引导和我自己的思考,答案是:”发现现有体系的问题“。我刚来觉得这里技术体系特别牛,加上沉淀了这么多年的双十一,已经是比较成熟的技术,觉得这是一个权威,不可能有问题,所以一直抱着膜拜的想法在了解和学习现有体系,所以这就是问题所在。
这时候我学会的最深刻的一个成长是:“要勇于挑战权威,发现现有技术体系的问题,并解决它。”
身为PM如何推进事情
感谢主管的培养和信任,给了我很多试错空间,入职到现在这半年时间从第一次当PM到现在,犯了很多错误,在一次次犯错后也学习到了很多当Project Manager的知识,本小节将这些成长总结起来分享给大家。
▐ 解决合作阻碍
在推进项目时,有时会遇到一些阻碍,例如:不配合,难合作,主动性差等问题。绝大部分能来到阿里工作的同学不会是“能力”或“态度”问题,所以大部分阻碍可以归结于:
-
信息不一致
-
目标不一致
-
优先级不一致
解决障碍,就是在解决以上这三点**,信息不一致可以靠“沟通”和“换位思考”解决,而“目标不一致”和“优先级不一致”可以靠“上升”解决,**只要事情足够重要,给出几种解决方案,上升到某个级别问题一定会被按照最合理的方案解决。
▐ 建立自己的权威
入职大概三个月左右的时候,我发现PD(产品经理,在阿里巴巴我们称为 Product Design,即:“产品设计”)在与我合作的过程中对我是有点不信任的,例如:相同的答案PD会相信我师兄和主管、我给了方案后PD会再去找我主管询问是否有更好的方案等。这也让我有了很多成长,当时我还特地去向二级主管请教一些方法。
拉人佐证自己的判断
案例一:在没有建立起自己的权威前,很多时候PD并不相信我给出的方案。那么这种情况解决方案是:假设有3种方案,将各自的利弊信息同步给PD后,如果都不满意,可以拉其他人,例如拉自己的主管进来,佐证自己的判断。(但前提是自己要做好功课,先和主管沟通好达成一致,再将信息同步给PD)。
案例二:假设现有两种方案各有利弊,完美的方案需要团队A配合,那么可以拉着自己的PD去和团队A的PD谈(前提是要先和自己的PD达成一致,并且以自己为主导拉PD只是来佐证自己的判断),一方面向团队A的PD佐证自己提的需求是重要的,另一方面也可以向自己的PD佐证这个需求确实没那么简单。如果事情推进遇到阻塞,回到“解决合作阻碍”小节,最终问题一定会被解决。
- 拉主管进来是为了佐证自己的判断,而不是和PD一起把复杂问题抛出去。
- 拉主管佐证要先沟通好达成一致,不是突然把主管拉进来佐证自己,避免主管的判断和自己不一致当场被打脸
资源不足而PD说我都要怎么办?
先和主管达成一致,客观评估需求是否真的重要到需要拉其他同学来帮忙开发,在一个更宏观的角度评估哪个需求优先级更高,然后再给PD同步结论,如果不接受拉主管进来还是相同的结论,再不接受再拉主管的主管也是相同的结论。权威就是在日常这样一点点建立起来的。
与PD合作的艺术
回到最初的问题,PD为什么要找我主管寻求帮助?
-
她想把事情更好地推进下去
-
她觉得找主管会有更令她满意的方案
本质上是我还没有建立起自己的权威,另外PD是信息弱势方,所以如果我给出的方案她不满意时,她会去找她更信任的人寻求帮助看是否有更好的方案,那么如果这时真得到了一个更满意的方案,那么她会觉得这招管用下回还会再去,这时候我的权威就会崩塌。
解决方案是:提前做功课给到PD的信息永远是权威的判断,在不信任自己时拉人佐证自己的判断是对的,或者和PD一起去找其他人继续推进&解决问题,逐渐让PD意识到即便是找了其他更信任的人也会得到相同的结论,我的结论就是正确且权威的。
积累自己的信用
作为新同学,可能会发现同一件事,同一个解法,PD经常会不信任新同学。
这里日常工作本质上是累积信用和消费信用的过程,解决方案是:在日常工作中一点点累积自己的信用,当机会来临要勇于消费信用去推动事情,这也是体现“此时此刻,非我莫属”的阿里巴巴价值观。
当然,打了败仗,信用也会消耗,经常打败仗即便不是新同学也很难让人信任,所以还是要靠自己的本事来积累信用并建立权威。
▐ 项目风险同步
这半年时间,关于风险同步我犯过两次错误,这两次错误也分别让我学到了两种关于项目风险的经验。
风险同步:Case 1
事情发生在今年的88大促,当时我为会场底层渲染架构全新升级了一版,在一个极短的时间用新开发的2.0追上了正在运行的1.0的大部分功能,然后在88大促切换到2.0,可以类比在天上给飞机换引擎。切换2.0后如预料中的一样,出了一些小问题。
问题在于,给飞机换引擎这个动作和行为,我没有通知给业务方,导致出了问题的时候,业务方很惊讶,为什么之前一直好好的这次突然出了这么多问题?业务方对这个事没有任何预期。
在这件事上,我学到的是:**在做一件事时,要通知到所有可能会因为这件事而受到影响的人,把自己的计划,方案,风险等信息完全同步给可能会受到影响的人,**好处是:
-
人多力量大,如果方案确实不成熟,有漏洞大家可以一起完善提高稳定性
-
大家都知道这件事,而且计划、方案、风险、预案都得到了大家的认可,即使真的出问题也不会给大家“惊喜”
风险同步:Case 2
事情的背景是,有一次我负责一件事,这件事在过程中我发现进度有延迟的风险,但当时我选择了自己抗下来,加加班,赶赶进度。后面我低估了这件事的严重性,导致最后实在扛不住了才暴露风险,紧急加人解决了这件事,虽然这件事没引起问题,但是这个最后临门一脚才暴露风险这个行为是不对的。
通过这件事,我也学会了如何做事是对的(感谢主管孜孜不倦的教导),**暴露风险不是懦弱和能力不行的体现,暴露风险是一个PM的专业素质,**不要自己硬扛风险和压力,过程中有风险需要帮助应及时提,避免到最后扛不住才将风险暴露出来。
▐ 误区:不敢上升和暴露风险
新人入职都会进入一个误区:
-
为什么我负责的项目,大家都在争论不休,是不是我能力不行?
-
为什么我负责的项目,好多事我都解决不了需要靠更高级别的同学来拍板,是不是我能力不行?
-
为什么我负责的项目,又又又又有风险了,是不是我能力不行?
现在我可以很明确的告诉大家,不是,完全不是!
推进项目受阻有很多原因,绝大部分都不是自己这个位置能解决的,上升是非常高效的解决方案。
项目遇到风险也是同样的道理,除了确实是自己能力导致的风险以外,绝大部分风险都是客观存在的事实,和自己能力没关系,即时且充分暴露风险寻求资源解决风险才是王道,这反而是一名专业的PM应该具备的基本素质。
PM的职业素养
PM的目标只有一个:“确保项目按时保质上线”,但过程也同样重要,阿里巴巴有句土话我很喜欢:没有过程的结果是“垃圾”,没有结果的过程是“放屁”。
在推进项目的过程中,一名合格的PM需要具备的基本素养是:
-
拥有Owner的心态
-
做关键技术决策
-
充分暴露风险
前端框架
前端框架太多了,真的学不动了,别慌,其实对于前端的三大马车,Angular、React、Vue 只要把其中一种框架学明白,底层原理实现,其他两个学起来不会很吃力,这也取决于你以后就职的公司要求你会哪一个框架了,当然,会的越多越好,但是往往每个人的时间是有限的,对于自学的学生,或者即将面试找工作的人,当然要选择一门框架深挖原理。
以 Vue 为例,我整理了如下的面试题。