How to become an excellent front-end engineer?

Recently saw a chicken soup article "How to become a great front-end Engineer" (Original address http://blog.mcbird.cn/2015/08/15/ how-to-become-a-great-front-end-engineer/), is a front-end engineer from Google-philip Walton share their own views on how to become a good engineer, after reading very touched, Each of the points of view can bring some profound understanding, and I opened a blog in the blog and began to write blog is inspired by this article, hope that through the blog to record their own learning, thinking and some sentiment, I hope that the front-end engineers can go farther on the road. Next I'll talk about each of the ideas in the article "How to become a great front-end Engineer", and record it to make yourself feel confused in the future, and you can come here and look for directions.

Don ' t just solve problems, figure out what's really going on.

My interpretation of this sentence is: not only to solve the problem, but also to find out the root of the problem. In the programming process, we always encounter a variety of problems, we do not because of luck to solve the problem and complacent, and we have to do is to go deep into the problem, to find the root cause of the problem, always keep in doubt, think about how many ways to solve the problem, and finally choose an optimal solution. For example, when we developed in the front-end, why sometimes the same code in the IE6 browser and other standard browser performance is not the same, through Google, we found that the problem is IE6 to some of the styles are incompatible, and then we may in the CSS code, through the hack notation IE6 write a single style , and then reopen the IE6 browser to see, the problem is solved, but is this the best way to solve it? We can not be satisfied with the problem, but also in-depth study of it, through access to information to find new solutions, and finally choose a better solution.

learn to anticipate changes to the browser landscape

learn to predict future changes in the browser domain. The original author gave an example, as early as 2011, in a very well-known JavaScript framework to see the following section of the source code (in general):

var isIE6 =!isie7 &&!isie8 &&!isie9;

We now see that this line of code we can not judge the user to visit the page browser is not IE6, but in fact, this line of code is used to determine whether the browser is IE6, yes, before IE10 out, this line of code is correct, but Microsoft will continue to upgrade the IE viewer, such as the later launch of the IE10, IE11 Browser, now this line of code is going to expire, to think this line of code is not a problem, you must change the code to:

isIE6 =!isie7 &&!isie8 &&!isie9 &&!isie10 &&!isie11;

So when we write code, we also have to consider the evolution of the browser, write maintainability of the code, you have to learn to predict the future changes may occur, even if the future, your code will still be able to work properly.

Read the Specs

Read the official documentation. We all know that official documents are the most authoritative, most of the programming guides that we Chinese see are written according to official documents, but some translators have different abilities, so the books that are written in the end do not inspire the reader better, and may cause some misunderstanding of the understanding of some norms. The examples given by the authors are cross-browser compatibility issues and are not introduced here. What we need to do is to improve our English as much as possible, and then consult as many official documents as possible. Sometimes what people think is right is not necessarily in line with the Official document interpretation.

Read Other people ' s code

Read someone else's code. This is undoubtedly a very good way of learning, in the front-end development process, we often encounter the code is not working properly, maybe you have already solved the same problem before, and then you use the method used before to solve the problem, it is no good for your progress, you have to do is to Google this problem, Look at how others solve the problem, read the code that someone else has written, get some inspiration from it, and improve your programming skills. And in real life, we are in other people wrote the existing code based on the work, the Code of others to modify, add. So the habit and ability to read other people's code is necessary in the course of personal growth.

Work with people smarter than

Work with someone smarter than you. In China there is a proverb "Jinzhuzhechi, howl", probably has this meaning, as the front-end engineers, their knowledge system is mostly done by self-study, in the process of self-study often lack of communication with others, so write out the code is usually worse, and there is no code to write better than the guidance of the person, So for a long time you also feel that there will not be much progress. However, working with people who are more experienced than you are, you can grow better because others will spit out your bad code, make you ashamed, and then burn and fight, and of course you should understand that I'm joking, and I want to say that you work with someone smarter than you, at least someone will review your code, And then give you constructive advice to write more excellent code.

Reinvent the wheel

Re-build the wheel. This does not mean that you are not allowed to use other excellent libraries (such as jquery) to improve your development efficiency while you are programming, but you want to be a good front-end development engineer, you should be the maintainer (developer) of these excellent libraries, not just use them. Simply using those good libraries doesn't make you understand the core of the problem. Only try to write some of your own library, and constantly maintain, optimize the code so that you can learn more, why not try it?

Write About Learn

Write down what you have learned. This is important, and this is one of the reasons why I wrote this blog.

Although it is not well written, and written down is not necessarily someone to see, but this is the best way to record their growth process. Keep a record of what you've learned or don't understand, and the knowledge that you might think you already understand, but when you write it down on a blog, you find that the facts are not well mastered.

So sticking with blogging may force you to better understand what you've learned.

How to become an excellent front-end engineer?