Web前端最全高级工程师做事方法总结篇，轻松获得一线大厂面试offer

2401_84617681

已于 2024-05-09 02:17:39 修改

阅读量697

点赞数 8

分类专栏：程序员文章标签：前端面试职场和发展

于 2024-05-09 02:17:37 首次发布

本文链接：https://blog.csdn.net/2401_84617681/article/details/138592301

版权

程序员专栏收录该内容

104 篇文章 0 订阅

订阅专栏

紧跟潮流

大前端和全栈是以后前端的一个趋势，懂后端的前端，懂各端的前端更加具有竞争力，以后可以往这个方向靠拢。

这边整理了一个对标“阿里 50W”年薪企业高级前端工程师成长路线，由于图片太大仅展示一小部分

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

很多人“不会做事”，是因为都只关注到 “事中”，事前大部分都是 leader 安排好了，自己没有思考过为什么要做这件事、目标是啥；至于事后，由于项目紧张，事情做完很快就投入到另一件事情了，关于这件事后续如何，如果不是出了线上问题，或者 leader 过问，自己很少会去关注。

其实大家技术都差不多，但思维上的细微偏差，长此以往可能就会导致截然不同的发展轨迹，这里围绕“事前-事中-事后”这个闭环思维去展开各个环节中的一些方法论吧。

二、事前分析

“为什么要做这件事？”，“痛点是什么？”，这是很多大佬经常问的问题，往往是在你滔滔不绝地介绍方案的时候，大佬们就用这个问题打断了你，既然大佬们经常问，说明背后一定有其深层原因。

结合我自身的理解，从技术优化类和产品需求类来分析这个思考的必要性，这是码农日常最常见的两类事情。

1. 产品需求类

很多人说，这个产品都已经思考好了，照着做就是了，哪来那么多为什么呀？

的确，在我们这些码农接到需求之前，产品同学内部应该都讨论多轮了，但是我们还是要去理解一下需求背后的深层原因，一方面能够加深对需求的理解、提高业务理解能力，另一方面也能通过**对需求本质的理解，在设计方案的时候思路更清晰。**例如技术方案评审的时候被问到为什么这么做，而不是那么做的时候，你能结合需求业务场景和扩展性等作出清晰的解释。

2. 技术优化类

比如你觉得现在网络框架中需要引入quic ，你要思考的问题就是为什么要引入，是 quic 比较弱网情况下性能比较好？

那再问，我们目前的网络库性能表现不好吗？有没有数据支撑说明？另外做完这件事投入是多少？收益是多少？能不能从现有的数据情况推论出做这件事之后的收益？

这些问题想清楚之后，规划执行才能有理有据，你的 leader 才可能给你争取资源来做。

3. 2P挖掘法

知道经常被问和理解其必要性之后，我们就来准备怎么才能清晰回答这些问题，要想应对自如，就是提前问自己。方法论是：“2P挖掘法”，即，至少找出个痛点或者两个论据来支持你做这件事的必要性，这个两个痛点不是拍脑袋或凭感觉，最好要有严格的数据说明。

例如现在要对一个百人的项目做组件化重构，痛点是：

编译太慢，影响开发效率；
模块耦合严重，维护成本高。

为了进一步说明这个痛点有多痛，你可以用一些数据说明，例如一次编译要 20min，一般开发在开发和解 bug 平均一天编译6次，一天花在编译上的时间就是 2h，一百人的团队，一天浪费的时间就是200h；如果能组件化后单独编译组件只要2min ，一天就能节约180h的时间。

如果每件事情都逼迫自己至少挖出两个以上类似的痛点或论据，后续被问到 why 的时候，一定能应对自如，因为你早就已经经过了深思熟虑。

三、事中执行

想清楚为什么做这件事之后，做的时候就能放开顾虑去做了，包括方案设计、落地实施、问题处理等重要的步骤。

“你为什么选择这个方案？”、“你的方案考虑过xxx这种情况吗？”、“业界是怎么做的？为啥不使用xxx开源方案？”，这些都是在一场技术评审会上被问得最多的问题，如果你的回答是支支吾吾、临时拼凑，那么就会给人留下你没有深入研究的印象。

解决这个问题的方法是：每次设计方案的时候逼迫自己想出三个备选方案，如果你想出了三个方案，那么前面提到的哪些问题，你一定都提前问过自己了。

1. 3C 方案设计法

3C ，即三个 Choice，主要是逼迫自己去想更多的可能性，横向对比行业是怎么做的，是不是可以拿来用，自身业务情况下是不是有更多选择，严格按照这个思维去做方案，久而久之也会无形中提高自己的深度和广度。

有人可能会觉得浪费时间，想快，这也是人的天性，但是我们用这些方法论不就是对抗人性的弱点吗？如果为了快，方案有多潦草，技术评审会上讨论就有多激烈，最终也浪费了大家的时间，最终返工浪费的时间更多，还给大佬留下不好的印象，所以“3C”还是值得花时间去做的。

2. 落地实施的进度条

方案设计之后，就是怎么推动事情落地了。首先把任务按照依赖关系最小粒度的划分，评估每个模块的工作量，最后评估出总的工作量，然后排上计划，执行的时候就开始了我们的进度条。如果太长，可以划分为 2~3 个里程碑，执行过程随时检测进度，是不是存在风险。

需要注意的是，在拆解任务的时候尽量识别出依赖或被依赖的关键节点，尽早安排，实际开发中，工作量评估最常见的盲区就是忽略了跨组联调、对接的时间，这些节点往往也容易成为项目进度风险的关键因素。

3. 借助他人的力量

程序员最容易犯的错误就是习惯自己一个人埋头苦干，希望自己能搞定一切事情，怕打扰他人，但是有些事情需要他人配合才能完成，甚至需要依赖外部团队，怎么推动他人按照自己的计划配合完成事情呢？

这里我觉得和平时做人有些关系（并不是指人品好坏），我觉得会有一篇《大佬们的做人方法论》，如果是熟人、或有交情的人，推动起来就事半功倍，如果不熟悉，的确不太好推动，可能平时多和兄弟团队多打打招呼、多认识认识会有些好处。如果自己无法驱动时，可以借助 leader 的力量，leader 出面，对方也会重视起来，别人配合你做事也有名有分。