I am here web The longer you work in the field , The more I realized that it's not their knowledge that distinguishes talent from top talent —— It's the way they think about things .
Obviously , Knowledge is very important and critical in many cases —— But in a fast-growing field , The way you move forward and acquire knowledge ( For a long time at least ) It will be more important than what you already know . what's more ： How do you use this knowledge to solve everyday problems .
I want to give some different advice . In this article , I want to talk about the mentality of a front-end Engineer , Hope to help you find your way to excellence .
Don't just solve the problem , Think about what happened
I passed code review Find out that this happens all the time . I always ask you ：“ Why do you add float: left？” perhaps “ there overflow: hidden Is it necessary ？”, They often say ：“ I don't know either , But as soon as I delete them , The page is out of order .”
I find that in many cases , When you have problems , You're just solving the problem right now . But if you never take the time to understand the root cause of the problem , You will face the same problem again and again . Take some time to find out why , It looks like a lot of time and effort , But I promise it will save you time in the future .
After fully understanding the whole system , You don't have to guess and argue all the time .
Learn to foresee the future trend of browser development
One of the main differences between front-end and back-end development is that the back-end code usually runs in an environment that is completely under your control . The front end is relatively less in your control .
Platforms or devices of different users are the eternal topic of the front end , Your code needs to be elegant in controlling all this .
I understand that in the real world, feature checking is not 100% Work , And sometimes you have to rely on having bug Or design whitelists based on browser features . But everything you do is critical , Because you foresee no more bug The future of .
For many of us , The code we write today will be longer than our work cycle . Some of the code I wrote is in the past 8 More than years, still running on the product line . It's very satisfying and disturbing .
Read the specification document
Browser has bug It's inevitable , But when the same code is rendered in two browsers, the effect is not the same , People always speculate without thinking , that “ Widely praised ” Your browser is right , and “ not eye-catching ” The browser is wrong .
But that's not necessarily the case , When your hypothesis goes wrong , The workarounds you choose will encounter problems in the future .
A recent example is flex The default minimum size of the element . According to the specification ,flex Element initialized min-width and min-height The value of is auto ( instead of 0), That is to say, by default, they should shrink to the smallest size of their content . But in the past, as long as 8 In months , Only Firefox The implementation of is accurate .
If you run into this browser compatibility problem and find Chrome、IE、Opera、Safari The effect is the same, and Firefox Different from them , You'd probably think it was Firefox A mistake .
In fact, I've seen a lot of this . A lot of me on my own Flexbugs The problems reported by the project are like this . And the problem with these solutions will be in two weeks Chrome 44 After repair, it is reflected .
Compared to a standard compliant solution , All of these programs hurt the right normative behavior .
When the same code is rendered differently in two or more browsers , You should take some time to determine which effect is right , And write code according to this standard .
Your solution should be future friendly . additional , So-called “ Excellent ” The front-end engineers are always feeling the change , Adapt to a technology before it becomes mainstream , Even contributing to this kind of Technology .
If you train yourself to see the specification, you can imagine how it works before the browser supports it , So you're going to be the group that talks about and influences its specification development .
Read other people's code
Reading other people's code for fun may not be the entertainment you think of every Saturday night , But it's undoubtedly the best way for you to be a good engineer .
It's definitely a good way to solve problems on your own , But it shouldn't be the only way for you , Because it will soon stabilize you at a certain level .
Reading other people's code will open your mind , And reading and understanding code written by others is also a must for teamwork or open source contribution .
I really think the biggest mistake many companies make when recruiting new employees is that they only evaluate candidates' ability to write new code from the outline . I've rarely seen an interview where candidates are asked to read existing code , Find out the problem , And fix them .
The lack of such an interview process is really bad , Because a lot of your time as an engineer is spent adding or changing existing code , Instead of building something new .
Working with people smarter than you
Many of the front-end developers I remember ( Compared to a full-time job ) They're all freelancers , There are not so many back-end developers with similar ideas .
Maybe it's because many of the front-end are self-taught, while the back-end is mostly learned from school . Whether it's self-study or self work , We all face a problem ： You don't have a chance to learn anything from someone smarter than you . There's no one to help you review Code , No one collides with you for inspiration .
I strongly recommend , At least in the early stages of your career development , You have to work in a team , Especially in a team that is generally smarter and more experienced than you are .
If you eventually choose to work independently at some stage of your career development , Be sure to engage yourself in the open source community . Keep active contributions to open source projects , This will give your team the same or even more benefits .
“ To build the wheels ”
Making wheels is very bad in business , But it's very good from a learning point of view .
You may want to take those libraries and gadgets directly from npm Take it down and use it , But imagine how much you can learn by building them on your own . I know some people who read this are particularly against it . Don't get me wrong , I'm not saying you shouldn't use third-party code . Those well tested libraries have years of test case accumulation and known problem accumulation , It's a very wise choice to use them . But here I want to talk about how to go from excellence to excellence .
The good news is that , When you are in trouble , The source code of all ready-made libraries will help you .
Make a note of what you've learned
There are many reasons for this , But perhaps the most important reason is that it forces you to understand it better .
If you can't explain how it works , Throughout the process, it pushes you to figure out what you don't really understand .
In many cases, you don't realize that you don't understand them yet —— Until you write it yourself .
According to my experience , writing 、 speech 、 do demo It's the best way to force yourself to fully understand something . Even if you write something that nobody reads , The whole process will also benefit you a lot .
A digression , I always have the habit of sorting out the interview questions , Be ready to jump out of the comfort zone at any time , Before I knew it, I sorted it out 229 page , Share it here , In need Click here to get the title for free + analysis PDF