Yang Yonglin, Chief Architect of LinkedIn: My 8 Years of Architect Growth

  javascript

Yang Yonglin, known as “leader”, has eight years of experience in front-end development. He was formerly a front-end technical expert of Sina Weibo and is currently the front-end chief architect of LinkedIn. Long-term research on Web access performance optimization and front-end framework building.
As an initial team member, the leader participated in the development of all PC versions of Sina Weibo, of which versions 4-6 designed the front-end architecture of the PC version of Weibo as an architect. During his tenure on Sina Weibo, the leader designed and implemented pipelined loading technology and modular code organization, achieving the goal of greatly reducing development costs while improving access performance. The main research direction is Web access performance optimization and framework organization. The BigPipe technology has been implemented in a few countries, greatly improving the access speed of microblogs. At the same time, the front-end code base package, front-end framework and building tools of microblog are all created by leaders.
At the end of 2015, the leader joined LinkedIn and was responsible for the overall structure of the front end.
How did the leader become a well-known front-end architect step by step during his 8-year front-end development career? Why did you choose to join LinkedIn?

You are a front-end architect on Weibo and Linker. Can you tell me what is the specific job of front-end architect?

Yang Yonglin: My understanding of the responsibilities of architects is gradually changing and deepening.

At the beginning of my work, I felt that architects are people who write code quickly and well, and are the advanced versions of engineers.

After several years of work, I found that it was not enough to improve my development efficiency alone. The team needed to improve as a whole. After discovering this, I began to make and perfect various development tools and write development frameworks.

In recent years, with the iterative development of some product books, I have found that the framework tools that can improve efficiency before may become a stumbling block to product development later. At this time, I began to consider the guiding principles of architecture design, and began to consider trade-offs. Some things that can improve efficiency in a short period of time but do not conform to the principles, I will choose not to do or find ways to improve under the guidance of the principles. For example, I believe that changeable code is the living code, and I also tend to let the code of the project evolve bit by bit in architecture design, instead of refactoring to the state without a word. Therefore, I think the front-end architect is the kind of person who puts forward the guiding principles of development in the front-end field and designs the development framework and tools under the principles so that more developers can work together.

When you designed the front-end architecture on Sina Weibo, could you introduce what components are included and what key technologies are there?

Yang Yonglin: Mainly code base package, page loading framework and front-end building tools.

Two major problems faced by early front-end development are browser compatibility and insufficient API, and basic packages are generally used to solve these two problems. At that time, Sina had its own Sina package, but the code was scattered and the model was not uniform. Each product line had its own expansion. The same function could be implemented in many ways and was not easy to maintain. Later, I developed a basic package with namespace management function in my spare time, which is characterized by simplicity, clarity and ease of use. It has been adopted by the team as the basic package of microblog and has been used so far.

The page loading framework was forced by demand. In 2010, the microblog business expanded and the content displayed on the page became more and more, which made the response speed of the page slower and slower. My team has received a request to respond faster when there is more content.

At this time, Facebook launched BigPipe technology. We thought this idea could solve the problem we were dealing with, so we decided to implement it. However, Facebook only shared their practices at that time and did not provide implementation, so it was also a huge challenge for me. At that time, I divided the page into several independent sub-modules. Modules can run independently and modules can be nested, so the page is a tree stack of modules. The server transmits the module information to the page in the form of JavaScript code blocks in the manner of Chunked, and the very important work to be done by the front end is to manage the life cycle of each module.

I am very honored to have the opportunity to develop this loading framework with team members at that time. We may be the first in China to fully use this technology in large-scale Internet applications. In the following year, I have been committed to the optimization of this technology, such as supporting out-of-order output of the server, ensuring that the server can use parallel strategies, compression, reducing pre-dependency conditions, etc. In 2013, I implemented CBigPipe (parallel BigPipe) technology in cooperation with @Laruence, further improving the performance of this technology. The V5 version of microblog also reached its peak in loading performance, with the page loading speed almost equivalent to that of static web pages.

Front-end building tools have only become popular in recent years. In fact, as early as 2008, Sina already used front-end small files for development, testing and online using building tools. Now think about it should be more advanced, but at that time the version needed PHP, Python and Java environment, the team is more difficult to maintain, and the string replacement scheme is used, the function is limited. In 2012, I revamped this tool so that it only needs Node environment and supports development, test deployment and packaging online. Due to UglifyJS and syntax tree, I added some functions that I didn’t have before, such as precompiled template engine, support for template nesting and parent templates, code health detection, redundant module analysis, etc.

Before and after the front-end building tools are Grunt/Gulp, Webpack, npm scripts, etc. What do you think of these tools and which is better? How to choose the right tools for the company’s products? What should we consider?

