这里有一份简洁的前端知识体系等待你查收，看看吧，会有惊喜哦~如果觉得不错，麻烦star哈~
徘徊：道中彷徨
职业倦怠：如何面对
职业生涯的路上，每个人都会碰到职业倦怠期，要走出倦怠期，关键是理解工作区。
关于工作区，我想借用下面一张图来展示。
每一份工作都包含了这三个方面：
- 目的意义 Purpose
- 职业生涯 Career
- 工作岗位 Job
目的意义，这是工作的终极之问。它决定了你的很多选择，以及你接受什么、拒绝什么，是工作愿景背后的灵魂所在。每个人工作都会有自己的目的与意义，而且还会随着工作过程发生变化（或者说进化更合适些）。追寻目的与意义，这可能是你、我一生的工作。
职业生涯，是个人一生职业愿望的追寻过程。它由长期目标驱动，是追寻 “目的意义” 的一条你所期望的路径。而这条路径并不唯一，它因人而异，因你的 “目的意义” 而异。它构建在你工作过程中的所有经历、经验、决策、知识、技能与时运的基础之上。
工作岗位，这不过是你现在上班的地方，包括了位置、角色、关系、职责与薪酬的总和。
这三个区域会有交集，这里我举个实际的例子。假如你工作的 “目的意义” 非常现实，就是希望有更多的收入改善家庭生活，住更大的房子，开更好的车。而现在的 “工作岗位” 能够提供这样让你满意的收入水平，那么你就会感到 “快乐幸福”。
而若你对 “职业生涯” 路径的期望是从程序员到架构师，甚至再到 CTO，当前的 “工作岗位” 能提供这样的发展路径，那你就会充满 “激励驱动”。显然，职业生涯一路达到 CTO，收入水平会更高，与你的现实 “目的意义” 相符合，那你就会感到 “成就满足”。
如图中所示，这三者相交的那个位置，就是你的 “工作区”。在这个区域内，工作让你有驱动力，感到快乐，充满成就感。找到了 “工作区”，很自然就会进入 “工作态”。
当职业倦怠时，自然是远离了工作区，这时很容易产生的一个决策是：换一份工作。我曾经就做过这样的决策。换一份工作没有对错好坏之分，它能改变你的工作岗位，甚至也能改变你的职业生涯路径，但它唯一不能改变的就是你对 “目的意义” 的思考与认识。
做自己所爱，是对的；爱上自己所做，也是对的，关键就是要找到什么在真正驱动你前进。
寻路：路在何方
程序员、技术主管与架构师
技术主管与过渡
技术主管，有些公司可能又叫 “技术经理”，英文一般是“Tech Leader”或简称“TL”。
技术主管是开发团队中的某位程序员需要对整个开发团队负责时所承担的角色。既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。一般一个技术主管约 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上，而余下 30% 的时间则花在为了保障系统按时交付所需要的各种计划、协作、沟通和管理上。
另一方面，技术主管即使在日常的开发实现中，重点的内容一般也不是放在某个具体的功能实现上。在完成了具体的开发任务评估、分解并分配后，技术主管应该负责设计整体代码的结构和规范，必要时引入能提高整个团队生产力的新工具，推广代码模板，总结最佳实践。并且技术主管需要经常性地关注整个团队完成一项研发任务的水平和实际要求的水平之间的差距问题，让团队不仅满足及时的软件系统交付，同时又得到成长。
现实中，一个开发团队中最优秀的程序员容易被指定承担技术主管的角色，但优秀的程序员又很容易陷入到实现功能的细节中，满足于完美的实现，优雅简洁的代码。但实际上，这样优秀的程序员转入技术主管这个角色后，就很容易尝试控制设计和代码的实现，他们很难接受代码不按照他们希望的方式去编写，这个是他们作为优秀程序员一直以来的工作习惯，长此以往他们自身很容易变成整个开发团队的瓶颈，而团队里的其他成员也未能得到足够的锻炼和成长。
所以技术主管实际相比团队里的其他程序员对系统的视角更开阔，以更有策略和长远的方式来考虑问题。他们即使拥有比团队里所有其他程序员更高超的开发实现技能，对所有开发任务拥有最强大的实现自信，也需要转变为另一种 “借助他人使之实现” 的能力和自信，因为技术主管是一个承担更广泛责任的角色，必然导致能够专注有效编码的时间会相比以前减少很多，而这一点正是优秀程序员转变为技术主管所面临的最大挑战之一。
最适合技术主管角色人，不一定是团队中编程能力最好的人，但必然是团队中编程、沟通和协作能力最综合平衡的人。而技术主管之所以是一个过渡，就在于继续往前走，如果偏向 “主管” 就会成为真正的管理者（经理），如果偏向 “技术” 就会走向架构师。
架构师与取舍
架构师是一个在业界拥有知名的称谓，但在绝大部分公司却不属于一个职位序列，许多公司都很纠结于如何定义架构师的角色，以及架构师所做的工作。
架构师能力模型，如下：
一旦选择走入架构师这条路，基本你就从一名出色的程序员这个领域走出，需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应，因为承担了更多其他职责，就必然会减少在编码实现的时间，慢慢就会怀疑自己的编码能力会退化，也跟不上一线最新的技术栈、各种酷酷的新工具。
舍得，舍得，没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得，获得了一个面，在某些点上必然面临被超越的结局。工作在一个面上，一个有经验的架构师应该能够很好地表达某些技术指导原则，借助他人使之实现，并且了解和把握什么时候该插手，什么时候该放手。
这就是架构师从技术 “实现力” 到 “掌控力” 再到 “决策力” 的能力变迁。
从程序员，到技术主管，再到架构师，名称变化了，角色的困惑我们也分析了，最后总结下这三种角色的工作内容和职责，如下表：
每种角色有不同的技术和组织职责，只是在每种职责分配的时间比例不太一样。看完上表的职责范围，是不是感觉有时安安静静地做个程序员，要心净多了。
蜕变：破茧成蝶
跨越断层，突破边界
在前文中定义过程序员的职场阶梯，而阶梯不过就是很多人已经走过的路，我们只需要沿着这条路去持续成长就能爬上还算不低的楼层。只是到了一定楼层后我们会发现上面似乎还有几层，但却看不见下一层的楼梯了。因为再往上走的人就不多了，也就没能成了路，自然也就看不见，这可能就是所谓成长阶梯的断层。
在程序员的成长阶梯上，到了一定阶段，我们可能会面临方向的选择，不同的方向选择意味着不同的路径，会碰到不同的断层，而跨越断层也需要不同的方法。
那我们会面临怎样的方向选择呢?
方向
在我的技术成长路上，我看到了三个方向，正好可以用三个字来表 达:“高”“精”“尖”。
“高” 指的是 “高级(High-grade)”，“精” 代表 “精确(Precision)”，而 “尖” 则是 “尖端(Advanced)”。这是我所看到的技术人前进的三个主要方向，而这 三个方向的走向往往还是互斥的。
高级，说的不是更高级的技术，因为技术之间的横向比较没有高低级之分，比如操作系 统、数据库、网络编程、机器学习等技术，没法比出个高下。这里的“高级”，如其英文 是更高等级的意思，是职位和人的级别。而往高等级走的技术人，离 “精” 自然只能越来 越远，毕竟站的高就只能看得广，但很难看得精确了。
精确，就是把一门技术做到真正的精通。现在技术的分工越来越细，通常能精通一两个细 分领域已实属不易。而要做到精，其实越往后付出越多，但感觉提升却变得越来越慢。都 到 95 分了，再往后每提升 1 分都需要付出艰辛的努力。走到细微深处，也很难再看得 远、看得广了。
尖端，似乎听起来像 “精” 的极致，其实不然，这完全是另一条路。“高” 与 “精”， 是工业界的实践之路，而 “尖” 是理论界的突破之路。只有能推进人类科技进步的技术才 称得上尖端，就如 IT 界历史上著名的贝尔实验室里的科学家们做的工作。
“高” 是往宏观走，“精” 是往微观走，“尖” 是去突破边界。
这三条路，“高” 和 “精” 的方向在业界更常见，而 “尖” 不是工业界常规的路，毕竟 业界拥有类似贝尔实验室这样机构的公司太罕见，所以 “尖” 的路线更多在学术界。因而 后面我们主要探讨 “高” 和 “精” 两个方向的路径断层与跨越方法。
高
高的两条典型路线如下:
- 程序员—架构师—技术领导者
- 程序员—技术主管—管理者
往高处走，每一次角色的转变，都是断层。有时候，公司里到了一定级别的程序员就会被冠以架构师的称呼，但工作的实质内容依然是资深程序员平时做的事，如:一些关键系统的设计和实现，解决一些困难的技术问题。
这些工作中的确有一部分也算是架构师的内容，但如果不能认识到架构师工作内容的实 质，再往高处走也就很难实现断层的跨越了。而架构工作的实质是创造一个模型，来连 接、匹配关于业务、技术和团队之间的关系。
其中的 “业务” 属于架构师工作内容中的领域建模;“技术” 是匹配领域模型的技术实 现模型;“团队” 是关于个体之间如何组合的结构，需要满足个体技术能力与技术实现模 型的匹配。由这三个元素连接和匹配构成的模型中，“业务” 是变化最频繁的，其次是 “团队”，而变化频次最低的反倒是 “技术”。
每一项元素发生变化，都意味着架构模型需要去适应这种变化，适应不了变化的模型就需 要升级。而常见的组织架构调整，也就意味着 “团队” 的沟通路径变化了，因为康威定律 (系统设计的通信结构和设计系统的团队组织的沟通结构是一致的)的缘故，必然带来架 构模型的适应性变化调整。
透过具体的实质再往高处抽象到本质，你会发现架构工作的本质是在通过模型调优生产关系，从而提高生产效率和生产力。这是一条杠杆之路，通过找到其中的关键支点去放大输出，扩大价值。
在架构模型三元素中，技术本身就是一种杠杆，而团队和业务是价值支点。
曾经，技术的草莽时期，是一个英雄辈出的年代。两个人可以创造 Unix、C 语言，一个人 也可以发明 Linux，也可以写出 Foxmail。掌握了技术，就可能创造历史，那时技术的杠 杆很高。
如今，是技术的成熟时期，个体英雄少了，更多是一种团队和集团军作战的方式。如果你是技术的绝世高手(精的极致)，那你也需要找到一支契合你技能的场景与队伍，加入进去。此时个人的技术杠杆也许不像曾经那么高，但也许你们这个队伍还是有机会能创造历史的。
前几年，Facebook 曾收购了一家叫 WhatsApp 的公司，花了 190 亿美元。这家公司当 时仅 50 人，而其中一半是技术人员，这应该是近年用技术杠杆撬动价值之最了吧。
在 WhatsApp 这个例子中的价值支点是什么?是产品(业务)，连接用户、形成网络。技 术本身的价值通过这个产品业务形态支点，在每个活跃用户身上得到了放大。
而另一个价值支点，是借助团队，但这只适合高级别的技术人员，比如:技术管理者或架构师。但团队也需要能创造真正的价值，才能实现利用杠杆放大价值的效果。在商业环境下，任何一种产品业务形态，其最终能实现价值，都会存在一个价值网络。这个网络中覆盖了各种角色，技术只是其一，若要找到最好的价值支点，那么通常会在离价值来源比较近的地方。
技术像是一根棍子，能发挥多大价值，取决于棍子本身的品质和运用的方式。而往高处走的技术人，要跨越这条路径的断层，就是要认识清楚这个价值网络，并找到最适合技术发挥的价值点。
精
精的路线是一条 “专家” 之路。
曾经在前文《定义:阶梯与级别》中定义过 “专家”，我说:专家可能就是某个领域中你 绕不过去的人吧。这个定义中包含两个点，一个是领域，另一个是绕不过去。第一点表达 了某个范围，第二个则模糊地表达了这个范围的大小，绕不过去其实是一个很大的范围 了。
比如，若你处在物理学领域，牛顿就是你绕不过去的人，之后是爱因斯坦。而在计算机领域，图灵定义了计算机的边界，也是这个领域绕不过去的人。但这样的天才人物，百年来才出一个，如果都要达到这个水平才算是专家，可能就太难了，从而失去了指导意义。
如今反思，其实用这两点来定义专家也是可以的，只是需要更清晰地明确领域和量化范围。大至国家、社会、行业，小到公司、团队、小组，都有自己关于专家的定义。
走向专家之路，就是精确地找到、建立你的领域，并不断推高壁垒和扩大边界的过程。
那么如何建立属于自己的、更大范围内且具备足够识别性的领域?这就是 “精” 的路径中 的非连续性断层问题。曾经读过一篇吴军的文章，谈到了工程师成长中的类似问题，他用 了一个公式来描述解法:
成就 = 成功率 x 事情的量级 x 做事的速度
在连续的成长阶段，我们的成长主要体现在不断提升做事的熟练度，也就是上述公式中的速度和成功率，但这两个指标到了一定的熟练度阶段后就会碰到物理极限。实际情况是，一个资深的工程师的速度甚至不会比一个初级工程师快两倍，但可能成功率会高几倍，甚至十倍，这就是传说中的一个顶十个的程序员，但离极限也就差不远了。
而要成为传说中以一敌百的程序员，只有一个可能，他们做的事情和其他人不在一个量级 上。现实案例中，就有如 Linus 这样的人。所以，一直做同样的事，都是写代码，也可以 跨越断层，但关键是，你写的代码体现在什么量级的事情上。
之前在工程思维中总结过:问题的量级变了，逻辑就不一样了。作为程序员，我们会有直 观的感受，用户量级越过了一定的门槛后，我们编写、维护和部署程序系统的方式都会发 生本质的变化。而提升量级最难的就在于我们要放下曾经熟悉的方式和习惯，站在更高的 维度去看更大量级的事情，并且找到适合这个量级事情的合适解决方案。
面临成长路上的非连续断层，以及角色之间的无形壁障，该如何跨越断层，突破边界?我 们着重从成长路线的两个方向:“高” 和 “精”， 提供了分析和解法。
- 高的路线，需要借助技术的杠杆，认清所处的价值网络，找到合适的价值点，撬动更大的价值;
- 精的路线，在做事情的成功率和速度接近自己的极限后，只能去提升事情的量级，才能发挥出专家的价值。
成长蓝图，进化跃迁
回顾过去，我们会清晰地看见走过来的路线，但面向未来我们又该如何走下去?但凡过往，皆为序章，过去不可变，未来才是希望，而如何去规划并管理好未来的成长进化之路，才是我们当下要面临的主要任务。
我们先从一个高度抽象的维度，来看看这条成长之路。
一、成长路线
结合我自己的经历、思考与总结，我对走过的路和未来的路概括成如下这张图:
图中描述了好几个阶段，从一个阶段到下一个阶段，都会经历一次转折。
1. 开发代码(Develop Code)
从刚走出学校到进入职场成为一名新手程序员，在最初的一两年内，你可能都处在这个阶 段。不停地大量写代码，为各类系统的“大厦”添砖加瓦，像块海绵一样，把自己吸得满 满的，朝 9 晚 24 地工作与学习，并不时自嘲为 “码农”。
这个阶段，你为生存所需(迫)，会强烈地渴望成长。
2. 开发系统(Develop System)
三、五年后，你可能从初级、中级成长到了高级，此时你不再仅仅是写代码搬砖，而是开始负责起或大或小的整个系统。这时，你最关心的是如何用最好的技术方案，去开发、优化和完善系统。
3. 开发产品(Develop Product)
从高级走向资深、专家或架构师，你会发现你的技术执行技能已经优化到了相当的程度，这时往前多走一步，关注你所实现的系统所属的产品，会让你打开新的空间，找到更有效率和效果的实现路径，减少做无用功。而且在技术的世界里，有很多面向开发者的技术型产品，这个领域中最适合承担起产品经理角色的就应该是各类资深的技术专家和架构师了。
4. 开发团队(Develop Team)
当你选择走上技术主管并转变为一名管理者，那么人和团队将成为你的主要开发对象，而 不再是代码了，这是成为管理者的必经之路。
5. 开发梦想(Develop Dream)
梦想这个东西也会随着岁月与你相伴成长，梦想实际永远在前方，它只是不断引领着你往 前走。梦想相对而言是一个感觉上很 “虚” 的概念，它可能需要产品作为载体，也需要团 队来一起开发创造。如此，梦想的引力就会引发你向一名创新者或领导者的方向进化跃 迁。比如说，十多年前，刚毕业时，我的梦想是成为一名架构师，如今已然实现。
以上这张图只是帮你看清从过去到未来的一条路，但如何走好这条路，就需要另一个视角维度的蓝图了。
二、战略蓝图
战略这个词，通常会和组织、公司关联在一起;那假想下，如果个人是一家公司，那么这 家 “公司” 的战略该如何确定?
在分析战略之前，我们需要先分析下公司的业务。为了更好地分析清楚公司的主要业务， 这里借鉴下咨询公司爱用的商业分析模型:波士顿矩阵。实际有很多不同的分析模型，我 只是觉得这个最简单，比较适合像个人这样的小小微 “公司”。
波士顿矩阵模型，把公司业务分成下面四类:
- 现金牛业务
- 明星业务
- 问题业务
- 瘦狗业务
现金牛业务，比较形象地表达了就是产生现金的业务。比如谷歌的搜索业务、微软的 Windows 操作系统，都是它们的现金牛业务，有很高的市场占有率，但成长率相对就比 较低了。
就个人来说，现金牛业务自然是一份稳定的工作，产生现金，维持个人生活的基本面，当 然稳定之外越高薪越好。程序员这个职业就是很好的现金牛业务，行业繁荣，工作也比较 稳定，专注于这个业务，不断提升薪资水平，这就是:活在当下。
明星业务，比较形象地表达了很有前景的新兴业务，已经走上了快速发展的轨道。比如: 亚马逊的云计算(AWS)就是它的未来之星。而个人呢?如果你的现金牛业务(级别和薪 资)已经进入行业正态分布的前 20%，那么再继续提升的难度就比较大了。
个人的明星业务是为未来 5 到 10 年准备的，就是现在还并不能带来稳定的现金流但感觉 上了轨道的事。于我而言，是投资理财。人到中年，除了劳动性收入，资产性收益将作为 很重要的补充收入来源，而当资本金足够大时，很可能就是未来的主要收入来源。当你开 始在考虑未来的明星业务时，这就是:活在未来。
问题业务，比较形象地表达了还有比较多问题的业务领域，面临很多不确定性，也就是还 没走上正轨。将来到底是死掉，还是成为新的明星业务，现在还看不清楚。比如谷歌的无 人驾驶、机器人等业务领域都属于此类。
就个人而言，可能是一些自身的兴趣探索领域。于我来说，目前就是写作和英语，即使写 作已经开了专栏，但并不算是稳定可靠的收入来源，主要还是以兴趣驱动，投入时间，不 断探索，开拓新的维度，这就是:活在多维。
瘦狗业务，比较形象地表达了一些食之无味、弃之可惜的业务。瘦狗业务要么无法产生现 金流，要么产生的现金流不断萎缩。今日之瘦狗，也许是昨日的明星或现金牛，比如像诺 基亚的功能机。
就个人而言，行业在发展，技术也在进化，曾经你赖以为生的 “现金牛” 技能，可能过几 年后就会落后，逐渐变成了 “瘦狗”，无法果断地放弃旧技能、开发新技能，可能就如诺 基亚一般在新的时代被淘汰。固守瘦狗业务，那就是:活在过去。
业务模型构成了你的蓝图，而对你的各种业务进行与时俱进地布局与取舍，这就是战略。
三、进化跃迁
明晰了路线，掌握了蓝图，该如何完成你的成长进化跃迁呢?
跃迁是量子力学里的概念，指电子吸收能量后，突然跳到更高的能量级，这种不连续、跳 跃的突变，我们称之为 “跃迁”。我借用了这个概念来类比成长，从如上定义中有几个关 键点:
- 吸收能量
- 更高能量级
- 非连续跳跃
个人成长的跃迁也需要能量，在这里能量就是知识、技能和能力。完成 “能量” 的积累就 需要持续地学习和实践行动，而持续行动又靠什么来驱动?
内心的自驱力，这是稳定有效 的驱动力来源，若没有自我驱动的力量是不太可能带来持续行动的。
学习行动计划、养成行动习惯都是为了提升行动的效率，行动积累了足够的 “能量” 后， 就向更高能量级跳跃。这里更高的能量级是对知识和能力的更高维度抽象的比喻，比如: 知识模型和技能体系，就比孤立的知识点和技能拥有更高的能量级。
而第三个关键点:非连续跳跃，说明这样的进化有突变的特征。而个人知识的积累与能力的提升，其实都是比较缓慢而连续的，非连续的跳跃其实体现在机会和运气上。合适的机会若没能降临，你就没法完成跃迁。
连续的成长积累是你能掌控的部分，而跃迁的机会、运气则属于概率成分，你的努力可能一定程度上提高了概率，但它并不能导致必然的跃迁结果发生。即使机会没能到临，努力过后也许有无奈，也该当无悔了。
最后，我们总结下:
从开发代码到开发梦想，你可以画出一张你的成长路线图，从而走上进化跃迁的道路;上了路后，接着你可以利用工程师的思维模式和商业工具模型，建立一个你的成长战略蓝图去指导你如何走这条路。剩下的，就让你的努力、选择和运气来帮助你完成不断的跃迁变化吧。
