Always wanted to write this "10th talk", talk about my experience in the Web front-end development, by the way to answer the confusion around a lot of people and confused. I am not going to talk too much about technology, I think, through the experience of technology, the reflection should be more important.
I always think of myself as a "beginner" front-end development engineer, on the one hand I humanely still shallow, only a few years, on the other hand, I am aware of the technology is not in-depth, may be due to environmental reasons, of course, the most important thing is that I am fortunate to participate in the rise of the Internet The Times have created a group of weak but highly sought-after "riders", this has greatly influenced our insight into the nature of technology, and over the years has not had a system of "front-end technology" evangelism, so that most of the current understanding of the front-end technology, the cover begins with the expression of the job description is not rigorous, This is precisely the reflection of the Web front-end development of their own fuzzy positioning. For many Web front-end engineers, the first taste of forbidden fruit can not last a long time, fell into a round of confusion, thinking about their career planning, trying to find suitable for their own growth path, see their own skills bottlenecks, to find breakthroughs. Unfortunately, Web front-end technology has been widely accepted for a short time and there are few inspirational success models to follow. However, the situation is not always so bad, after all, the Web front-end technology is a "technology", and Computer science department, just because of the rapid rise of the internet has been shrouded in fog, cover the eyes, let us silly to see the situation.
So how do you define the Web front-end technical post boundaries? Web前端技术的价值体现在何处?前端工程师的价值仅仅体现在物以稀为贵吗?前端工程师的初级、中级、高级和专家之间到底如何界定?当前"我"处在什么位置?接下来的路子应当怎样走?何谓前端技术之"道"?我想多数人都思考过这些问题 , this "10th talk" in the point of view may be a bit extreme, but to give a tip, the reader can take these remarks as a primer.
Day one: first taste of forbidden fruit
God said, "Have light!" Then there is light.
All Creatures, sunshine and dew from the beginning of the creation of heavenly creations, we can not imagine God to create the world before the light. But fortunately, the front-end development is not a god-like charm. The breeding, shaping and development of this technical type of work has its own track, and it is quite easy to understand, of course. Not strictly speaking, the Web front-end technology has started to get into the public eye when Jerry Yang and Philo Yahoo! in the Stanford University room, but there was no loud name at the time. Since then, "browser-based development" has become a new branch of software development, this is also the core of Web front-end technology, that is, no matter when and where the system and what kind of device, all browser-based, is the Web front-end development category (of course, this definition is very narrow, hereinafter mentioned).
It should be said that the two types of people are complementary, they understand the nature of the browser part of a set of people to the rendering engine at hand, another person will be JS engine Shangwei, in fact, any part of the advantages of play out can make fine. Most of the front-end engineers can find their own shadow from these two sources. However, these two types of people's thinking patterns and views are so different, so that some unnecessary confrontation, such as in some companies, simply the Web front-end technology in two, "cut the page" and "Write JS." This seems to make it clear that division of labor improves efficiency, but he has a huge impact on employee career development. There will be further discussion in the second day of "The scholar of the prep".
I should belong to the second category, that is, in the school serious study C/java and C # and so on, think after graduating from university can do ERP software, desktop software or into some communications companies write TCP/IP related procedures. Campus recruitment to choose the Chinese Yahoo, because that year (08) Yahoo still has a bit of fame, and I heard that Yahoo compared technology flow of the company ... Since then on the shanghaied, an uncontrollable.
During this time of Yahoo, I had the privilege to come into contact with a awe-inspiring of technical schools, and also formed my basic view of the front-end technology, these basic views have been affecting me so far.
An elegant college pie.
Yahoo's technical schools were in the heyday of the year, with many "father" level of high man, created by the hack atmosphere is really intoxicating, that period of time I would rather work overtime to read a large amount of documents and source code, feel really very comfortable, I deeply by Yahoo engineers this low-key pragmatic, Seiko fine-cut " The service spirit "is moved, but this kind of humble excellent quality greatly affects the Yahoo product user experience and the high quality technical output. So what is the "spirit of service"? That is, what you are doing is serving people, product customers, people who take over your project, or people who use the features you develop, so technical documentation is standard for accompanying code. As a result, engineers can communicate with each other through code. This is an engineer's basic quality, that is, a clear idea of the completion of the project, and equipped with valuable technical documents, if your program is for other programmers to use, but also to do so, as you make a home appliances have to be equipped with the same instructions. As a result, Ydn became the most popular technical document library for the world's programmers at the time, and this elegant and pragmatic "college breath" makes people feel unique.
It is strange that this kind of academic school has not been seen in the Chinese community. Even in the Web front-end technology community with the advantages of congenital open source is also quiet, it can be seen that writing a good technical copy is really more difficult than heaven. Most of the so-called documents I see are simply pasting a copy of the statement block of output data from the code, as to why the data format is designed to do so, if the field has to be modified how to do it, how to encode and decode the key information, and so on, or developers have not thought about these issues. Therefore, we have been emphasizing the quality and maintainability of the code, but has not been effective, the lid stems from the lack of this "service" awareness of indoctrination. This awareness will be mentioned many times in the following paragraphs, because it can affect every detail of your work, is the most should first break out of the ideological tangle.
In addition to the problem of consciousness, the other is technical problems, that is, writing. This is the most important problem that engineers can't look at, it's unbelievable that this is the key to hinder engineers from breaking the bottleneck. I have seen countless people in the promotion of this level to eat a great loss, a lot of engineers technical strength is very strong, but is not to express, or list a lot of information without focus, or no fun to speak code details, I do not know. Unless you run into a skilled boss, otherwise there is really no way to escape the fate of the code farmers. But most people still disagree. And in the field of Web front-end development more. Front-end engineers are most like refactoring, but in the face of fast-paced needs, it is difficult to use the vague rhetoric of "improve maintainability" and "improve performance" to buy yourself time for refactoring, to be explicit, maybe you really can't quantify the real value of a refactoring, just "feel the code more neatly." Just. I will be in the following "pseudo architecture" will be launched to analyze the front-end engineers this impetuous flattering technical complex. This is one of the most lacking qualities of the front-end engineers: Use data to talk, use rigorous scientific arguments to support your point of view, the boss is not stupid, valuable things of course will let you do.
Of course, the situation is not always so bad, we see the Chinese community has exercised a lot of writers, they are using high-quality text to promote their technical ideas, this is a good omen, good writing can be tempered. In the workplace, especially for the special position of the front-end engineer, this basic skill can help you rethink the prioritization of your needs and grasp the seven-inch location from the messy needs. Because when you start to write an email carefully, this kind of thinking already includes it.
Therefore, the marketing of Yahoo Technology is relatively successful and distant broadcast. The key lies in two aspects, solid technical skills and superb writers. And the real technology Daniel must be a set of both and one, not only study the kendo, but also output cheats. This is also the power source of Yahoo! 's elegant academic atmosphere. Many technical groups in the country want to make a contribution in this regard, and should first think about this.
Specification of the broken and stand 1
Yahoo's technical operation is very normative, just mentioned, including technology, organization, culture, everything looks like a model, also called the benchmark, nature has become a lot of domestic technical team and community to emulate the object. For a time a variety of "norms" of the wind, the color of the "standard" big line, the result is uneven quality.
What kind of specifications do we need? What is the magic of Yahoo's technical specifications? What kind of ideas to build the standard is genuine? What is the life cycle of a specification? To understand these problems, can greatly reduce the ideological burden of many Web front-end engineers, to see a part of the technical nature, to avoid blindly follow suit.
We do need norms, but good norms must be pragmatic, must be "problem-solving." For example, a project-built DPL can incorporate common visual components to reduce repetitive development, and specify the event distribution principle for a OPOA project to establish code inertia for incremental development. Conversely, poor specifications are too "abstract", such as page performance metrics, responsive design principles. In addition, although his mountain stone can attack Jade, but copycat has a big premise, is you understand your project key questions, you have to prioritize the key issues, and foreign norms can just solve your problem. The specification is therefore a desk manual, a solution to the problem, and should be a "dictionary" rather than a "tutorial". The source of the visible specification is "problem". So, when you want to refactor your project with Coffeescript, when you want to introduce the COMMONJS specification, when you want to rub into the bootstrap on the page, when you're going to reinvent the wheel for a set of JS libraries, when you want to rewrite a set of assets packaging tools, Think about what these things do to solve your problem? Will it bring new problems, complicate matters, or do you want to be a delicacy? or to use and master a variety of new technologies in a resume?