Yang Yonglin: I think these tools have effectively solved the problem of front-end development efficiency. Their appearance is a promotion of technology. If these projects appear when I make tools, it will reduce my workload. As for which is better, I think, you can master which is the best. Because in the end, the tool serves your business, and you may need to make some modifications or write some extensions to it. At this time, you find that your familiarity with it becomes very important. The migration cost of the building tool is still quite high. I don’t recommend changing it frequently, so it is better not to follow the trend, but to choose a suitable one according to the characteristics of your team. If it is not a super-large application, in fact, the impact of the build result is not very different. instead of thinking about which is better and which is better, it is better to play through one of them.

How to ensure team members will not step on the same pit? Are there any considerations in designing frameworks and building tools? Please give an example.

Yang Yonglin: First of all, it is inevitable to formulate norms and share experiences, but the paper will be shallow at last. Most of the time, one step in the pit will give one profound experience. What I have to do is to reduce the consequences when the team members step on the pit. For example, the development environment I provided can completely simulate the online environment, the test code is consistent with the online environment, and many unexpected situations can be found during the development and testing period. At the same time, the developed development specifications should be ensured by tool testing, and codes that do not conform to the specifications cannot be packaged and put on line. For standard codes, tools can be used to calculate the business impact range, which can effectively ensure the test coverage. In general, it doesn’t matter if you step on the pit, the structure will help you get to the bottom, and the process of climbing out of the pit will become the wealth gained by the team members.

What do you think should be paid attention to in optimizing the performance of Web access? Among them, what is the most noteworthy point? Why?

Yang Yonglin: I think performance optimization needs to take into account all aspects, including network time, server computing time, page requests, download volume, page loading model, etc. The performance improvement of any one of these items may require you to modify a lot of code or adjust the architecture, but the result may be a little bit. Therefore, silver bullets are rarely seen and are usually made bit by bit. I’d like to talk about two points that I think deserve more attention but are easily overlooked.

One is the form of the products you serve and what users care about, which some engineers can easily ignore. Some products require users to open them quickly, while others require users to use them smoothly. Some product users can tolerate reading old data, while others must be new content. Some product users turn it on many times a day, while others turn it off after watching it once. The difference in demand for these products will affect your decision.

The second is the evaluation standard, which is used to measure the performance. Some people think that when the number of requests or requests decreases, the visit will be faster. In fact, this is not necessarily the case. It is possible that what you have spent a lot of energy on has not changed much in the eyes of users. Therefore, it is very important to find an evaluation standard so that each optimization can be reflected in the data.

What are the metrics to measure front-end performance? How to Monitor Web Access Performance?

Yang Yonglin: The products I serve generally focus on access performance, that is, how fast users see content, so we usually use the first screen time to evaluate, and the general performance testing service providers can provide this indicator.

There are two considerations in choosing this indicator: first, it is not a technical indicator, but a perception indicator, so it is closer to human feelings. The second is bypass detection, which is not in the system and is not the data reported by the system, thus effectively avoiding the problem of deviation of survivors. Of course, it also has some shortcomings: first, the data sample is small, second, it can be cheated. Therefore, it may require a little knowledge of statistics and a correct understanding of performance monitoring.

In the process of monitoring, first, we should pay attention to the changes of long-term trends. If it is not an emergency situation, the absolute value of single-point data is meaningless. We should collect long-term data and analyze the changes. When there are changes, we should pay special attention to the changes of data. The second is to pay attention to the worst 25% situation. Some people will brush their products on the company’s intranet and feel very fast. In fact, no matter what means you use, as long as the internet is fast, the user experience will not be too bad. The difference in experience lies in the worst part of the users. The third is to analyze data from different dimensions, such as region, network, time period, operating environment, etc.

How do front-end engineers become front-end architects, besides their programming skills and architectural knowledge, what other abilities do they need to develop?

Yang Yonglin: I think the work of architects in most fields is the same, that is, to set up a framework to solve problems so that team members can work well together under the framework to fulfill the product development requirements.

We know that there are many ways to solve a problem, and it is very important to choose between them in this process. We also know that without silver bullets, it is rare to find a solution with comprehensive advantages. Most of the solutions sacrifice some things in exchange for some things. Therefore, as an architect, one should not only be familiar with the characteristics and costs of each technical scheme (i.e. programming ability and architectural knowledge), but also learn how to choose. Obviously, the architect needs to make a decision according to the characteristics and development direction of the product, and the architecture in the front-end field should enable the cooperating teams to interface smoothly. So in this process, good communication skills, empathy and altruistic thinking are very important. Because we not only need to complete the development task, but also need to think about how to help the project solve the problem in our own field.

It is said that some colleagues are proud of “beating” you in the discussion of technology. What do you think? What impact does this have on the development of the team and its individuals?

