May 31, 2021 Article blog
The article comes from the public number: The front end is really fun Author: Your brother
From time to time, a small partner asked me this question, said the front end needs to learn too much knowledge, and then gave me a lot of technology stack: what three frameworks, all kinds of family buckets, small programs, umi, flutter, SSR, Node and so on, anyway, the front-end technology stack listed again
There's a lot on the front end, but there's no need to learn anything. O nce you have this idea, you'll most likely fly like a headless fly. Look at this, that learning point, in the end nothing was learned well.
Such an example in fact I see a lot more in the reader, learning really seems to be learning, what materials are collected, today to see the video of this technology, tomorrow to take another technology book to read, but this way of learning is quite inefficient, and what information collection will also create a time is completely inadequate illusion. I f you don't have a goal plan for learning, you can do more (perhaps not even half). Because programming this part of the thing is relying on a lot of coding, if you learn this tomorrow to see that, there is not a lot of practice let you train yourself to the end is nothing to learn.
Know what you want to learn must be done before, otherwise it is headless flies around.
If you really don't have any ideas, here are three things I recommend:
In fact, I personally feel that there is no absolute answer to this question, both of which are beneficial.
Digging depth helps you become an expert in the field, and although the vast majority of people don't have this opportunity, we can certainly do it more than some people do, so digging depth can ultimately help you become less likely to be eliminated in the industry.
Digging for breadth can help you touch bypass, learn more about concepts, and more, and the more you learn about the human body, the faster you feel. Of course, the breadth of this excavation is not the kind of thing said earlier to learn the practice, but in learning a direction when the associated content is also learned a little.
For example, if you're going to start learning Redux's State Management Library today, you might consider learning by the way what its competitors compare to Redux's strengths and weaknesses, and so on. What needs to be noted here is that instead of letting you learn all about it, you understand the advantages and drawbacks of the competition (which is the breadth), and the depth of the dig is to learn Redux well until you can build the same wheel (which is the depth of the dig to the very back).
Building a knowledge system is important, otherwise it's easy to forget that whatever you've learned is a separate piece of knowledge, and if there's no connection to anything else.
You should have seen the front-end knowledge brain map on the Internet before this kind of thing, this is actually even a sub-point (because this is only a sub-area division, there is no connection with more sub-areas) knowledge system, of course, can master it first is also great.
A better way is for what you have learned to be as connected to other knowledge as possible, and the better it is to connect with the more knowledge you have.
For example, today the interviewer asked you a theoretical knowledge, this time if you can first speak theoretical knowledge, but also to speak of relevant theoretical knowledge, and finally use examples in the work to describe this knowledge, this is even a good knowledge system practice. You connect this theoretical knowledge with other theoretical knowledge, and you associate it with examples in action.
So how do we build our own knowledge system? The method is simple:
Many of the technical stacks listed at the beginning of the article, such as flutter, SSR, umi, are not familiar to many authors, but I don't always think about when I'm going to learn them.
Because people's energy is certainly limited, for the work of the approximate rate of things I have always been the strategy is to understand this technology stack, read its Readme, know what problems it solves on the line, in addition to this will not continue to learn, only when I really need these technology stack when I will learn them.
This strategy I also recommend you can use, because there is really no need to go ahead a lot to learn a do not know when to use the technology. The author has also said that programming is required a lot of practice, no practice after a period of time may be a little forgotten (anyway, the author will be like this), and then after a while this technology may update the iteration of the larger version, then you learn things may not be used to have to release, have that time to play the game is not good
the total feeling that they will not be a lot, and do not know where to start, senior front end to take you to break the
relevant introduction, I hope to help you.