背景
之前分享了个人成长和能力模型的关系。期望大家理解能力模型对各个人成长的重要性，同时遗留下了一个能力模型的问题。前端的能力模型是什么样子？ 怎么制定能力模型的？
希望本次分享能提供给大家一个参考
本次分享并不会全文聚焦于直接描述前端标准是什么样子。而是会介绍确定目标，目标拆解，到制定能力模型这一思考过程。期望大家能理解为什么会形成这个模型，模型内的每一条都是出于何种考虑。授人以鱼不如授人以渔嘛。期望能给大家后续确定自己的模型标准，提供一个参考。
重点概念：
- “六有”标准
- “三加一”模型
- 技术的“深度”和“广度”
成长目标
既然说到一套能力模型能指导个人成长。那么你的成长目标是什么？
- 资深技术专家
能设计、开发、并最终落地优秀的技术项目 - 技术管理者
能打造优秀的技术团队 - 团队内的先进个人
为团队发展做出突出贡献 - 优秀的开发工程师
编写出优雅高效的代码
上述目标好像都可以的，但是有没有什么问题？
会不会有点听着很明白，但是仔细一想又有点含糊其辞不够清晰的感觉？
会不会有一种不知道怎么实现的感觉？
就好像高中的时候,有些同学学习目标是将来要考清北、考山大、考湖大、靠中南、有的是要考全校前50名、前100名....
我当时定的目标是我要考600分.不关心能考什么学校，也不关心能考多少名。
然后我就可以细分我的各科需要考多少分才能让我总分到600.然后继续对比我当前各科差异多少分。
然后从自己的错题集里找分。 努力把自己易错的题目，变成不易错得。考试的时候就能多得几分了。多掌握几个，自己单科就能达到目标分数了。以此类推，总分也能实现目标。自己努力得点也就梳理出来了。。。。
那关于个人成长有没有一种更好衡量的目标?
这里我换了一个角度来理解目标:
"追求卓越,成功就会在不经意间追上你"——《三傻大闹宝莱坞》
让自己成为一个可以不断解决工作问题的人。
具有不断发现问题并不断解决问题的能力，能不断自我迭代不断进步。
具备上述能力的人，最初列举的目标只是其成长路上的某一阶段的表现
继续细化一下成长目标是成为一个“六有青年”
“六有”标准
讨论一个场景：
在日常工作中，肯定会或多或少的出现各种问题。
这里不同的人会有不同的反应：
1、识别不到问题，稀里糊涂开展工作；（浑浑噩噩）
2、能识别问题，无心改善，一边吐槽，一边忍受现状，也可能是逃避问题，避而不谈；（无能狂怒）
3、能识别问题，有心改善，但是毫无头绪，有心无力；（有心无力）
4、能识别问题，有心改善，但是鉴于相关积累不足，制定不出有效的改善方案，效果不理想；（力有不逮）
5、能识别问题，有心改善，有相应的解决办法。但是受限于环境问题，解决方案无法推行落地；（谋事在人，成事在天）
6、能识别问题，有心改善，有相应的解决办法，可以推动解决方案落地生效，真正解决问题；（人定胜天）
有想法、有目标、有行动
有方法、有战功、有战果
能力模型(3+1)
如何定义能力
审视工作：工作到底是什么？
我们试着抽象出来一个普适的标准：处理日常工作、以及处理工作中遇到的问题
那么能力的定义：
- 执行日常工作的能力： 不同岗位的日常工作内容不同、不等级别的日常工作也不同
- 处理工作中遇到问题的能力： 不同岗位不同级别遇到的问题不一样，都需要处理各自遇到的问题
日常工作
一个问题：如果有人问你前端开发都做什么，你会怎么回答？
通过这个问题得答案，基本上能看出来你大概会怎么定义前端模型。
有没有人心里第一反应是：需求实现、写页面、画UI、改bug、打包、发布、封装组件、运维。。。。
路走窄了，兄弟们
如果自嘲一下这么说说还行，心里一定不要这么想。
我们剖析一下我们日常得工作内容（技术开发，非技术管理）：
- 先拿一个全新的项目为例：
1、项目需求评估
2、项目立项
3、实现方案设计
4、需求拆解
5、开发排期
6、编码开发
7、自测
8、提交测试
9、修复bug
10、环境配置
11、打包发布
12、线上运维
13、版本迭代 - 再拿迭代项目为例：
1、需求评估
2、方案设计、开发排期
3、编码开发
4、自测、提测
5、bugfix
6、打包发布
7、线上运维
这些是固定环节
在这期间还有哪些其他内容：
1、开会，各种会： 日会、站会、周会、沟通会、汇报会、总结会、对齐会、分享会。。。
2、不定期和产品沟通对齐需求细节
3、和UI沟通设计稿
4、和后端沟通接口
5、解答别人的疑问
6、网上检索相关资料
7、方案调研
有没有发现，从时间、精力分布上来看，编写代码的占比，并不是全部?甚至占比都不能说特别高？
说了这么多工作内容，是为什么呢?
是像引导大家思考一下，在这些工作内容中，需要哪些能力、继而才能总结出对应的能力模型。
总不能把一个职业运动员的能力模型，匹配给一个科研工作者吧？
甚至把足球运动员的放到篮球运动员身上也都是不合适的。
说了这么多 下面看一下我个人的一些思考
主要分为三个方面（必备）：
- 专业技能、落地能力、技术判断力(技术视野)
另外一个很重要但是很容易被忽略的部分（附加项）：
- 软技能
专业技能
指从事技术开发，必须的专业技能。这里面也分了很多层次，基础知识、框架、技术方案/技术领域。大概如下图所示：
从广度和深度做一下对比。
广度
是指涉及到的知识面的范围。
这里需要提示一下，有不少人会认为，自己在广度上会的越多，自己就会从初级变成中级高级。然后会有一些人不断地学习新技术、新框架，以为这样自己就能完成进阶了。
举几个例子：
例子一
1、比如有人会认为自己会react了也会node了，前后端都会了。自己可以独自开发一个商城应用了。自己很厉害，是全栈工程师了。
例子二
2、类比一下建筑业。某个人会砌墙，也会贴瓷砖，也会吊顶。甚至在农村可以给街坊邻居盖出一间三室两厅的平房出来，你会认为他是一个建筑工程师吗？可以负责承担一栋大楼的建设工作吗？
例子三
3、再举个例子。某个人他只会砌墙，他知道不同的砖砌墙的注意事项，了解不同的砖的加工生产过程，熟悉不同的砖的市场价格，知道不同材质对砖造成的影响，也知道不同的砖砌到一起后，对墙产生的影响。知道不同结构的墙的承重特性。你这个时候会怎么看待这个人？会不会觉得很专业？
据上述几个例子，就想说明平时大家自嘲使用的“码农”和“工程师”的区别。有不少人从业十多年，依旧属于码农的阶段。不够深入。
前端技术广度上来看，我认为包含下述内容：
- 计算机基础： 操作系统、计算机网络、算法与数据结构
- 前端三件套：css、html、JavaScript
- 平台：pc浏览器、手机浏览器
- 框架工具：vue、react、electron、nodejs、nginx、webpack、
- 技术方案： 微前端、低代码、跨平台、秒杀、大促、直播、聊天室、地图、线上监控。。。。
深度
怎么理解深度？可以尝试从以下几个方面来理解：
- 框架全貌的理解
- 产生的背景
- 解决的问题
- 特性
- 优缺点对比分析
- 源码解读和理解
- 浏览器内核
- 渲染过程
- 技术选型的思考
- 如何实现一套自己的方案
- antd react vue fiber 双向绑定 组件库 设计模式 架构
- plugins、proxy
- 实现原理
- 实现方案的优缺点
- 与其他方案的对比
- 参考某个方案，可不可以自己实现一套类似的，然后可以具备某些特性
这里有一个常见的误区：我就负责功能实现，面试问我原理干嘛？面试造航母，入职打螺丝。
很多同学可能经历过面试，喜欢问原理，问的很深。可能实际开发中，并不会直接用到这里原理性质的内容。就会觉得面试难度过大了。甚至觉得面试问的很奇怪。
这个时候我们再次回过头来看上述的第二和第三个关于盖房子、砌墙的例子。可能你的工作就是负责再某个项目中砌某一面墙，或者就是负责盖三间茅草屋。但是如果深度不够，原理不清晰，是很难进阶，负责更大更难的项目的。第二个例子中的人，哪怕不断的给邻居建房子，他能某一天去承建一栋大厦吗？对比看一下第三个例子中的人。如果现阶段他是负责砌墙，后面让他负责吊顶，负责贴瓷砖，负责不同的工作。后续是不是就可以逐步承建更复杂的项目？能不能再当前工作内容深入下去是能决定一个人在技术上能走多远的。
技术判断力
或许我们也可以称之为技术视野。即根据自己的见识或者经验，判断要做什么能做什么的能力。这部分能力并不是能单纯的靠看文档，做项目就能具备的。需要很多经历、经验、思考、总结。 需要专业能力的不断学习和项目经验的不断思考总结积累，才能形成准确的技术判断力。
这个能力比较抽象。
举个例子来说明一下：
1、在前端中，要实现项目首次加载在1秒内，即平时常说的秒开。（或者其他技术指标）。
这个时候需要依赖技术判断力来判断，这个标准是不是合理的。是不是不可达成的。是很难达成，还是不可达成？如果不合理 那1秒这个时间指标，修改成多少比较合理？如果是可达成，这里面涉及到的技术难点是什么？实现目标的技术路线图是什么？
具备技术判断力的表现可以初略的拆分为以下两个方面：（个人理解，有待迭代）
1、能制定合理科学的目标
2、能制定出科学合理的从现状到目标的到达路径
落地能力
我们也可以简单得理解为 执行力，并大于执行力，执行力是落地能力得子集。落地能力并不是单纯的指可以完成某项工作任务的执行工作，还需要结合自己的判断力，在对的方向上，利用自己的技能将一个个拆解后得目标落地的能力。或者说一步步实现目标的能力。
举个例子：
“纸上谈兵”这个成语大家都很熟悉。赵括熟练掌握各自兵法，他爹赵奢和他讨论兵法得时候，也说不过他。然后带兵打仗的时候，几十万大军惨败。这个词充分说明了并不是具备了专业知识，有了明确的目标，最终就一定能有好的结果，落地能力：即怎么样让自己不会变为纸上谈兵的能力。
大家工作中有没有这种经历：技术水平差不多的人，去做相差不多的项目，有的人项目做起来体验好，性能好。有的项目上线以后漏洞百出，线上bug不断。有的如期上线、有的延期上线。有人天天加班，做出的东西惨不忍睹，有人轻轻松松就开发完复杂的功能。
这些例子中都涉及到了落地能力。
落地能力包括一下方面：
执行力
攻坚能力
项目管理
目标分解
会议沟通
人员管理
组织能力
软技能
其实软技能也可以归结到落地能力中。只是因为开发人员，在软技能方便，相对较弱一些，所以单独拿出来，强调一下。
- 沟通
- 演讲
- 文档编写
- 目标分解
- 面试
- 社交
举几个例子说一下。
推动某个事情。
某个项目依赖一个接口，A（前端）准备下午把这个功能开发完毕。然后A上午找B（后端）提供接口。
上午十点：
A：有个功能，需要一个接口，你能提供一下吗？
B：当前有个紧急事情，线上有个bug要处理。稍等一下
A： 好的。
等啊等。。。
上午十一点：
A：你忙完了吗？能提供一下接口吗？
B：上午开发不完了，下午给你吧
A： 好的。
下午两点：
A：接口好了吗？
B：还没有，再稍等一会吧
A：好的。
下午四点：
A：接口开发完了吗？
B：不好意思，刚刚领导叫我开个会，接口还没写好，估计弄好要到明天了
A：。。。好吧
然后这个原计划今天做完的事情，拖到了第二天。
原因是沟通工作没有约定截止时间，导致一拖再拖。
调整方法：
某个项目依赖一个接口，A（前端）准备下午把这个功能开发完毕。然后A上午找B（后端）提供接口。
上午十点：
A：有个功能，需要一个接口，你能提供一下吗？
B：当前有个紧急事情，线上有个bug要处理。稍等一下
A：那你预计什么时间能提供这个接口呢？
B：下午吧
A：那你看我们把时间定到下午三点可以吗？时间够用吗？
B： 可以的。
在这期间你完全可以处理手头上其他事情。当前事情处于pending状态，不会关心
下午三点：
A：接口写完了吗？现在我可以联调了吗？
B：不好意思，刚刚有个会被领导叫走了。接口还没有写完。。
A： 。。。好吧。那我们调整一下时间吧，你看晚上七点能提供吗？
B： 没问题
这个时间A又可以去做点别的事情了
晚上七点。接口联调
其实上面还有问题，都是A在主动推动事情的截止时间。更好的一种状态是双方都有意识的约定时间。
某个项目依赖一个接口，A（前端）准备下午把这个功能开发完毕。然后A上午找B（后端）提供接口。
上午十点：
A：有个功能，需要一个接口，你能提供一下吗？
B：当前有个紧急事情，线上有个bug要处理。稍等一下
A：那你预计什么时间能提供这个接口呢？
B：下午吧
A：那你看我们把时间定到下午三点可以吗？时间够用吗？
B： 可以的。
在这期间你完全可以处理手头上其他事情。当前事情处于pending状态，不会关心
下午一点：
B：不好意思，领导安排我一会开个会，会影响接口开发，原定的3点提供会受影响，你看我晚上七点提供给你可以吗？
A： 好的。那我们调整一下时间，就晚上七点
B： 没问题
这个时间A又可以去做点别的事情了
晚上七点。接口联调
开会
开需求评估会。
有一个需求评估会，项目经理组织前端、后端、UI、设计、产品等角色一起开会讨论评估需求内容。
项目经理：今天我们开会，讨论一个某某某需求。这个需求内容第一条是......技术同学看看有没有问题
前端： 页面是没有啥问题，UI给设计稿就行。前端实现。但是这个登录功能，需要后端提供一个接口。
后端： 我提供登录接口没有问题，只是这里涉及到一个字段得取值逻辑，我这里不清楚，我得问问某某某，找他确认一下。
项目经理：好，那这里麻烦你确认一下。 我们看一下需求第二条，内容是......
需求一条条讨论，最后梳理出好几条遗留问题。 最后大家散会。各自确认刚才的问题。
等到了下次开会，发现有的人把问题确认过了，有的人没有确认过，因为太忙，忘记了。需要再找人确认细节。。。。
又影响到了项目推进的速度。。。本来第二次会议就可以推动下一个环节的事情，由于有遗留问题没有确认，需要再次约会下次才能推动。
总结
举个例子，回顾一下这个 3+1模型：
海上航行
专业技能：熟悉各种船的操作、维修。
技术视野：知道要航行到某个终点，并且能规划出来一个合理的路线。
落地能力：船在行驶过程中会遇到各种紧急状态、突发情况、如何合理的应对，确保自己不迷路不走偏。能如期的抵达一个个终点。
软技能：在航行过程中，处理各种工作沟通，情绪调整，等主观人为因素的问题。
讨论一个场景，回顾一下“六有标准”：
我们先假定一个前提：在日常工作中，肯定会或多或少的出现各种问题。
这里不同的人会有不同的反应：
1、识别不到问题，稀里糊涂开展工作；（浑浑噩噩）
2、能识别问题，无心改善，一边吐槽，一边忍受现状；（无能狂怒）
3、能识别问题，有心改善，但是毫无头绪，有心无力；（有心无力）
4、能识别问题，有心改善，但是鉴于相关积累不足，制定不出有效的改善方案，效果不理想；（力有不逮）
5、能识别问题，有心改善，有相应的解决办法。但是受限于环境问题，解决方案无法推行落地；（谋事在人，成事在天）
6、能识别问题，有心改善，有相应的解决办法，可以推动解决方案落地生效，真正解决问题；（人定胜天）
- 是否能识别问题
依赖技术判断力 - 是否有改变现状的想法
依赖主观意愿 - 是否能提出有效的方案
依赖专业知识 - 是否能推动方案执行落地
依赖执行力，落地能力
期望每个人都可以成为“六有”青年
有想法、有目标、有行动、有方法、有战功、有战果
不同阶段的占比:
技术视野的占比随着等级的提高,占比逐渐提高
执行力基本在各个阶段都比较重要,只是具体的要求和衡量标准不太一样.
专业知识的占比随着等级的提升,逐步降低.但是专业知识是一个技术从业者的生存之本.不可懈怠.
能力分层:
初级:计算机基础扎实,良好的学习能力和文档阅读能力;以学习前端基础为主,需求实现为辅.能独立完成简单需求开发,或者在指导下可以完成复杂功能开发.
中级:前端基础良好;能承担某一项目内部,单一模块复杂功能的开发;
高级:前端基础扎实;能主导简单系统或者多模块的设计和开发;能带领并指导初中级开发;
资深:前端基础扎实;能主导大型系统的设计和开发;指导初中级开发,并能给高级开发指明工作方向;
