认识大前端，开启无限可能_墨刀 vue

万丈高楼平地起。开始，我们将以轻松幽默的方式，从实际工作中的开发痛点出发，以项目全生命周期为主线，对全栈有全局的认识。从整体项目分析开始，培养项目架构思维。

一、了解大前端知识体系，有全局的认知

1.1 工程师的技能树

在大前端知识体系中，每个阶段的工程师，需要有不同的知识技能储备。江湖封号程序猿（媛），业内一般称呼软件开发工程师。

1.1.1 初级工程师

初级前端工程师的标准，就是能够完成日常的功能开发和debug，可以在已有的代码基础上做修改，优化和维护；熟练使用平时开发需要用到的工具即可，无需理解原理。这时候需要学习的东西是非常多的，不过由于只要掌握80%（二八法则的比喻，前80%的知识只需要20%的精力学习，后20%深入的知识则需要投入80%的精力）的使用知识，只需要付出20%的精力就能够学会，所以会很有成就感，进步也会非常快。

阶段分析：
需要大量的项目实践经验，至少应用一个框架开发实际项目半年以上，才算真正掌握一个框架的使用。另外就是项目开发过程中运用到的各种工具，每个领域都要熟悉一种，当然，只要熟悉基本操作即可。最后，对于业内的各种话题和思想要有概念，起码做到听说过，大概知道是干什么的。整个初级工程师的学习过程大约会持续1-2年。

学习充电20%：
大量的实际开发经验；足够复杂的业务场景；业内最新信息等。

个人技能80%：

• 熟练开发语言（js/es6/ts、html/template、css/less/scss、nodejs、json等）
• 熟练开发框架（react全家桶+antd、vue全家桶+element、angular+material等）
• 熟练开发工具（IDE、shell、fiddler/charles、git/svn、mock等）
• 熟练常用库（axios、jquery、lodash、moment等）

1.1.2 中级工程师

在初级前端工程师的基础上，需要在原理上有更深入的理解。能够从较本质的层面分析和解决问题，需要具有从零搭建一个项目的能立，还要能够找出项目瓶颈和可优化的点。这时候就要触及那剩余的20%的知识了，进步的速度会慢下来，需要一定时间的沉淀。此时要适应这个节奏的变化，要耐得住寂寞，只有厚积才能薄发。

阶段分析：
经过初级工程师的阶段，现在最起码已经掌握了1个框架的使用。与初级相比，知识广度上，不会有特别大的变化，但是深度上就要差出一个档次了。当我们对一个事物熟悉到一定程度时，一般都会将其抽象化，以方便我们了解本质，寻找规律，最后达到触类旁通的境界。所以，如果你隐约的能够将之前你觉得不相关的知识联系起来时，那么知识的深度就已经达到了标准。举个最简单的例子：网络层面的缓存与计算机结构中的内存原理，有多少相似的地方？当然，单是某几个自己最常用的知识点达到足够的深度，就已经称得上是一个合格的中级工程师了。整个过程的积累需要大约2-3年的时间。

学习充电20%：
足够深度的原理干货；自己模拟造轮子；业内最佳实践等。

个人技能80%：

• 项目工程搭建及自动化（webpack/rollup/parcel/gulp等）
• 性能优化（交互、缓存、网络、运行效率等）
• 代码质量保证（eslint、stylelint、jest/mocha等）
• 其他常用领域达到初级水平以上（网络、后端、数据库等）
• 开始带人

1.1.3 高级工程师

在中级工程师的基础上，具有更好的抽象能力，透过表面看本质。此时已经在开发过程中积累了相当的经验，理解也比较深入，达到了触类旁通的层次，已不局限于框架和库，甚至是前端领域的约束，可以开始自己无中生有的造轮子了。另外，更重要的是对于团队的贡献，要能够成为一个团队的主心骨，明确团队的方向，整合整个团队的力量来做事情。

