基层知识：HTML，CSS，javascript是基本；Vue.js，AngularJS，React为主流；
原生永远是最核心的技术；
《JavaScript高级程序设计》渡劫必备神器。
下面就是PS了，早期的前端多数由美工转化而来，所以PS没问题；
现在的前端基本都是专业领域培训了，基本不懂PS；很多小公司不注重工作流程，把PSD一股脑甩给前端处理切图和标注，浪费开发大量的时间；UI的进阶有很多插件，比如Sketch什么的。术业有专攻，那是他们的学习路程；
进阶：ES6,ES7,响应式，兼容性，移动和PC端差异化，flex布局，审美等海量项目的淬炼；以及各种提高自己开发效率的技能。平时多看别人写的代码，汲取别人的优点，提高代码的可读性和维护性；
要针对自己遇到的bug多总结，多思考；高阶：掌握Node，koa框架，mysql数据库等，拿下后端基本是每个前端的终极目标；
不是说一定要做后端，而是理解了后端开发逻辑，数据库设计原理以后，才是真正打通了编程；
完整的工作流程：项目立项--立项评审--确定需求--产品原型--设计定稿--前端开发--提测--修复bug--验收--上线前端这方面我们需要做的有梳理业务逻辑并理解业务逻辑,这对你后面的开发很有用处,同时根据需求进行应用技术的选择,项目结构的划分,需求模块的划分,完整项目的搭建,当然现在有很多可以自动化构建工具可以节省你很多时间, 现在的前端开发已经不再仅仅只是静态网页的开发了，日新月异的前端技术已经让前端代码的逻辑和交互效果越来越复杂，更加的不易于管理，模块化开发和预处理框架把项目分成若干个小模块，增加了最后发布的困难，没有一个统一的标准，让前端的项目结构千奇百怪。
前端自动化构建在整个项目开发中越来越重要,但新手入门还是应该去尝试自己一点一点的去构建一个项目,等你多做几个项目觉得每次都这样重复好烦,自然而然的就入了自动化构建的坑,毕竟这样能让你更深刻的理解,为什么要使用自动化构建……比如我们主栈是vue,我们最常用的就是vue-cli,自动化工具有很多选择如Bower、Gulp、Grunt、node、yeoman,我们应该根据需求选择最适合自己的去研究。
前端是团队里最应该学会沟通的人,界面有问题需要和UI沟通,数据有问题需要和后台沟通,功能有问题需要和产品沟通,测试的时候给你提bug你还需要和测试沟通……（心塞吧）
前端是最接近用户的人,用户对一个网站,软件最直观的感受是反映到前端；交互体验更是前端项目的核心点；
和UI的沟通,在工作中我们不应该是被动的实现UI的设计,而是应该合理化的提出自己的想法,不然日后返工浪费的是双方的时间。比如通用组件的设计，每次出页面都会有一套全新的toast提示，很明显在大量开发任务的前提下，通用的统一的消息提示更能提高开发效率，而不影响页面交互体验；
前端应该跟UI沟通制定统一的通用组件，不然你会一直写重复并且不能提高技术含金量的任务；
再比如你需要做一个图表,用到了echarts,你完全可以让UI基于echarts去设计样式,而不是让他在那里自由发挥,因为你永远不知道设计师的脑子里装了多少创意,这样节省的是两个人的时间,不会出现他做好样式而你实现不了的尴尬。
如果你们的关系上升足够好，你可以让他们给你预留出时间，去尝试一下新的特效和体验；可以就用，不可以就换设计方案；（前提是UI能配合你的创新）出色的产品经理会考虑的面面俱到，你们争论的需求需求合理性而不会是逻辑缺失性的东西；一般来说程序员和产品经理之间是最难沟通的,只有相杀没有相爱。
因为“这个需求比较简单，怎么实现你自己搞定，明天要求上线”
记得有一个段子：
产品汪：程序猿，我们来实现一个紧急需求？
程序猿：请说。
产品汪：请根据手机壳的颜色，来实现APP启动的颜色。
程序猿已经在风中凌乱。。。从这个段子中多少能折射出产品和技术之间的各种激情“火花”。
产品经理眼中简单的需求，而在我们看来是不可能实现的。而程序员也无法理解产品经理为什么要实现这样的需求。那么，站在一个程序员的角度应该怎么样和产品经理沟通呢？
1.深刻理解需求，清楚需求的动机和缘由我们程序员一定会在问，产品经理为什么想要根据手机壳的颜色来动态实现APP启动时的颜色。既然想听解析，那就先别急着说出自己的结论——技术上无法实现！既然有疑问，那就先将自己的疑问解决。
2.换位思考产品有产品的角度。作为程序员我们追求的是什么？逻辑正确，更快，更容易扩展。产品追求的是什么？说实话，我自己没有深刻去思考过这个问题。站在一个惯性的角度思考可以想到：一个产品为什么存在，他的存在能解决什么问题，他的用户体验好不好。这些才是决定一个产品的核心价值。毕竟工作性质影响了一个人的思维逻辑，所以这时候，我们能站在一个产品的角度去思考每一个需求，便显得尤其重要。
3.不放过每一个细节作为程序员想必对这句话都是深深认同的。因为一个标点符号或者类型的错误，会导致一个自己意想不到的bug。
产品经理在设计一个产品的时候，都是从大方向去想问题的，大方向没有错就行了，细节脱离不了大方向。这是他们想的。但是对于程序来说，却万万不能。因为一个细节的逻辑往往决定了整个大方向。举个例子：有一个需求，用户的作品需要提交审核，经过审核才可以让所有人看到。当产品经理交这个需求给你的时候，你能察觉到什么问题了吗？这里面有几个细节：
- 1.用户提交审核后，用户可以不可以再编辑作品；
- 2.作品是否会多次审核；
- 3.需不需要记录审核历史；
- 4.用户作品是否需要有版本的控制，如要产生版本，版本又是如何产生的；
- 5.审核通过后，用户可以不可以再修改作品，若不可以，那么是不是其他人就看不见用户作品......话说回来这只是一个简单的逻辑需求！但是涉及的细节却是太多太多。我们往往在编码的时候写不下去，就是因为给的需求太模糊，没有细化到点上。
4.换一种方式说“不能实现”不能实现，这句话想必我们都是经常说。但是直接对产品经理说，没准会让产品经理抓狂。因为我们会让他们觉得他们提出的任何需求，我们都不能实现。但是事实并非如此，因为不能实现是有条件的，比如时间不够。所以我们要先认同产品经理的观点（“能实现”），再提出自己实现他的需求的条件是什么。因为现实产品经理也不会经常犯傻，经常提出一些不合理的需求，但是面对需求，我们需要评估实现的时间，而且这个时间不是那么容易评估准确的。(你只要尽全力实现产品的需求，产品也会慎重对待你的难度)
5.当遇到不合理的需求时，积极寻求替换方案就拿段子里面的需求来说，让我们提供几种APP皮肤给用户进行选择，肯定比原先的需求容易实现，而且也更加符合人性化。说另外一个故事，有家智能家居的公司，要实现厨房水龙头，根据人声说水温几度，就可以达到几度。换个角度想，你会感觉出40度和45度水的温差吗？而且根据人声判断，这又涉及到声音识别系统，你要兼容多少种语言？其实我就觉得左右切换就挺智能的，完全没有必要搞的那么复杂。所以程序员要找到一种更好更容易实现的方法。别给产品经理的想当然自乱阵脚。我们常说的：拒绝别人方案的时候给他一个更合适的解决方案；
6.必须遵循文档精神在开发的时候，我们往往会另外与产品经理进行细节化的讨论。但是这种讨论结果，我们并没有记录到产品原型里面或者需求列表里面。但是过了几个月后，我们自己往往会忘记我们当初为什么会讨论出这样或者那样的一个细节。所以一切的需求必须是根据的。从另一方面来说，也保障了双方的利益，别等到出问题的时候，不知道是谁的责任，而在这一方面，程序员往往很吃亏。7.对自己的程序有一颗艺术的心有人说过，当需求影响到代码扩展性的时候，会首先砍需求，而不是改代码！在一定程度上，我是认同这句话的。在我看来，程序是一件思想上的作品，要达到艺术的境界，从功能、体验和逻辑上都必须是合情合理的。就像一件艺术品一样，看起来是浑然天成的！因为一件看起来很“丑陋”作品，一定是不符合人的逻辑和习惯的。写到最后，感觉绕回到程序员自身了。其实跟产品经理沟通，最重要的是要明白到：我们是在解决问题，而不是在制造问题！主要抱着这个核心，一切问题迎刃而解一般来说和后台沟通没那么多的麻烦,约定好规则后,一般来说你们是通过api来沟通的,但当你调试接口时,出现一些未知的,你感觉不是自己问题的时候,及时的沟通后台是最明智的。
责任划分相信大家在这一点上都深有感触,因为前端是最后一关,所有的需求都是在前端手里变成一个具体的产品的,这样也就导致你很容易变成背锅侠,导致项目延期的情况有很多种,设计图不及时,后台数据出现问题,产品临时改需求,如果你不能证明是这些问题导致项目延期,这个锅你必背无疑,唯一的方法就是--口头确认--钉钉通知到责任人确认--通知上级,千万不要觉得这个麻烦,出问题的时候会比这个更麻烦的。
合格的web前端工程师尚且需要好多修炼，入门级的web前端工程师也是不容易达到的。想要成为一名web前端工程师，从知海匠库http://www.zhihaijiangku.com的web前端课程开始。课程结合项目实战，还有就业指导，帮助新手快速入门并就业。
