Front-end learning and re-learning, learning and learning

Front-end learning and re-learning, learning and learning

This article is translated from a blog by Google Engineer Philip Walton. After reading this article, I was very touched. Many of my views have been very persistent and recognized for a long time. Therefore, I have translated this article and shared it with more front-end students!


Recently, I have received a letter from a reader, which puts me into thinking:


Hi Philip, do you mind if I ask, how do you become a great front-end engineer? Do you have any suggestions for this?
I have to admit that I was surprised to be asked such a question, because I never felt that I was a very good front-end engineer. Even in the first few years, I didn't think I could do this well. I'm sure I'm not more knowledgeable than I think, and I don't know where to ask when I'm interviewing.
Http://www.cnblogs.com/roucheng/p/csslogin.html

Even so, I have done a good job and become a valuable member of the team. But when I finally leave (to seek new challenges-I am not competent yet), I am often asked to recruit my successor. Looking back at these interviews, I can't help but lament how scarce I was at the beginning. I may not be hiring based on my own model now, even my personal experience may be successful.


The longer I work in the web field, the more I realize that it is not their knowledge to distinguish between talent and top talent-but their way of thinking. Obviously, knowledge is very important and critical in many cases-but in a fast-growing field, the way you move forward and acquire knowledge (at least for a long time) it is more important than what you have mastered. More importantly, how do you use this knowledge to solve daily problems.


There are many articles about the languages, frameworks, and tools you need in your work. I hope to give some different suggestions. In this article, I want to talk about the mentality of a front-end engineer, hoping to help you find the path to excellence.


Don't just solve the problem and think about what happened.


Many people write CSS and JavaScript until the program starts to work and then do other things. I found this happen frequently through code review.


I will always ask you: "Why do you add float: left here ?" Or "is overflow: Den den necessary ?", They often replied, "I don't know, but when I delete them, the page will be messy ."


The same is true for JavaScript. I always see a setTimeout in a competitive place, or some people accidentally stop the event propagation, but do not know that it will affect the processing of other events on the page.


I found that in many cases, when you encounter problems, you just solve the current problems. However, if you never take the time to understand the source of the problem, you will face the same problem again and again.


It seems time and effort-consuming to figure out why, but I promise it will save you time in the future. After you fully understand the entire system, you do not need to guess and argue.


Learn future browser development trends


One major difference between front-end and back-end development is that the back-end code usually runs in an environment under your control. The front-end is relatively less under your control. Platforms or devices of different users are the eternal topic of the front-end, and your code needs to be elegantly controlled.


I remember seeing the following code (simplified) when I read a mainstream JavaScript framework before 2011 ):


Var isIE6 =! IsIE7 &&! IsIE8 &&! IsIE9;


In this example, the variable IE6 is used to determine whether the IE browser version is 6 or earlier. So when IE10 was released, our program determined that there would still be a problem.


I understand that feature detection does not work 100% in the real world, and sometimes you have to rely on bug features or incorrect design whitelist Based on browser feature detection. But everything you do for this is critical, because you foresee a future where no bugs exist.


For many of us, the code we write today is longer than our work cycle. Some of the code I have written has been running online for more than eight years. This is satisfying and disturbing.


Read standard documents


It is inevitable that there are bugs in browsers. However, when the rendering effect of the same Code in two browsers is different, people will always think about it without thinking about it, the "widely acclaimed" browser is right, and the "inconspicuous" browser is wrong. But this is not the case. When your assumptions are incorrect, the alternatives you choose will encounter problems in the future.


An example of proximity is the default minimum size of flex elements. According to the standard description, the min-width and min-height values initialized by the flex element are auto (instead of 0), which means they should be reduced to the minimum size of their content by default. However, in the past eight months, only the implementation of Firefox is accurate. [1]


If you encounter this browser compatibility problem and find that Chrome, IE, Opera, and Safari have the same effect and Firefox is different from them, you may think that Firefox is wrong. As a matter of fact, I see more about this situation. Many of the problems I reported in my Flexbugs project are the same. And the problems with these solutions will be reflected two weeks later After Chrome 44 is fixed. Compared with standard solutions, these solutions hurt the correct normative behavior. [2]


When the rendering results of the same Code in two or more browsers are different, you should take some time to determine which effect is correct and write the code as standard. Your solution should be friendly to the future.


Additionally, the so-called "excellent" front-end engineer is always aware of changes and adapts to a technology before it becomes mainstream, even contributing to such a technology. If you train yourself to see how a standard works before the browser supports it, then you will become the group that talks about and influences its standard development.


Read others' code

Http://www.cnblogs.com/roucheng/p/5404594.html
Reading other people's code out of fun may not be the entertainment project you think of every Saturday evening, but it is undoubtedly the best way to become a good engineer.


Solving problems independently is definitely a good method, but this is not your only method, because it will soon make you stable at a certain level. Reading other people's code will open your mind, and reading and understanding the code written by others is also a must for teamwork or open source contributions.


I think the biggest mistake many companies make when recruiting new employees is that they only evaluate the candidate's ability to write new code starting from the outline. I have almost never seen an interview asking the applicant to read the existing code, locate the problem, and fix it. The lack of such an interview process is really bad, because you have spent a lot of time as an engineer adding or changing the door-to-door on the basis of the existing code, rather than building new things.


Work with people smarter than you


Many front-end developers (compared to full-time working) Are Freelancers, and there are not so many backend developers with similar ideas. It may be because many front-ends are self-taught, while the back-ends are mostly learned by schools.


Whether it's self-learning or self-work, we all face a problem: You have no chance to learn anything from a guy smarter than you. No one will help you review the code, and no one will share your inspiration with you.


I strongly recommend that you work in a team at least in the early stages of your career development, especially in a team that is generally smarter and experienced than you.


If you choose to work independently at a certain stage of your career development, you must devote yourself to the open-source community. Maintain an active contribution to open-source projects, which will give your team the same or even more benefits.


Create wheels"


Making a wheel is very bad in business, but it is very good from the perspective of learning. You may want to use those libraries and gadgets directly from npm, but you can also imagine how much you can learn to build them independently.


I know that some people do not approve of this. Don't get me wrong. I didn't say you shouldn't use third-party code. The well-tested libraries have years of experience in test cases and known issues. It is wise to use them.


But here I want to talk about how to go from excellence to excellence. I think many excellent people in this field are the authors or maintainers of the very popular libraries I use every day.


You may have never created your own JavaScript library or a successful career development, but it is almost impossible for you to get gold from your hands.


A common question in this line is: What should I do next? If you didn't try to learn a new tool to create a new application, try to create a new JavaScript library or CSS framework that you like. The good news is that when you encounter difficulties, the source code of all ready-made libraries will help you.


Record everything you learned


Last but not least, you should record what you learned. There are many reasons for doing so, but perhaps the most important reason is that it forces you to better understand it. If you cannot clarify how it works, it will push you to figure out what you don't really understand. In many cases, you do not realize that you do not understand them until you write them yourself.


Based on my experience, writing, speaking, and demo are the best way to force myself to fully understand one thing. Even if you write nothing, the whole process will benefit you a lot.

Effects: http://www.cnblogs.com/roucheng/p/texiao.html