阶段分析：
此时，自己已经有了多次触类旁通的经验，也就是说自己对于学习一个新知识应该深入到什么程度，已经有了一个比较明确的认知。那么此时的学习诉求便是能够高效的获取其他领域的足够深度的知识。从线到面，构建起一整套的知识系统。中级工程师只要一直积累便可水到渠成的达到这一步。不过，身为高级工程师，也要开始关注技术意外的东西了，比如过管理团队。就像一个初级工程师熟练使用了一个框架之后，要开始学习其他方面的知识一样。高级工程师也就是螺旋上升到了另一个层面，开始了另一个循环而已。到了这个层次，基本已经实现“技术自由”了，而且一定是公司里独当一面的中坚力量。整个过程需要持续3-5年的时间。

学习充电20%：
高效获取足够深度的知识；管理方面的知识；业内趋势的判断等。

个人技能80%：

• 架构设计（UML）
• 技术选型
• 团队开发效率提升（公共组件、Travis CI、jenkins、gerrit/gitlab/Gogs、mock等的搭建）
• 难题攻关
• 项目管理（jira、asana、tpad、禅道等）
• 其他常用领域达到中级水平以上（网络、后端、数据库、运维、分布式等）
• 开始带团队

1.1.4 技术专家

在业内，要具备一定的技术影响力，以及“代表作”。所作所为可以影响整个公司，乃至整个行业。从流行的追逐者，变成了流行的创造者。当然，能力越大责任越大，公司的决策压力自然也要背负，此时已经不是管理单个团队了，而是对技术方向的全局把控，足够影响公司的战略甚至生存。

阶段分析：
到了这个境界，已经不能够简单的归为技术类了。就像前端高级工程师，已经不仅仅局限于前端这个领域一样。能够达到这个境界，相信已经不需要太多旁人的指手画脚了，能量已经大到足够影响上万人甚至更多。说白了，就是处于金字塔顶端少数的存在。除非转型，那么这个阶段基本可以一直干了，而且是自己挑公司，做自己想做的事，甚至自己当老板。

学习充电20%：
国内外顶级文章；业内痛点及瓶颈；行业及环境宏观分析等。

个人技能80%：

• 技术影响力
• 战略级技术架构
• 跨部门项目推动
• 英语

1.2 七大知识库

1.2.1HTML5知识库

HTML5知识图谱由前端技术专家、CSDN博客专家侯志强（@yisuowushinian）绘制

1.2.2CSS3知识库

CSS3知识图谱由前端技术专家、CSDN博客专家侯志强（@yisuowushinian）绘制。

1.2.3 JavaScript知识库

JavaScript知识图谱由Java高级工程师王成委（@jaune161）绘制。

1.2.4 jQuery知识库

jQuery图谱由CSDN博客专家郭晓湉（@XTQueen_up）绘制。

1.2.5 Node.js知识库

Node.js知识图谱由腾讯前端高级工程师黄丹华（@danhuang2012）绘制

1.2.6 AngularJS知识库

AngularJS知识图谱由广发证券前端开发工程师李泽扬绘制

1.2.7 AngularJS知识库

React知识图谱由蚂蚁金服前端工程师林展新绘制

二、理解大前端的定义，不再迷茫

大前端就是所有前端的统称，比如Android、iOS、web、Watch等，最接近用户的那一层也就是UI层，然后将其统一起来，就是大前端。大前端最大的特点在于一次开发，同时适用于所有平台，开发者不用为一个APP需要做Android和iOS两种模式而担心。大前端是web统一的时代，利用web不仅能开发出网站，更可以开发手机端web应用和移动端应用程序。

三、项目规划及DevOps流程

3.1项目规划

项目规划亦称 “项目设计”。专业人员对项目发起人拟建项目的全面、详细的规划。它是项目方案的具体化，是项目立项、筹资及施工阶段控制的主要依据，直接关系到项目预期目标的实现。项目规划的原则是根据一个研究得出的市场机会及项目发起人组织内的资源状况，使该项目在性能质量、成本及工期三者间达到最优的平衡。

3.2DevOps流程

DevOps流程包含：计划（plan）、编码(code)、编译(build)、测试(test)、发布(release)、部署(deploy)、运营(operate)、监控（monitor），这是一个循环的过程。