Yang Yonglin: This is my fault. I like to criticize other people’s plans. I think this is a speculative process. Only by analyzing the problem from different angles and challenging the rationality of the solution can the problem be solved more safely. The same is true in the acquisition of knowledge. Only by asking why and tracing to the source can the knowledge system be strengthened.

I like playing a “villain” role in the team, analyzing problems from a negative perspective and challenging other people’s plans. In fact, I don’t really deny him, but I hope his plan is produced after repeated deliberation and careful consideration. Such a plan will be more robust. After a long time, they will think I am a wrangler and will be ready to “challenge” me. They will feel very happy to be able to take me beyond words. This result is what I want to see, because it shows that the team members have done enough thinking in solving the problem.

Why did you give up your veteran status on Sina Weibo and choose to join LinkedIn?

Yang Yonglin: This may come from my view of work. I think people live in society and work is to create value and wealth for the society. It has no direct relation with what kind of occupation he is engaged in. At present, there is a general mood in the industry, that is, it is good for programmers to write good code and do not care about what they do. Even the society gives programmers some labels such as “wooden” and “low EQ”. I don’t think it should be like this. Programmers are also social people. They also have their social responsibilities and family responsibilities. They also need to accompany their partners and take care of their children. They don’t just face the code every day and ignore other things. People should not restrict themselves because of group impression. People’s life should be varied, rich and varied. Life should be meaningful.

Personally, in the past few years, the products I serve have not only deepened the communication and understanding between people, but also made the information of the country more transparent. The work I have done has contributed to such a product. It can be said that my work has made the world a little better. This makes me feel that my life has added a little meaning. And when I set up the front-end framework, the role I can play becomes smaller and smaller, and the value I can continue to create becomes smaller and smaller, so I need another platform to continue to use my energy.

At this time, I had the opportunity to get in touch with LinkedIn. This company is committed to solving people’s living problems. It makes China’s largest market transparent and orderly. I think what LinkedIn has done is very meaningful. At the same time, in less than two years, it has assembled a group of cattle in various fields, maintained the largest real estate trading system in China, and made the purchase and sale of houses easier, more transparent and faster by technical means. In my contact with LinkedIn, I felt the energy of actively solving problems and the pragmatic attitude of doing things. In addition, most of the technicians in LinkedIn were the backbone of large Internet companies before. I think there is nothing more exciting than changing the world with like-minded people. At this time, Brother Bird specially invited me to join Linkist. I agreed without hesitation.

Hierarchies Answer Group Friends’ Questions:
Q: Do you have any good suggestions for junior front-end personnel?
A: Try more solutions, think more about the characteristics of these solutions, and explore the principles of others’ solutions.
Q: Are there any books on front-end learning that can be introduced?
A: There are quite a lot of front-end books now. I generally recommend advanced programming, illustrating CSS3.
Q: What is the most serious online incident you encountered in your role as an architect? How was it solved at that time?
A: After working for so many years, there should be only one Class B failure at the front end, but when it is not the front end, it goes through a big mess, because the online speed is relatively fast and the big problems are obvious solutions, so it goes online quickly. This is thanks to the testing students, which is very helpful and avoids many online faults.
Q: Is it more effective to attend business training before studying? Or is this kind of business training more rigid in thinking? How well are the trainees trained in this assembly line recognized in the enterprise?
A: I haven’t seen business training and I’m not very good at it. I think the knowledge I’ve been taught may not be as solid as the knowledge I’ve got lying down in the pit. Enterprises recognize this aspect, I basically only look at ability.
Q: Is technology more important to you or is the product more important? Because you said just now that you considered the “product” of Linkist because you thought it was more meaningful. Does that mean that you think the product is more important than the technology?
A: The product I am talking about is not “product personnel”, but the service of the company’s output. Obviously, for a company, products are the most important, and technology is the means to realize products.
Q: What kind of code do you think is changeable? What practices have been made in this regard? What are the systematic outputs?
A: I said that the changed code is actually controllable and can be used to adjust the project conveniently. I can rebuild the project step by step instead of refactoring. I follow this idea in my development.
Q: I mentioned earlier the framework available to the team, but I felt that the workload was huge and needed a lot of improvement and testing. Did the leader feel the same way at that time? How to solve the problem of such a heavy workload?
A: I may be lucky. I have adjusted the structure for a period of time. I think so. Every time I take a step forward, I am making progress. Therefore, I am not in a hurry to put the structure in place once. I will think about the steps of adjustment. Each step will make the structure progress and break down big problems into small ones step by step.
Q: The lack of project management experience in the front-end development of small companies has led to a lot of redundant work. What is the leader’s suggestion on management?
A: The situation in this different company is different, isn’t it? It’s not very good advice.
Q: Is it contradictory to try more solutions and “improve products step by step”?
A: It’s not contradictory. Trying more doesn’t mean implementing more.