⾯试题：你如何理解前端的⼯作
作者：搞前端的李蚊⼦
⼊坑前端到今天也将近两年半了，这两天突然想到了第⼀次⾯试时⾯试官的⼀个问题-------你怎样理解前端的⼯作？
对于当时我⼀个⼩⽩⽽⾔完全是胡说⼀通，词不达意，搞得⾯试官⼀脸懵逼，现在想想那可能就叫尬聊吧……时隔两年在不断爬坑中对这个问题有了⾃⼰新的认识，今天趁着上午没什么事情，写下这篇博客，想到哪写到哪，谈⼀谈我所理解的前端。
技术⽅⾯：
第⼀阶段(新⼿村)
⼀个前端初学者必须所掌握的核⼼技能HTML，CSS，Java，这三项是前端最底层的技术⽀持了，如果你看⼏年前的回答应该还会有⼀项jquery，但我个⼈觉得现阶段的前端圈jquery可以不作为必备技能，虽然Jquery对新⼈很友好，但现在mvvm框架满天飞Vue，Angular，React三分天下，⽤起来要⽐直接操作dom的jquery舒服很多，当然在这个阶段是打基础的阶段框架，类库什么的可以往后靠。原⽣Js永远都是重中之重，只会⽤框架不懂底层原理永远达不到精通，推荐Java⾼级程序设计，吃透打
牢基础再去学习其他框架，妈妈就再也不⽤担⼼你的学习。接下来还有⼀项额外的技能PhotoShop，要知道ps可以不⽤去做，但必须要会，⽽且在⼀些⼩公司⾥UI只会丢给你⼀个PSD，没有什么Sketch之类的东西，也没⼈帮你切图，这些都需要你⾃⼰来处理，所以ps是额外的必备技能。
第⼆阶段(副本开启)
进⼊告诉成长阶段，开始打怪升级，这个阶段的时间持续最长，在这期间你需要爬⽆数的坑，积累各种失败的经验，⼀关⼀关的往下刷，关于HTML和CSS你需要知道各种UI框架的使⽤，如BootStrap，ElementUI……，关于不同图⽚的格式标准，浏览器的兼容性，移动和pc端的区别，响应式布局，flex布局，栅格布局，对设计审美的提升…等关于提⾼你页⾯开发效率的各种技能，UI框架这⼀块⽐较杂选⾃⼰感兴趣的看看就好。
Js⽅⾯这时候已经可以开始挑⼀种主流框架进⾏学习了，前⾯提到的Vue，Angular，React都是不错的选择，并且对⾯向对象编程，对象封装，原型继承，闭包，同步异步差异，等⼀系列的js进阶知识应该进⾏深⼊了解，同时对es6标准也需要了解，可以参考阮⼀峰⽼师的es6⼊门，书中包含了es6的各种新特性，默认参数，模版表达式，多⾏字符串，拆包表达式，改进的对象表达式，箭头函数 =&>，Promise，块级作⽤域的let和const，class类，模块化等常⽤特性。可以做到⾃⼰封装组件，编写维护性⾼，可读性强的代码。
jquery在项目里是干啥的
⽽且在平时需要多看别⼈写的代码，汲取别⼈的优点，并且阅读⼤量的技术⽂献，最重要的是要总结⾃⼰的问题，⽐如说你遇到⼀个bug，迷迷糊糊的就解决了，下⼀次你⼜遇到相同的问题，这个时候有没有对之前问题进⾏总结的效果就看出来了。
第三阶段及更⾼级
了解各种设计模式，看得懂各种框架源码，前后端通吃，可以⾃⼰⼿写js框架...好吧，我还没到这个阶段就不写了...
在⼯作中
⼀个完整的的⼯作流程应该是：
⽴项--项⽬研讨--需求确认----产品出原型----后台开发同时设计师拿到原型进⾏UI设计--前端开始开发--测试提bug--改bug--重复n次--产品验收
上⾯只是⼀套笼统的流程，⾄少在前端这⽅⾯我们需要做的有梳理业务逻辑并理解业务逻辑，这对你后⾯的开发很有⽤处，同时根据需求进⾏应⽤技术的选择，项⽬结构的划分，需求模块的划分，完整项⽬的搭建，当然现在有很多可以⾃动化构建⼯具可以节省你很多时间，现在的前端开发已经不再仅仅只是静态⽹页的开发了，⽇新⽉异的前端技术已经让前端代码的逻辑和交互效果越来越复杂，更加
的不易于管理，模块化开发和预处理框架把项⽬分成若⼲个⼩模块，增加了最后发布的困难，没有⼀个统⼀的标准，让前端的项⽬结构千奇百怪。前端⾃动化构建在整个项⽬开发中越来越重要，但新⼿⼊门还是应该去尝试⾃⼰⼀点⼀点的去构建⼀个项⽬，等你多做⼏个项⽬觉得每次都这样重复好烦，⾃然⽽然的就⼊了⾃动化构建的坑，毕竟这样能让你更深刻的理解，为什么要使⽤⾃动化构建……⽐如我们主栈是vue，我们
然的就⼊了⾃动化构建的坑，毕竟这样能让你更深刻的理解，为什么要使⽤⾃动化构建……⽐如我们主栈是vue，我们最常⽤的就是vue-cli，⾃动化⼯具有很多选择如Bower、Gulp、Grunt、node、yeoman，我们应该根据需求选择最适合⾃⼰的去研究。
沟通
前端是团队⾥最应该学会沟通的⼈，界⾯有问题需要和UI沟通，数据有问题需要和后台沟通，功能有问题需要和产品沟通，测试的时候给你提bug你还需要和测试沟通……emmm⼼累
沟通ui
前端是最接近⽤户的⼈，⽤户对⼀个⽹站，软件最直观的感受是反映到前端的，可能你会说最直观的不应该是UI设计师么，你要知道我是前端我为设计师代⾔
和UI的沟通，在⼯作中我们不应该是被动的实现UI的设计，⽽是应该合理化的提出⾃⼰的想法，不然⽇后返⼯浪费的是双⽅的时间，⽐如最开始刚来公司的时候，项⽬⾥对⼀些⼩图标的图⽚还在使⽤雪碧图，但很明显随着浏览器的⽀持越来越好，svg和字体图标慢慢占据主流，我在阿⾥巴巴图标库建了⼀个项⽬把UI也拉了进来，UI把他⽤到的图标直接添加进项⽬，前端直接从项⽬⽣成字体图标引⼊到项⽬，绝逼要⽐⾃⼰慢慢切图，扣图标，合并雪碧图要省事的多，⽽且⽤起来也特别爽，想改颜⾊就改颜⾊。再⽐如你需要做⼀个图表，⽤到了echarts，你完全可以让UI基于echarts去设计样式，⽽不是让他在那⾥⾃由发挥，因为你永远不知道设计师的脑⼦⾥装了多少创意，这样节省的是两个⼈的时间，不会出现他做好样式⽽你实现不了的尴尬。
沟通产品
⼀般来说程序员和产品经理之间是最难沟通的，只有相杀没有相爱，毕竟⼦曾经⽈过：’这个需求很简单，怎么实现我不管，明天上线！’
下⾯引⽤lensuntop的⼀篇⽂章，我觉得写的⾮常好
记得有⼀个段⼦：
产品汪：程序猿，我们来实现⼀个紧急需求？
程序猿：请说。
产品汪：请根据⼿机壳的颜⾊，来实现APP启动的颜⾊。
程序猿已经在风中凌乱。。。
从这个段⼦中多少能折射出产品和技术之间的各种激情“⽕花”。产品经理眼中简单的需求，⽽在我们看来是不可能实现的。⽽程序员也⽆法理解产品经理为什么要实现这样的需求。那么，站在⼀个程序员的⾓度应该怎么样和产品经理沟通呢？
1.深刻理解需求，清楚需求的动机和缘由
我们程序员⼀定会在问，产品经理为什么想要根据⼿机壳的颜⾊来动态实现APP启动时的颜⾊。既然想听解析，那就先别急着说出⾃⼰的结论——技术上⽆法实现！既然有疑问，那就先将⾃⼰的疑问解决。
2.换位思考
产品有产品的⾓度。作为程序员我们追求的是什么？逻辑正确，更快，更容易扩展。产品追求的是什么？说实话，我⾃⼰没有深刻去思考过这个问题。站在⼀个惯性的⾓度思考可以想到：⼀个产品为什
么存在，他的存在能解决什么问题，他的⽤户体验好不好。这些才是决定⼀个产品的核⼼价值。毕竟⼯作性质影响了⼀个⼈的思维逻辑，所以这时候，我们能站在⼀个产品的⾓度去思考每⼀个需求，便显得尤其重要。
3.不放过每⼀个细节
作为程序员想必对这句话都是深深认同的。因为⼀个标点符号或者类型的错误，会导致⼀个⾃⼰意想不到的bug。产品经理在设计⼀个产品的时候，都是从⼤⽅向去想问题的，⼤⽅向没有错就⾏了，细节脱离不了⼤⽅向。这是他们想的。但是对于程序来说，却万万不能。因为⼀个细节的逻辑往往决定了整个⼤⽅向。举个例⼦：有⼀个需求，⽤户的作品需要提交审核，经过审核才可以让所有⼈看到。当产品经理交这个需求给你的时候，你能察觉到什么问题了吗？这⾥⾯有⼏个细节：1。⽤户提交审核后，⽤户可以不可以再编辑作品；2。作品是否会多次审核；3。需不需要记录审核历史；4。⽤户作品是否需要有版本的控制，如要产⽣版本，版本⼜是如何产⽣的；5。审核通过后，⽤户可以不可以再修改作品，若不可以，那么是不是其他⼈就看不见⽤户作品。。。。。。话说回来这只是⼀个简单的逻辑需求！但是涉及的细节却是太多太多。我们往往在编码的时候写不下去，就是因为给的需求太模糊，没有细化到点上。
4.换⼀种⽅式说“不能实现”
不能实现，这句话想必我们都是经常说。但是直接对产品经理说，没准会让产品经理抓狂。因为我们会让他们觉得他们提出的任何需求，我们都不能实现。但是事实并⾮如此，因为不能实现是有条件的，⽐如时间不够。所以我们要先认同产品经理的观点（“能实现”），再提出⾃⼰实现他的需求的条件是什么。因为现实产品经理也不会经常犯傻，经常提出⼀些不合理的需求，但是⾯对需求，我们需要评估实现的时间，⽽且这个时间不是那么容易评估准确的。
5.当遇到不合理的需求时，积极寻求替换⽅案
6.必须遵循⽂档精神
在开发的时候，我们往往会另外与产品经理进⾏细节化的讨论。但是这种讨论结果，我们并没有记录到产品原型⾥⾯或者需求列表⾥⾯。但是过了⼏个⽉后，我们⾃⼰往往会忘记我们当初为什么会讨论出这样或者那样的⼀个细节。所以⼀切的需求必须是根据的。从另⼀⽅⾯来说，也保障了双⽅的利益，别等到出问题的时候，不知道是谁的责任，⽽在这⼀⽅⾯，程序员往往很吃亏。
7.对⾃⼰的程序有⼀颗艺术的⼼
有⼈说过，当需求影响到代码扩展性的时候，会⾸先砍需求，⽽不是改代码！在⼀定程度上，我是认同这句话的。在我看来，程序是⼀件思想上的作品，要达到艺术的境界，从功能、体验和逻辑上都必
须是合情合理的。就像⼀件艺术品⼀样，看起来是浑然天成的！因为⼀件看起来很“丑陋”作品，⼀定是不符合⼈的逻辑和习惯的。
写到最后，感觉绕回到程序员⾃⾝了。其实跟产品经理沟通，最重要的是要明⽩到：我们是在解决问题，⽽不是在制造问题！主要抱着这个核⼼，⼀切问题迎刃⽽解
⼀般来说和后台沟通没那么多的⿇烦，约定好规则后，⼀般来说你们是通过api来沟通的，但当你调试接⼝时，出现⼀些未知的，你感觉不是⾃⼰问题的时候，及时的沟通后台是最明智的。
责任划分
相信⼤家在这⼀点上都深有感触，因为前端是最后⼀关，所有的需求都是在前端⼿⾥变成⼀个具体的产品的，这样也就导致你很容易变成背锅侠，导致项⽬延期的情况有很多种，设计图不及时，后台数据出现问题，产品临时改需求，如果你不能证明是这些问题导致项⽬延期，这个锅你必背⽆疑，唯⼀的⽅法就是--à⼝头确认--à发email到责任⼈确认--à通知上级，千万不要觉得这个⿇烦，出问题的时候会⽐这个更⿇烦的，
写不动了，以上就是个⼈爬坑后对前端的⼀些理解(ps：虽然我还在坑⾥)，也算对⾃⼰⼯作的⼀个总结吧，写的⽐较絮叨，不喜勿喷，最后祝⼤家升职加薪，到⼥朋友
END
查看更多⼲货，关注我们▼▼

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。