DevOps是依托容器、自动化、云计算等技术及精益化管理形成的一种项目过程,有效的促进了开发、测试、运营、运维、QA等团队间的协作，使得团队内、跨团队之间的协作得到极大的提升，可以帮助企业做到产品精益化、运营精益化、管理精益化。

从项目的全生命周期来看，DevOps实现了项目全生命周期的团队高效协作、自动化。DevOps的职责包括：开发和运维的紧密协作、测试和运维的自动化、产品持续交付、持续集成。例如DevOps打通了开发和运维之间的隔阂，加之紫定华运维的出现，大大提高了系统部署的稳定性和安全性。

当团队甚至公司之间践行DevOps理念并且团队成员都能有DevOps的思维时，才能真正做到敏捷。

四、分析实际工作中遇到的痛点以及解决办法

4.1 工作中遇到的痛点

• 产品的代码太复杂，结构不好，耦合太紧，架构设计完全错误，用户界面和核心逻辑代码混杂在一起，每当修复一个bug或者作出一些修改时，其他部分就像被病毒感染那样受到影响。
• 代码出现问题，该重写吗？
• 遇到技术难题怎么办？

4.2 解决办法

1. 审视问题当你遇到麻烦时，首先审视你的问题，看它究竟是什么样的问题，然后针对不同问题想解决的对策。审视你的问题，就是了解问题，找到问题的根源，然后从根源上解决问题。
2. 正视问题在遇到问题时，应勇于承担问题，正视你的问题，勇敢地面对，不要选择逃避。 回避并不能解决问题，反而这种置之不理会带来的伤害更大，更持久。所以在遇到问题，面对问题时应勇敢坚强。
3. 解决问题愤怒，着急和痛苦不能改变什么，问题只有你决定解决的时候才能消失，所以不要回避问题，有问题就解决，更不要一味地抱怨，抱怨不是解决问题的办法，抱怨过后，你还是要面对解决问题。所以，勇于解决问题，这样才能克服困难。
4. 继续前进解决问题以后，你应当继续前进，不要再受已解决问题的干扰，不要再一遍一遍地思考问题，这样之只会给你带来紧张和焦虑。向前看，向前走，不要让过去的问题成为你现在的绊脚石。
5. 总结经验在克服困难的过程中总结经验，当下一个类似问题出现时，你就会知道怎样解决问题了。从困难中学习，就会有新的感想，新的发现，这样可以不断补充自己的能力，使自己工作的更好。遇到困难，也是一种学习，在困难中总结经验，远胜过怨恨困难。
6. 永远不要灰心丧气不要因为一次或几次问题的出现，就开始怀疑自己的能力，开始灰心丧气。问题是每个人都不可避免的，不要让问题成为衡量你人生价值的标尺，问题在解决的过程中还可以使你的能力得到提升。所以，永远不要被问题吓到，问题可以给你带来更多的机会。
7. 时刻准备生活中会遇到各种各样的问题，在问题还未到来之前，我们应做好准备，面对困难，解决问题。问题有时是生活中最重要的一部分，接受问题，用积极地心态迎接问题，时刻准备解决问题，这样才会成功。
8. 很多程序员看别人写的代码很痛苦，心里总有一个念头让你“不要看，快扔掉”，但重写代码比起你重新整理那一堆混乱的代码还要痛苦，bug陈出不穷，你就像面对着一只自己制造出来的怪兽，看到它要毁坏村庄，却又无可奈何。时间方面更值得考量，当你用上一年时间重写代码时，你确定你的软件还会再次受欢迎吗？所以，没有完善的重写计划，不要轻易重写代码。
9. 理工科的人通常心比较大，做事不很仔细，但做开发人员却需要心细，譬如开发合同的订立，无论是合理不合理的，你想新增或者去掉某些功能等等，不可以随意按照自己的意愿去行事，必须按照合同办事；确实需要改变时，协商更改条约，再拟定新合同或者增加补充合同。
   10.我们相信问题早晚是可以得到解决的，但如果有一定数量的用户，时间就必须分秒必争，否则失去了信誉后，怎么更新、怎么完备的功能都无济于事了

