近几年，前端的发展还是非常好的，市场需求大，加上学习起来也相对简单，有众多人选择并学习。现在流行前后端都会的全栈技能，我有全套web前端视频课资料可以发给你自学，是目前前沿的前端技能叫做web全栈工程师。
学习的内容包括：
①计算机基础以及PS基础
②前端开发基础（HTML5开发、JavaScript基础到高级、jQuery网页特效、Bootstrap框架）
③移动开发
④前端高级开发（ECMAScript6、Veu.js框架开发、webpack、前端页面优化、React框架开发、AngularJS2.0框架开发等）
⑤小程序开发
⑥全栈开发（MySQL数据库、Python编程语言、Django框架等）
⑦就业拓展（网站SEO与前端安全技术）
互联网行业目前还是最热门的行业之一，学习IT技能之后足够优秀是有机会进入腾讯、阿里、网易等互联网大厂高薪就业的，发展前景非常好，普通人也可以学习。
想要系统学习，你可以考察对比一下开设有相关专业的热门学校，好的学校拥有根据当下企业需求自主研发课程的能力，能够在校期间取得大专或本科学历，中博软件学院、南京课工场、南京北大青鸟等开设相关专业的学校都是不错的，建议实地考察对比一下。
祝你学有所成，望采纳。
项目微服务架构图
微服务架构根据目前产品存在的问题，针对快速开发、海量用户、大量数据、低延迟等互联网应用的实际需要，通过对业务架构、系统架构、基础架构、技术架构进行设计，彻底解决系统解耦、性能低下等问题，而且支持云计算部署，可以满足高并发、高可用、高稳定。微服务并没有一个官方的定义，可以理解为一种架构风格。
大数据管理数据处理过程图
大数据(bigdata)，指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察力。大数据处理的主要流程包括数据收集、数据存储、数据处理、数据应用等主要环节。随着业务的增长，大量和流程、规则相关的非结构化数据也爆发式增长。大数据处理，大...
产品开发流程图
产品开发流程(ProductDevelopmentProcess)产品开发流程是指企业用于想像、设计和商业化一种产品的步骤或活动的序列。产品开发流程涉及的人员从产品经理到设计师、前端、后端等等一系列人员，这篇文章主要关于产品开发的完整流程，希望对各个工作岗位上的人有借鉴意义。很多产品经理不...
阿里巴巴数据中台全景图
阿里是数据中台概念的首先提出者，其案例更具分析意义。从阿里巴巴数据中台全景图可以看出，阿里的数据中台包括了计算与存储平台、数据资产管理、智能数据研发、统一数据中心中间件（OneService）四大模块，最上层支撑着阿里数据、数据大屏、生意参谋等大数据应用。阿里数据中台架构。数据中台建设理论、方...
Web开发技术架构图
大型web系统架构动态应用，是相对于网站静态内容而言，是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件，比如论坛、网络相册。1、学习Web开发原理，包括MVC/MTV等Web框架;2、学习DjangoWeb框架，从技术原理到项目实践;3、学习Djan...
互联网工作原理拓扑图
互联网工作原理拓扑图模板，计算机网络是由很多台计算机组成的，要实现网络之间传输数据，必须要做两件事，数据传输目的地址和保证数据迅速可靠传输的措施。计算机网络是由许多计算机组成的，要实现网络的计算机之间传输数据，必须要作两件事，数据传输目的地址和保证数据迅速可靠传输的措施。拓扑图用于计算机...
管理业务流程图
业务管理是网路管理中比较重要的部分，涉及的面也比较广泛。在这一管理层，大多数的管理信息直接在GSM系统的各网路单元与GSM网路管理设施之间交换。这些管理信息还包括由AuC管理的安全性数据，由HLR管理的客户数据，由MSC管理的费率和计费数据等。业务管理(BusinessManagement)...
电商知识图谱
知识图谱(KnowledgeGraph/Vault，以下简称KG)本质上是语义网络，是一种基于图的数据结构，由节点(Point)和边(Edge)组成。电商就是电子商务的简称，在互联网上销售产品而进行的商业活动，是把现实生活中的商业活动，搬到虚拟的世界当中电商这一特殊领域的知识图谱构建过程中，...
树状网络拓扑图
树型拓扑（treetopology）：一种类似于总线拓扑的局域网拓扑。树型网络可以包含分支，每个分支又可包含多个结点。树状拓扑结构是一种分级结构。在树状结构的网络中，任意两个节点之间不产生回路，每条通路都支持双向传输、这种结构的特点是扩充方便、灵活，成本低，易推广，适合于分主次或分等级的层级...
云平台整体架构图
大厂前端项目的研发流程。即，在一线互联网公司，一个项目的开发，或者产品的迭代，从一开始到上线，都要经历哪些核心步骤、哪些角色人员。而我们前端程序员，又是如何参与其中的。
这个主题是我在一年多之前就想做的，只是一直拖到近期才产出了这篇分享。我好多年之前结识了一个创业公司的技术负责人，一直也没断了联系，有一次和他约饭，他就说：现在公司慢慢壮大，几十个人了，想了解一下大厂的开发规范，否则越大越难管理。
当时我也没做什么准备，于是就边吃边聊，把我想到的都跟他说了，不过比较散乱。从那时候开始，我就想应该很多人都有这个困惑，特别是中小型公司的管理者和程序员。于是，经过了这么久我还是最终整理出了这篇分享稿。
但是，本次分享并不是泛泛而谈，我除了会讲解各个流程、阶段和角色人员之外，还会讲到一些我们常用的工具、技术点。我觉得我也有能力给大家讲出来，因为我既是一名大厂的高级前端工程师、有一定的开发经验，又是一名PMP和项目负责人、有项目管理的知识积累和实践。
闲话不多说，画了一个流程图给大家做一个整体流程、角色、交付物的概述。
接下来给大家介绍一下各个角色。
20:03:40在说几点注意事项：
接下来我们将假想一个实际的案例（因为我们不会在这里演示如何开发）——为页面增加评论（发布评论，评论列表、点赞、回复）——这个功能，来把上述各个步骤详细分析一下，一来是再深入了解一些细节，二来是帮助大家加深对整个研发流程的理解和印象。
项目立项
这个过程我们作为FE很可能是参与不到，或者压根就不知道的。因为在需求评审之前，所有的事情都是PM来主导的，只有项目立项之后，并且PM把需求编写完成，才能流转到FE这里。总之，这个过程你不用关心，只需要知道有了这个过程，PM才能编写需求，并发起需求评审。
编写需求和需求评审
编写需求是PM的工作，我们不用关心。接下来PM会拉各个角色（UEUIRDCRDFEQA）开会，进行需求评审。会议的主要步骤：第一，PM会按照需求文档把功能全部讲一遍，包括C端的各个功能（如发布评论，评论列表、点赞、回复），也包括后台的一些策略（黄反、敏感词屏蔽）和统计；第二，各个角色的与会者提出自己的问题，PM来解答；第三，如果问题全部被解答，则评审通过，否则评审不通过。
FE参见需求评审和其他RDCRD类似，最重要的是关心这些功能的技术实现：是否可实现，或者实现成本高不高。例如，PM要在用户长按点赞按钮时显示绚丽的动画，这一点使用h5来成本太高，你就可以建议PM在h5端换成简单动画。另外，开发人员也可以对PM的功能逻辑提出质疑，不一定非得是技术问题。
评审结束之后，PM一般就会向各个开发人员要排期。注意，这时候不能立刻答应，最好的回复方式是：我们回去讨论一下，明天下班之前（或者某个未来不太久的时间点，都行）给你答复。这样，你可以和其他FE或者架构师来讨论技术方案，一起评估一个比较靠谱的排期。PS：如果你的项目有拍死的deadline，那没招了，你就安排加班吧。
编写技术方案
这一步容易被大家忽略，人类好像是本能的眼高手低，感觉看似比较简单的事情就很乐观。越是这种心态，越要谨慎行事，在这里我建议所有的公司或者团队，都把编写技术方案作为一个必要的步骤，即打开开发前必须编写技术方案，并完成评审。
技术方案到底写什么——技术方案就是写你计划如何实现需求中的功能。拿这个评论项目来说，发布功能如何实现？要调用什么接口，输入输出时什么？要不要考虑xss攻击？再如点赞，是先执行动画再调用接口，还是先调用接口再执行动画？还有，你的代码如何拆解，分几个模块，有哪些核心的方法。这些都要写。技术方案没有一个固定的格式可供参考，因此是否能把技术方案写的清晰且使用，是判断一个人技术能力的标准之一。
技术方案评审
技术方案编写完成之后，需要拉内部的经理、架构师（或者技术负责人）、其他对接的角色（RDCRD）来评审技术方案。内部人员注意评审这个方案是不是符合设计原则，有扩展性，以及是否有其他坑（如性能问题，安全漏洞等）。外部对接的角色主要评审接口是否全面，输入输出设计是否合理。
技术方案评审通过之后，就得给PM反馈排期了。注意，估算工期一定要留有buffer，给自己留好余地。有工作经验的人都知道，一个人在一个公司里，一般会同时担任很多的工作，你不能保证接下来不会有其他功能耽误你的时间。例如，这个项目你本来预估是10人/天工作量，那你最好反馈12-13人/天。PS：评审之前反馈排期也可以，只是评审之后反馈，更加靠谱一些。
补充一句。这里我们仅仅提到了FE的技术方案评审，其实CRD和RD也会有他们的技术方案评审，评审时也需要拉着FE。其实大家的关系都是相互的，彼此相互把关，出来的设计方案就不会有太大问题。
交互视觉设计和评审
交互和视觉的设计，是UE和UI要做的事情，我们不管他们怎么做。他们做完之后会拉着PMFECRDQA进行设计稿的评审，即看看这个页面最终是什么样子。FE去参加主要看看视觉的实现是否有难度，特别是对一些透明、渐变、毛玻璃、阴影等特效，要慎重对待，还有比较常见的例如1px边框的问题。这些如果你遇到了，但是不确定是否可以实现，那最好回去查查再回复他们。
评审通过之后，UI将产出设计稿给FE。按照惯例，UI应该给750像素的图，即以iphone6两倍屏为标准的图，并且设计稿中标出所有的颜色色值和间距、字体的大小。他们有专门的工具来导出这些，例如用sketch就可以轻松导出。注意，此时如果你已经给了排期，但是设计稿比较复杂的话，必须及时和PM沟通修改排期，有问题早发现早处理。
开发
有了前端的技术方案，有了客户端、后端的接口，有了视觉设计稿，这时候就可以进行开发了。一般需要从git里新拉一个分支，使用mock数据（此时后端还没有接口）。如有客户端的对接，还需要用到一些模拟native能力的插件，如果你们没有那就只能等到和客户端联调时再看了。开发产出的不仅仅是代码，还应该有开发文档（也可以是比较丰富的注释）和测试用例。
我们作为技术人员，往往以为一个软件项目最关键的就是代码开发，而传统的项目管理流程说，代码开发只占软件生命周期的1/6。根据本文相信你能体会到，代码开发真的只占软件项目的很少一部分。所以，作为程序员你要想自己值钱、有不可替代性，就要从整个软件项目的阶段入手，而不仅仅是提高开发能力。
视觉联调
代码开发完成之后，所有界面都做完了，你要告诉UI进行视觉联调。虽然你自己是按照UI给的设计稿做的，但是你不一定每一个细节都做的正确，需要UI确认。另外，各个手机屏幕的响应式做的怎样，也需要UI拿不同手机测试。他如何测试你不用管，只需要配合他就行了，遇到问题你就改。
这一步的产出是“联调报告”，不要被这个词给吓着，以为要写一个正规的文档。现实不是这样的，待UI联调完了之后，让他在项目群里@PM回复一下说“视觉联调通过”，这样就行了，这就是联调报告，有这个记录即可。包括图中所有的“报告”，最常见的形式就是邮件和群信息。但是，哪怕就是一封邮件或者群信息，短短的一句话，这个步骤也不能省略。否则谁知道视觉联调已经成功了？
程序联调
FE开发h5页，CRD开发客户端，RD开发后端接口，待大家都开发完成之后，也需要把代码放在一起联调一下。将h5和后端代码打包到同一个测试机上，既可以联调h5和后端接口。将客户端的访问地址指向这个测试机，就可以联调客户端和后端接口，也可以联调客户端和h5。联调成功之后，最好再给PM看一眼，让他确定这就是做出来的效果。
自测
这一步我是自己加的，也是我自己的做事风格。但这一步不是我自创的，在传统软件项目管流程里，就有“冒烟测试”这一步骤，也就是自测。但是，我在所有带过的团队中，都没有发现规定必须自测且产出自测记录。但是，我还是坚持自己的观点，我负责的项目必须要有自测步骤，而且我呼吁大家也要坚持自测。
自测并不是把所有功能全部详细测试，而是把核心功能都测试一遍，并记录测试结果，保证主流程是能跑通的。我相信每个有工作经验的同学都遇到过这种情况，程序员代码写完就提测给QA了，QA一运行立马报错，无法继续测试，打回来找程序员重新修改。这种事情极大影响效率，谁都不乐意看到。如何避免呢？答案就是提测前，先自测。
自测依据需求的核心功能，可以是人肉手动测试，有可以是自动化单元测试，这个不要求。但是最后要产出一个自测记录，即用一个表格，列出所有核心功能，并记录每个功能你的测试结果。为何要有这个产出，就是为了证明你真的测试过每个功能了，而不是眼高手低看两眼就通过了。一般需要产出交付物时，大家都会认真对待，没有交付物大家就可能敷衍了事。
提测
自测完成，并产出自测记录，即可以提测了。提测需要FECRDRD和PM一起，将需求文档、代码、自测记录提交给QA，并发正式的提测邮件，告知所有项目角色该项目提测了。QA收到之后，确认分析完成，需要回复计划的测试完成时间。然后QA开始测试。
测试
QA测试过程中肯定会不断的产出bug列表，此时FE应该要求QA把所有bug的描述都写清楚，即能让个自己傻瓜式的复现这个bug，以便快速修改。遇到复现不了的问题，一定要第一时间找QA来复现，有些问题复现了一次再也复现不了，那你就先别管它，先去改别的问题。QA测试完成之后，要发准出邮件，告诉所有项目角色该项目测试通过，可以准备上线了。
上线回归测试
QA测试完之后不一定能立马上线，因为一般产品的上线都是例行的。频率比较快的产品，可能规定每周一到周四下午的某个时间点可以上线，晚上一般不上线，周五一般不上线，除非紧急修复bug。因为，上线之后就有可能带来一些bug，可能晚些才能发现，如果晚上或者周五上线，一旦发现bug大家已经回家睡觉或者过周末了，不容易集中人力修改。
上线的步骤一般是先合并代码到dev或者master分支，每次上线可能是多个功能一起上线，因此合并代码时还可能会出现冲突，得先解决冲突。然后开始发起上线审批，生成上线单，需要PMQA和各个技术经理审批确认，OP才能将这个上线单解锁，这样就可以发起上线。
上线的机器一般也分好几步，每一步都需要QA参与回归测试。第一步是预览机，预览机只对内有效，外网看不到，但是加载线上的真实数据。第二步是单台机器，即线上机的一台机器。第三步是单机房，即线上机的一个机房。第四部是全量，即线上机的所有机房。这些步骤全部操作完成，并且QA全部回归测试完成，才算真正的结束。
如果其中一个步骤遇到问题，就需要启动快速回滚。回滚就是用git的上一条记录重新上线，覆盖目前的代码，步骤也是先预览机、单机器、单机房、全量，每一步也需要QA回归测试。如果bug影响严重，还需要项目的主要角色写检讨，做复盘汇报，总结教训。
项目总结（可选）
项目总结是可选的，而且我发现大部分的团队都不会去做总结，觉得上线完了就大功告成，该启动下一个项目了。但我觉得，无论是不是做项目，做完一件事（如看完一本书）就应该自己总结一下。回顾一下经过，总结一下得失，积累一点经验，这样才能慢慢成长。
有想要学习前端或者转行前端的朋友可以私信小编“学习”，前端开发全套教学资料，大神带你学前端
