It has been nearly two and a half years since I entered the pit front end. In these two days, I suddenly thought of a question from the interviewer during the first interview-how do you understand the front end work?
For me as a novice at the time, it was completely nonsense, and the words were not expressing the meaning, which made the interviewer look confused. Now think about it, it may be called awkward chat... After two years of constant crawling on this question With my new understanding, I took advantage of nothing in the morning to write this blog, where I thought about writing, and talk about the front-end as I understand it.
Technical aspects:
Phase 1 (Novice Village)
A front-end beginner must master the core skills HTML, CSS, and JavaScript. These three are the bottom technical support of the front-end. If you look at the answer a few years ago, there should be another jquery, but I personally think that it is at this stage. The front-end circle jquery can not be used as a necessary skill. Although Jquery is very friendly to newcomers, now the mvvm framework is full of Vue, Angular, and React. It is much more comfortable to use than jquery that directly operates dom. Of course, it is a foundation at this stage. The stage framework, class library and so on can be moved forward. Native Js is always the top priority. It will only use the framework to not understand the underlying principles and will never be proficient. Recommend the Red Book Javascript advanced programming, learn the Red Book and lay a solid foundation before learning other frameworks, mother will never Don't worry about your study. Next, there is an additional skill PhotoShop. You need to know that PS can be done without doing it, but you must know it, and in some small companies, UI will only give you a PSD. There is nothing like Sketch, and no one helps. If you cut the picture, you need to handle it yourself, so ps is an additional necessary skill.
The second stage (dungeon open)
Enter the telling growth stage and start to fight monsters and upgrades. This stage lasts the longest. During this period, you need to climb countless pits, accumulate various failure experiences, and scan down one level. Regarding HTML and CSS, you need Know the use of various UI frameworks, such as BootStrap, ElementUI..., about the format standards of different pictures, browser compatibility, the difference between mobile and PC, responsive layout, flex layout, grid layout, and the improvement of design aesthetics …And so on for the various skills to improve the efficiency of your page development, the UI framework is more of a miscellaneous selection of what you are interested in.
On the Js side, 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, prototype inheritance, closures, synchronous and asynchronous differences, A series of advanced js knowledge should be deeply understood, and at the same time, you need to understand the es6 standard. You can refer to teacher Ruan Yifeng’s introduction to es6. The book contains various new features of es6, default parameters, template expressions, and multiple lines. Strings, unpacking expressions, improved object expressions, arrow functions =&>, Promise, block-level scope of let and const, class classes, modularization and other common features. You can encapsulate components by yourself and write maintainability High, readable code. And in normal times, you need to read the code written by others, learn from the advantages of others, 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, you can solve it. The next time you encounter the same problem, you can see if there is a summary of the previous problems at this time.
Stage 3 and higher
Understand various design patterns, understand the source code of various frameworks, take the front and back ends, and you can hand-write the js framework by yourself...Well, I will not write before this stage... ....
working
A complete workflow should be:
Project establishment-project discussion-demand confirmation-product prototype-background development while the designer gets the prototype for UI design-front-end development-test bug-change bug-repeat n times --Product acceptance
The above is just a set of general processes. At least in the front end, we need to sort out the business logic and understand the business logic. This is very useful for your future development. At the same time, you can choose the application technology and divide the project structure according to your needs. The division of demand modules and the construction of complete projects. Of course, there are now many automated construction tools that can save you a lot of time. Now the front-end development is no longer just the development of static web pages. The ever-changing front-end technology has made the logic of the front-end code and The interactive effects are becoming more and more complex and more difficult to manage. The modular development and preprocessing framework divides the project into several small modules, which increases the difficulty of final release. Without a unified standard, the front-end project structure is strange. Front-end automation construction is becoming more and more important in the entire project development, but novices should still try to build a project by themselves bit by bit. When you do a few more projects, it feels annoying to repeat this way every time, and naturally enter After all, this will give you a deeper understanding of why you should use automated build...For example, our main stack is vue, and our most commonly used is vue-cli. There are many options for automation tools such as Bower, Gulp, Grunt , Node, yeoman, we should choose the most suitable one to study according to our needs.
communication
The front-end is the person who should learn to communicate most in the team. If there is a problem with the interface, you need to communicate with the UI. If there is a problem with the data, you need to communicate with the backend. If there is a problem with the function, you need to communicate with the product. When you are testing a bug, you need to communicate with the test... emmm tired
Communication ui
The front-end is the person closest to the user. The user's most intuitive feelings about a website and software are reflected in the front-end. Maybe you would say that the most intuitive should not be a UI designer. You have to know that I am the front-end and I speak for the designer. !!!
Communicating with the UI, we should not passively implement the UI design at work, but should rationalize our own ideas, otherwise the rework in the future will waste the time of both parties, such as when we first came to the company, in the project Sprite images are still used for pictures of some small icons, but it is obvious that with the better and better support of browsers, svg and font icons are gradually occupying the mainstream. I built a project in the Alibaba icon library to pull the UI. Come in, the UI directly adds the icons he used to the project, and the front-end directly generates font icons from the project to import into the project. It is absolutely necessary to cut the image slowly, deduct the icon, and merge the Sprite image. It is much easier, and it is also easier to use. It's really cool. Change the color if you want. For another example, if you need to make a chart and use echarts, you can completely let the UI design styles based on echarts, instead of letting him freely play there, because you never know how much creativity is installed in the designer's mind, which saves It is the time of two people, there will be no embarrassment that he makes a good style and you can't achieve it.
Communication products
Generally speaking, it is the most difficult communication between programmers and product managers. There is only killing and no love. After all, Zi once said:'This demand is very simple, I don't care how to achieve it, and it will be online tomorrow!',
I quote an article by Lensuntop below , I think it is very well written
Remember there is a paragraph:
Product Wang: Programmer, shall we implement an urgent need?
Programmer: Please speak.
Product Wang: Please realize the color of APP startup according to the color of the phone case.
The programmer has messed up in the wind. . .
From this paragraph, it can reflect the various passion "sparks" between products and technology. The simple requirements in the eyes of product managers are impossible in our view. And programmers can't understand why product managers want to achieve such a demand. So, how should you communicate with product managers from the perspective of a programmer?
1. A deep understanding of the needs, clear the motivation and reasons for the needs
Our programmers must be asking why the product manager wants to dynamically realize the color of the APP when it starts according to the color of the phone case. Since you want to hear the analysis, don't rush to say your own conclusions-it is not technically possible! Since there is a doubt, then first solve your own doubt.
2. Empathy
The product has a product perspective. What do we pursue as programmers? The logic is correct, faster and easier to expand. What does the product pursue? To be honest, I haven't thought deeply about this problem myself. Thinking from the perspective of inertia, one can think of: why a product exists, what problems its existence can solve, and whether its user experience is good. These are the core values that determine a product. After all, the nature of work affects a person's thinking logic, so at this time, it is especially important for us to think about every need from the perspective of a product.
3. Don't miss every detail
As a programmer, I must deeply agree with this sentence. Because of a punctuation or type error, it will lead to an unexpected bug. When designing a product, the product manager always thinks about the problem from the general direction. The general direction is not wrong, and the details cannot be separated from the general direction. This is what they think. But for the program, it is absolutely impossible. Because a detailed logic often determines the overall direction. For example: there is a demand, the user's work needs to be submitted for review, and then it can be seen by everyone. When the product manager gave you this demand, can you detect any problems? There are several details here: 1. After the user submits for review, the user can no longer edit the work; 2. Whether the work will be reviewed multiple times; 3. Need to record the review history; 4. Whether the user's work needs version control , If you want to generate a version, how did the version come about; 5. After the review is passed, the user can modify the work again, if not, then is the user’s work invisible to others... Just a simple logical requirement! But there are too many details involved. We often can't write down when coding, because the requirements given are too vague and not detailed enough.
4. Say "cannot be achieved" in another way
It can't be realized, we must say this sentence often. But speaking directly to the product manager, it might drive the product manager crazy. Because we will make them feel that any demand they put forward cannot be realized by us. But this is not the case, because it is conditional that it cannot be realized, such as insufficient time. Therefore, we must first agree with the product manager's point of view ("achievable"), and then propose the conditions for achieving his needs. Because the reality is that product managers don’t often go stupid and often put forward some unreasonable requirements, but in the face of requirements, we need to evaluate the implementation time, and this time is not so easy to evaluate accurately.
5. When encountering unreasonable needs, actively seek alternatives
Take the needs in the paragraph, let us provide several APP skins for users to choose, which is definitely easier to achieve than the original needs, and it is more humane. To tell another story, there is a smart home company that wants to implement a kitchen faucet. According to the human voice, the water temperature can reach several degrees. Think about it from another angle, would you feel the temperature difference between 40 degrees and 45 degrees? And based on the human voice judgment, this involves a voice recognition system. How many languages do you want to be compatible with? In fact, I think the left and right switching is quite smart, there is no need to make it so complicated. So programmers need to find a better and easier way to implement. Don't give the product manager a mere assumption.
6. Must follow the spirit of the document
When developing, we often have detailed discussions with the product manager. However, we did not record the results of this discussion in the product prototype or the requirements list. But after a few months, we ourselves tend to forget why we discussed such a detail in the first place. So all needs must be based. On the other hand, it also protects the interests of both parties. Don’t wait until something goes wrong and don’t know who is responsible. In this regard, programmers often suffer.
6. Have an artistic heart for your own procedures
Someone once said that when requirements affect code scalability, the requirements will be cut first, not the code! To a certain extent, I agree with this sentence. In my opinion, a program is an ideological work. To reach the realm of art, it must be reasonable in terms of function, experience and logic. Just like a piece of art, it looks natural! Because a work that looks "ugly" must not conform to human logic and habits.
At the end of the writing, I feel that I am back to the programmer. In fact, when communicating with product managers, the most important thing is to understand: we are solving problems, not creating problems! Mainly holding this core, all problems can be solved easily
Generally speaking, there is not so much trouble communicating with the background. After you have agreed on the rules, generally speaking, you communicate through the api, but when you debug the interface, there are some unknowns, and you feel that it is not your own problem, in a timely manner The communication backstage is the most sensible.
Division of responsibilities
I believe everyone is deeply touched on this point, because the front-end is the last level, and all the needs are turned into a specific product in the front-end hands, which will also cause you to easily become a back pot, leading to the project There are many cases of postponement. The design drawings are not timely, the background data has problems, and the product needs to be temporarily changed. If you can't prove that these problems have caused the project to be postponed, you will undoubtedly remember this pot. The only way is-verbal confirmation- -àSend an email to the person in charge for confirmation--àNotify the superior, don't think this is troublesome, when something goes wrong, it will be more troublesome than this,
I can't write it. 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 work. The writing is more verbal. If you don't like it, don't spray. Finally, I wish everyone 2018 promotion and salary increase, find a girlfriend!!!
Scan the code to view the front-end interview questions