五、掌握需求分析的要点及工具（墨刀/Axure/蓝湖/XMind）

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

5.1 需求分析的要点

• 功能性需求
  功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。
• 非功能性需求
  作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。
• 设计约束
  一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。

5.2 需求分析的工具

1、墨刀是一款在线设计编辑原型的工具，特点短平快，适合一些APP，小型pc工程，以及一些频繁迭代的产品，优点协同办公效率比较高，目前国内个别大公司以及中小企业都有用到，个人版本免费，但是使用页面数量有限，编辑后产品都是保存直接保存在云上，很方便。不会出现文件丢失的情况，但是也有缺点，就是在网络不通畅，延迟比较高的时候，很麻烦，原型编辑操作会有卡顿现象以及版本不一致现象，还有原型模板暂时不像axure那么丰富。

2、Axure是是历史悠久的产品经理必备工具，功能齐全，交互方式多样，模板资源最丰富，基本上你想要的效果都可以实现，适合在制作PC端软件，尤其是一些针对偏B端的产品，有着明显的优势，而且有破解版，所以使用成本相对较低，而且相比较墨刀，可以离线工作。缺点吗？当然也有，就是前期稍微学习成本相对于来说上手难一点，不过也比较简单。只要用心也很快可以学会。

3、蓝湖也是国产的一款原型协作平台，在其官网上，蓝湖将自身定位为“简单好用的团队工作台”。使用蓝湖可以导入Sketch/Photoshop和Adobe XD的设计稿（通过插件），并在蓝湖上做自动标注和交互原型。对于设计师来说，可在蓝湖进行设计图管理和自动标注。对于产品经理来说，可以在蓝湖做页面逻辑流程图和汇集产品文档。

4、XMind 是一款非常实用的商业思维导图软件，应用全球最先进的Eclipse RCP 软件架构，全力打造易用、高效的可视化思维软件，强调软件的可扩展、跨平台、稳定性和性能，致力于使用先进的软件技术帮助用户真正意义上提高生产率。

六、从原型设计、接口设计到技术栈的宏观项目架构思维

6.1 原型设计

原型设计是交互设计师与PD、PM、网站开发工程师沟通的最好工具。而该块的设计在原则上必须是交互设计师的产物，交互设计以用户为中心的理念会贯穿整个产品。利用交互设计师专业的眼光与经验直接导致该产品的可用性。

6.2 接口设计

• 安全机制的设计
  当接口涉及到用户状态时，每次请求都要带上身份验证信息。

• 接口数据的设计
  接口的数据一般都采用JSON格式进行传输

• 接口版本的设计
  数据的变化，比如增加了旧版本不支持的数据类型
  参数的变化，比如新增了参数
  接口的废弃，不再使用该接口了

6.3 四种核心架构思维

• 抽象思维
  对某种事物进行简化表示或描述的过程，抽象让我们关注要素，隐藏额外细节。

• 分层思维
  为了构建一套复杂系统，我们把整个系统划分成若干个层次，每一层专注解决某个领域的问题，并向上提供服务。有些层次是纵向的，它贯穿所有其它层次，称为共享层。分层也可以认为是抽象的一种方式，将系统抽象分解成若干层次化的模块。

• 分治思维
  对于一个无法一次解决的大问题，我们会先把大问题分解成若干个子问题，如果子问题还无法直接解决，则继续分解成子子问题，直到可以直接解决的程度，这个是分解(divide)的过程；然后将子子问题的解组合拼装成子问题的解，再将子问题的解组合拼装成原问题的解，这个是组合(combine)的过程。

• 演化思维
  在互联网软件系统的整个生命周期过程中，前期的设计和开发大致只占三分，在后面的七分时间里，架构师需要根据用户的反馈对架构进行不断的调整。我认为架构师除了要利用自身的架构设计能力，同时也要学会借助用户反馈和进化的力量，推动架构的持续演进，这个就是演化式架构思维。