前端人生

前端人生杂谈

 

我所理解的前端

入坑前端到今天也将近两年半了,这两天忽然想到了第一次面试时面试官的一个问题-------你怎样理解前端的工做?

对于当时我一个小白而言彻底是胡说一通,词不达意,搞得面试官一脸懵逼,如今想一想那可能就叫尬聊吧……时隔两年在不断爬坑中对这个问题有了本身新的认识,今天趁着上午没什么事情,写下这篇博客,想到哪写到哪,谈一谈我所理解的前端。

技术方面:

第一阶段(新手区)

一个前端初学者必须所掌握的核心技能HTML,CSS,JavaScript,这三项是前端最底层的技术支持了,若是你看几年前的回答应该还会有一项jquery,但我我的以为现阶段的前端圈jquery能够不做为必备技能,虽然Jquery对新人很友好,但如今mvvm框架满天飞Vue, Angular,React三分天下,用起来要比直接操做dom的jquery舒服不少,固然在这个阶段是打基础的阶段框架,类库什么的能够日后靠。原生Js永远都是重中之重,只会用框架不懂底层原理永远达不到精通,推荐红宝书Javascript高级程序设计,吃透红宝书打牢基础再去学习其余框架,妈妈就不再用担忧你的学习。接下来还有一项额外的技能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类,模块化等经常使用特性.能够作到本身封装组件,编写维护性高,可读性强的代码. 并且在平时须要多看别人写的代码,汲取别人的优势,而且阅读大量的技术文献,最重要的是要总结本身的问题,好比说你遇到一个bug,迷迷糊糊的就解决了,下一次你又遇到相同的问题,这个时候有没有对以前问题进行总结的效果就看出来了.

第三阶段及更高级

了解各类设计模式,看得懂各类框架源码,先后端通吃,能够本身手写js框架...好吧,我还没到这个阶段就不写了..............

在工做中

一个完整的的工做流程应该是:

立项--à项目研讨--à需求确认--à后台开发--à产品出原型--à设计师拿到原型进行UI设计--à前端开始开发--à测试提bug--à改bug--à重复n次--à产品验收

上面只是一套笼统的流程,至少在前端这方面咱们须要作的有梳理业务逻辑并理解业务逻辑,这对你后面的开发颇有用处,同时根据需求进行应用技术的选择,项目结构的划分,需求模块的划分,完整项目的搭建,固然如今有不少能够自动化构建工具能够节省你不少时间, 如今的前端开发已经再也不仅仅只是静态网页的开发了，突飞猛进的前端技术已经让前端代码的逻辑和交互效果愈来愈复杂，更加的不易于管理，模块化开发和预处理框架把项目分红若干个小模块，增长了最后发布的困难，没有一个统一的标准，让前端的项目结构千奇百怪。前端自动化构建在整个项目开发中愈来愈重要,但新手入门仍是应该去尝试本身一点一点的去构建一个项目,等你多作几个项目以为每次都这样重复好烦,天然而然的就入了自动化构建的坑,毕竟这样能让你更深入的理解,为何要使用自动化构建……好比咱们主栈是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.当遇到不合理的需求时，积极寻求替换方案

就拿段子里面的需求来讲，让咱们提供几种APP皮肤给用户进行选择，确定比原先的需求容易实现，并且也更加符合人性化。说另一个故事，有家智能家居的公司，要实现厨房水龙头，根据人声说水温几度，就能够达到几度。换个角度想，你会感受出40度和45度水的温差吗？并且根据人声判断，这又涉及到声音识别系统，你要兼容多少种语言？其实我就以为左右切换就挺智能的，彻底没有必要搞的那么复杂。因此程序员要找到一种更好更容易实现的方法。别给产品经理的想固然自乱阵脚。

6.必须遵循文档精神

在开发的时候，咱们每每会另外与产品经理进行细节化的讨论。可是这种讨论结果，咱们并无记录到产品原型里面或者需求列表里面。可是过了几个月后，咱们本身每每会忘记咱们当初为何会讨论出这样或者那样的一个细节。因此一切的需求必须是根据的。从另外一方面来讲，也保障了双方的利益，别等到出问题的时候，不知道是谁的责任，而在这一方面，程序员每每很吃亏。

6.对本身的程序有一颗艺术的心

有人说过，当需求影响到代码扩展性的时候，会首先砍需求，而不是改代码！在必定程度上，我是认同这句话的。在我看来，程序是一件思想上的做品，要达到艺术的境界，从功能、体验和逻辑上都必须是合情合理的。就像一件艺术品同样，看起来是浑然天成的！由于一件看起来很“丑陋”做品，必定是不符合人的逻辑和习惯的。

写到最后，感受绕回到程序员自身了。其实跟产品经理沟通，最重要的是要明白到：咱们是在解决问题，而不是在制造问题！主要抱着这个核心，一切问题迎刃而解

通常来讲和后台沟通没那么多的麻烦,约定好规则后,通常来讲大家是经过api来沟通的,但当你调试接口时,出现一些未知的,你感受不是本身问题的时候,及时的沟通后台是最明智的。

责任划分

相信你们在这一点上都深有感触,由于前端是最后一关,全部的需求都是在前端手里变成一个具体的产品的,这样也就致使你很容易变成背锅侠,致使项目延期的状况有不少种,设计图不及时,后台数据出现问题,产品临时改需求,若是你不能证实是这些问题致使项目延期,这个锅你必背无疑,惟一的方法就是--à口头确认--à发email到责任人确认--à通知上级,千万不要以为这个麻烦,出问题的时候会比这个更麻烦