Original: www.cnblogs.com/Smiled/p/8377188.html
It has been nearly two and a half years since I entered the front end of the pit. In the past two days, I suddenly thought of a question from the interviewer during the first interview - How do you understand the work of the front end?
For me, a novice at the time, it was a complete nonsense. The words didn't convey the meaning, which made the interviewer look dazed. Now that I think about it, it might be called an awkward chat. With my new understanding, I took advantage of nothing in the morning to write this blog, where I wanted to write it, and talk about the front end that I understand.
Technical aspects:
The first stage (novice village)
The core skills that a front-end beginner must master are HTML, CSS, and JavaScript. These three items are the bottom-level technical support of the front-end. If you look at the answer from a few years ago, there should be a jquery, but I personally think that at this stage The front-end jquery can not be used as a necessary skill. Although Jquery is very friendly to newcomers, the mvvm framework is full of Vue, Angular, and React. It is much more comfortable to use than jquery that directly manipulates the dom. The stage framework, class library, etc. can fall back. Native JS is always the top priority. You can only use the framework if you don’t understand the underlying principles and you will never be proficient. I recommend the Red Book Javascript advanced programming. After reading the Red Book and laying a solid foundation, you can learn other frameworks. Don't worry about your studies. Next, there is an additional skill PhotoShop, you know that ps can not be done, but you must know, and in some small companies, the UI will only throw you a PSD, there is no such thing as Sketch, and no one can help You cut pictures, these need to be handled by yourself, so PS is an additional must-have skill.
The second stage (dungeon open)
Enter the stage of telling growth, start fighting monsters and upgrade. This stage lasts the longest. During this period, you need to climb countless pits, accumulate various failure experiences, and brush down one level at a time. Regarding HTML and CSS, you need to Know the use of various UI frameworks, such as BootStrap, ElementUI..., about the format standards of different images, browser compatibility, the difference between mobile and pc, responsive layout, flex layout, grid layout, improvement of design aesthetics ...and other skills to improve the efficiency of your page development, the UI framework is more interesting to choose and look at.
In terms of Js, you can start to pick a mainstream framework for learning. The aforementioned Vue, Angular, and React are all good choices, and for object-oriented programming, object encapsulation, prototypal inheritance, closures, synchronous and asynchronous differences, A series of js advanced knowledge should be deeply understood, and at the same time, you need to understand the es6 standard. You can refer to Mr. Ruan Yifeng's introduction to es6. The book contains various new features of es6, default parameters, template expressions, multi-line String, unpacking expression, improved object expression, arrow function =&>, Promise, let and const in block-level scope, class class, modularization and other common features. You can encapsulate components yourself and write maintainability High and readable code. And usually you need to read more code written by others, learn from others' advantages, and read a lot of technical literature. The most important thing is to summarize your own problems. For example, if you encounter a bug, If you are confused, it will be solved. Next time you encounter the same problem again, you will see if the effect of summarizing the previous problem is at this time.
Stage 3 and beyond
Understand various design patterns, understand the source code of various frameworks, take all the front-end and back-end, you can write js framework by yourself... Well, I won't write it before this stage... ....
working
A complete workflow should be:
Project approval--project discussion--requirement confirmation--product prototypes--back-end development while designers get prototypes for UI design--front-end development--test bugs--fix bugs--repeat n times --Product acceptance
上面只是一套笼统的流程,至少在前端这方面我们需要做的有梳理业务逻辑并理解业务逻辑,这对你后面的开发很有用处,同时根据需求进行应用技术的选择,项目结构的划分,需求模块的划分,完整项目的搭建,当然现在有很多可以自动化构建工具可以节省你很多时间, 现在的前端开发已经不再仅仅只是静态网页的开发了，日新月异的前端技术已经让前端代码的逻辑和交互效果越来越复杂，更加的不易于管理，模块化开发和预处理框架把项目分成若干个小模块，增加了最后发布的困难，没有一个统一的标准，让前端的项目结构千奇百怪。前端自动化构建在整个项目开发中越来越重要,但新手入门还是应该去尝试自己一点一点的去构建一个项目,等你多做几个项目觉得每次都这样重复好烦,自然而然的就入了自动化构建的坑,毕竟这样能让你更深刻的理解,为什么要使用自动化构建……比如我们主栈是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.必须遵循文档精神
在开发的时候，我们往往会另外与产品经理进行细节化的讨论。但是这种讨论结果，我们并没有记录到产品原型里面或者需求列表里面。但是过了几个月后，我们自己往往会忘记我们当初为什么会讨论出这样或者那样的一个细节。所以一切的需求必须是根据的。从另一方面来说，也保障了双方的利益，别等到出问题的时候，不知道是谁的责任，而在这一方面，程序员往往很吃亏。
7.对自己的程序有一颗艺术的心
有人说过，当需求影响到代码扩展性的时候，会首先砍需求，而不是改代码！在一定程度上，我是认同这句话的。在我看来，程序是一件思想上的作品，要达到艺术的境界，从功能、体验和逻辑上都必须是合情合理的。就像一件艺术品一样，看起来是浑然天成的！因为一件看起来很“丑陋”作品，一定是不符合人的逻辑和习惯的。
写到最后，感觉绕回到程序员自身了。其实跟产品经理沟通，最重要的是要明白到：我们是在解决问题，而不是在制造问题！主要抱着这个核心，一切问题迎刃而解
一般来说和后台沟通没那么多的麻烦,约定好规则后,一般来说你们是通过api来沟通的,但当你调试接口时,出现一些未知的,你感觉不是自己问题的时候,及时的沟通后台是最明智的。
责任划分
I believe that everyone has a deep feeling on this point, because the front end is the last level, and all the requirements are turned into a specific product in the hands of the front end. There are many kinds of delays, the design drawing is not timely, the background data has problems, and the product needs to be temporarily changed. If you can't prove that these problems caused the project to be delayed, you must bear the blame. The only way is --à Verbal confirmation- -àSend an email to the responsible person for confirmation--àNotify your superiors, don't feel this troublesome, it will be more troublesome than this when something goes wrong,
I can’t write anymore, the above is some understanding of the front end after I climbed the pit (ps: although I am still in the pit), it can also be regarded as a summary of my own work. 2018 promotion and salary increase, find a girlfriend!!!
END