3
查看阿里和腾讯评级表得知 P7 属“技术专家”T3-1 属“高级工程师”，但今晚面试了一个简历上写着阿里 P7 腾讯 T3-1 的人员:
- 不了解 vue 双向绑定原理
- 不了解 webpack 中如何做构建速度优化
- 不了解如何检测是否发生了内存泄露
- 经典的前端题 [1, 2, 3].map(parseInt) 答错（槽点）
- 不了解 js 实现模块化的原理
先说个相关的事。
前些日好不容易招了个 P7 的前端，8 月初入职后，亲自带。快 1 个月了，有些感悟。 目前来看，这位新同学能够在不了解太多技术细节的情况下，能够快速读懂和熟悉业务，一件事情只要交代了，必定在规定的时间内给出结果或反馈，做事主动有条理，基本符合我们对于 P7 的要求，或者说大家会按 P7 的标准要求他做事，他基本能应付得过来，如果过了试用期他能站住脚跟，那么他就是 P7 的。
正好前些天，我接了个新业务，需要做技术架构选型和迭代规划，这事情交给他来负责。当然，这个事情的结果会决定他的去留，他自己也很明白，就问我该如何做或有什么要求，给他 3 条建议：
第 1 条：关于技术深度的
技术一定是为了满足业务需求的，而前端项目的技术选型到了 P7 级别，在落地到业务上就要有“没有攻克不了的技术问题”的决心和信念，也就是前端业务的技术问题到 P7 这里就基本是最终的方案了。 比如，你选择了 react 技术栈，结果在开发过程中发现 react 框架有 bug，那么你就得有信心把 react 的问题给解了，而不是等 Facebook 来帮你修问题。
第 2 条：关于架构设计和规划的
做技术选型和概要设计，P7 级别的就要做 到，1 年以后当别人接手时就不需要考虑重构，如果是 P8 的就有信心做到 2 年以后，而 P9 的则是 3 年或更长时间。 当然，这是一个比较主观的评判标准，毕竟人难免会犯错，而我想表达意思是，P7-9 的技术选型就要有长远一点的目光和思考，而这些往往是 P7 以下工程师所缺乏的，可能是技术底子不好，也可能是视野未够，抑或是其他神马原因吧……
第 3 条：关于团队管理的
有组建自己的团队、有不断巩固和扩充业务地盘，以及有申请/借调资源的意识，多主动与不同团队的人沟通打交道，有拿结果的意志和行动。（不管你是用技术的还是非技术的手段，甚至技术人都厌恶的拍马屁的手段），总之只要你能不断扩充团队规模，扩大业务地盘，那么你的级别往往越高。拿结果这是高 p 必须的，大家都做事，企业只会为结果付费。
当然，领导也不是白痴，技术团队往往还是技术精湛的、做事主动，技术不设边界的同学更容易获得这样的机会。阿里这里基层的 leader 不兴空降，地盘是自己打下来的，团队也是自己建起来，我的团队就是这样建立起来的。
17 年上半年的时候，我和另外一名 P6 一起从另一组调配过来这个大组的，当时我还只是做业务的（不是 leader，没有实际的下属，虽然一起过来的是由我安排工作，但没有他的绩效考核权，要知道这个权限才是尚方宝剑），从属于另一 P7 的下，再上面是一个 P8。
这是一个很大的变动，相当于我的老板以及老板的老板都变了，需要在新团队下重新站稳脚， 而这个大组原来是纯客户端组，所有的 leader 都非前端。所以，在前端领域我要必须比他们更专业。我做了几件事：
- 1，前端微服务化和容器化。这个事情通是渐进式的重构来完成，将原本割裂的技术栈统一的前端工程体系下，大大降低了维护迭代的成本，原来这个业务是由 2 个团队共 6-7 个 P6 前端参与维护，目前在这一块我只投入 1 个 P6+3 个外包。效果立竿见影，否则也没有资源做后面的事。
这个新架构被验证并落地部分微服务后，非前端技术栈的 P7 同学其实是无法对我进行有效的指导了，我就被直接划拨到 P8 下成立一个专门的前端组，统筹前端方向的事物，开始有绩效考核权。
- 2，10 亿+http 业务全线 https。这个事情在我之前有人做过，由于业务复杂度高影响面广，以及 https 性能的问题，最后没有真正上线，其实也因为在 app 内有私有的 http 加密，但去年初加密算法被**了，劫持问题消耗很多人力。这事情，除了将 https/http2 落地外，前端技术上比较有点意思的是把 ServiceWorker 做静态资源的预加载，降低前端迭代的用户成本，而 PWA 没用上，坦白说用不上。
（在这里插一句，在中国移动互联网中 PWA 并不是前端技术的未来，因为国内最有价值的内容，例如微信订阅号、微博以及各种自媒体，还有各种短视频内容，无一例外都是私域内的东西，站在这些玩家的角度有必要通过 PWA 来巩固地盘吗？pwa 并不复杂，核心就 SW，折腾不了几下）
- 3，前端团队全面 Weex 化，统一 BU 的 Weex 前端工程化。其实 Weex 在我们 BU 主要是移动端的同学在搞，大组的老大把我要过来，最开始只是前端部分正是他的核心业务的落地消费场景，有没有想过前端在 Weex 上有什么作为，估计是没有的，他只是给 我提过期望前端也能参与 Weex 业务，我们入场后改变这个组在 Weex 上的人力分配。 当然，我进来之后也统一了整个 BU 的 Weex 工程化体系（不仅仅是我所在大组），在 Vue 基础上又引入 Rax 体系和打通 H5 自动降级，沉淀了一些列我们业务类型下的性能优化的策略。目前所由前端主要负责的 Weex 业务秒开率基本都在 92-95%，而在 Weex 开发效率上，前端出身的工程师要明显高于客户端转型的，在控制组件的可维护性上，前端开发者的优势也比较明显。 现在新业务基本都会以 Rax 去落地，整个大组 Weex 开发的模式则是前端为主，app 开发则偏向于底层，而淘汰掉 App 开发而空出来 HC 则大多变成了前端，当然就隶属于我这组，人数也从原来 2 人逐步到现在 15 人，目前还在继续招 P6/7 前端。
- 4，除了 weex 外，在 Node 中间层也有一些产出，以及在做一些 Flutter 技术布局的事情。
总体，webview 容器、Weex 容器和 Node 容器都有在做，而每个容器的相关业务，包括底层工具链脚手架，H5 页面的切图和逻辑，Weex 组件开发，Node 层开发维护，我基本都会自己写部分代码，至少核心的业务代码基本都会过一遍。技术上，对于未来的可能也会保持关注。 以上，就是我在做的事情。虽然还是没有直接回答题主的问题，但如果认真看完，应该能理解阿里 P7 到底要求是怎么样的，这样下去不知道明年有没有机会升 P8……谁知道呢，时机和运气都是实力的一部分。
另外，对于追逐更新的技术红利而晋升的道路，我想说的是：
不可否认，更早的吃螃蟹，确实更容易获得晋升，但这不是大多工程师的可选项，因为企业很多时候并不关心你用什么技术来完成业务需求的，也没有很多机会给人专门研究和落地新技术，维护业务才是绝大多数工程师的核心事项。 的确，我所在部门确实是一线的业务部门，保证业务快速落地才是第一要务。业务占比必然会比较大，但技术上探索的事情并不会像 P8 同学所说的感觉毫无技术含量似的，换一个角度，技术上又有多少事情是别人真的没有做过的呢？ 退一步，就算别人做过了，只要自己团队没有做过，那么还是需要有人去做一遍的，只是后来者既然是站在前人肩上的，就要做得更好更优就是了。
当然，我不是说只要做好业务就 OK 了，技术人还是要对新技术保持关注，有能力就尽可能参与，能力达不到的也没必要刻意追新。
必学的技术栈
一、JavaScript 高级进阶攻略 jQuery 设计模式-jQuery 源码分析
函数式编程-Underscore.JS 源码分析
二、单页应用开发
VUE.JS Recat webpack
三、移动端 app 开发
四、Node 开发工程师
https://blog.csdn.net/sinat_37903468/article/details/101170634