Why are we talking about this topic
Front-end circle is a field called entertainment circle by people in the technical circle. Many people who do back-end and algorithms often come to ridicule the front-end circle. There is even a question on Zhihu asking “what is the front-end architecture? Even the front circle itself had plenty of self-deprecation. But in fact, over the years, as the Internet has grown, so has the front end, the needs of the front end have become more and more complex, and the front end teams have grown larger and larger. In a complex product and large team, if there is no structure, it can only be manual workshop production, which is inefficient. So, I deliberately chose such a topic, to protect the dignity of our front 🙂
What is technology architecture?
Technological architecture refers to the technological whole which is composed of various technologies in the society, interacting with each other, connecting with each other, according to certain purposes and certain structural ways. The technology architecture — or technology architecture — is ultimately tailored around business growth, team size, and team characteristics, with the ultimate goal of improving overall r&d efficiency while maintaining quality and stability online.
Since the technical architecture is designed around business growth, team size, and team characteristics, we need to take a look at our project and team background. The project and team background of Meituan Dianping Hotel have the following characteristics:
- Project characteristics: There are similarities in the differences between projects. For example, although the objects facing the B and C end projects are different, they also need to be built and tested. For example, the B-side pages are basically query, form and chart pages, although the services are different from each other. It would be very inefficient if we had to redo these things for every project. Therefore, we need to increase the reuse rate between projects.
- Team characteristics: large scale. There are more than 100 people in the front of our hotel business group alone, and it is still growing in scale, that is to say, there are more and more people. As we all know, scale will lead to the increase of communication cost. We hope to reduce the cost increase brought by scale as much as possible, and fix the cost of scale as much as possible, so as to achieve scale effect.
standardized
Then, based on the characteristics of such projects and teams, we can clearly see that the first thing we need to do is — standardization. The nature of standardization for the team is that we constrain the various technologies used by the team, divide and narrow the selection.
There are many advantages to such constraints.
For projects, we can extract the reusable part of each project and improve its reuse rate through standardization. For example, it is common to separate component libraries so that components can be reused across business projects. For example, we take services such as deployment and monitoring and separate them into separate services that can be used by each line of business. Therefore, after standardization of projects, we no longer need to do repeated technology selection work, and can easily find a variety of public services to reuse, and ultimately achieve the ultimate goal of improving efficiency.
For team members, after standardization, projects are almost the same in terms of type selection and public services used, so the movement of people between different projects has almost no technical cost and only requires familiarity with the business. In addition, for elementary and intermediate students, they can clearly see the panorama of our technical architecture and have a clear and clear technical stack to master. From the perspective of the company, the team can be more targeted in training and recruitment. For senior talents, we can provide more space for students who are willing to think and capable to participate in the thinking and optimization of technical architecture, contribute their achievements to a large team, influence more engineers and projects, and obtain greater benefits. The final results can be calculated by multiplication.
In order to achieve standardization, we need to design around this goal.
This is the technical framework developed by our Meituan Dianping hotel team after standardization. We can see that our standardized process specifications cover the entire workflow from development to build to deploy to run.
automation
So with standardization, we will find that some links are mechanical repetition, and we can use tools and machines to replace them. For example, if we have code specifications and procedures for checking code when submitting code, we can see that checking code can actually be automated. We used the Lint tool to do this automated checking.
Automation can increase our efficiency exponentially or even infinitely.
In the technical architecture diagram of our team, we can find basic tools, automated testing tools, deployment platforms and monitoring systems. These tools and platforms are all made by us after standardizing and finding that we can replace manual labor with machines. Let’s take two more specific projects, just to give you a feel for it.
The background of the first example is that the popularity of applets is slowly beginning to spread. We have a lot of applets, and these applets often have the same set of mobile pages. So we find ourselves doing the same business on different platforms. So we invested some human resources to study how to implement a set of code to run in both mobile terminal page and small program page, and even Native. Considering that vue.js is the main focus of our team, we made a tool called mpVue, which converts the grammar of Vue into the grammar of applet, so that the mobile page can be perfectly converted to the grammar of applet, realizing the rapid development and multiplex of applet. Compared with the previous we need engineers to learn small program development, with this tool, our engineers almost no longer need to learn the development of small programs, thus reducing the cost of learning and development of small programs nearly infinitely. In the ideal future state, we can implement a set of code that can run directly on the Web end, small program end (including wechat and Alipay) and Native end (with the help of Weex), write once, run everywhere.
The background for the second example is that our B-side requirements don’t require much of an interface, just core functionality, and these pages are very similar, usually falling into three categories: query pages, form or detail pages, and chart pages. These requirements are different from business to business, but in fact we are doing almost the same thing, we are developing these pages directly in the heap of tag heap components, mindlessly binding data, writing HTTP requests. So we wondered, can we do these simple mechanical things faster, or even automate them? So we built an IDE, which is a graphical page-building tool packaged on TOP of Vue that allows engineers to quickly build front-end pages by drag and drop, and supports data binding. It is very fast to build pages using this IDE. The data we collected here is that some pages that used to need 1-2pd to write only need 1-2 hours with our tool, increasing the development efficiency by 30% to 80%. So far, we have been able to use the IDE to build some pages that are not very specific to the page requirements, and have a basic page building capability. After that, we will continue iterating through our IDE, providing templates for those three types of pages, and even automatically generating pages from API documentation, allowing engineers to develop pages with minimal changes, further improving our development efficiency.
In addition to these benefits of automation from standardization, we will also find that when we achieve automation, automation in turn promotes standardization. Because of people’s laziness or lack of ability, some students may not be willing to follow or secretly do not follow the standard, for example, many people are unwilling to follow the code specification, the equal sign around the space and so on. So when we have an automated inspection tool, if these students do this again, they will fail the inspection of the automated tool, and they will not be able to submit their code, so they have to write their code according to our standardized code specifications, so that they can submit their code successfully. Therefore, we can say that although automation is said to come from standardization, it will reverse to promote the implementation of standardization, which is a virtuous circle.
How do front-end engineers grow? How to become a middle/senior engineer/technical expert in Meituan Dianping?
So that’s the end of the architecture methodology, and now let’s talk about the methodology of front-end engineer growth.
We say, in fact, everything we do comes down to the impact on people. For example, one day all the code of the project we were working on was lost, including the server, everyone, the computer and git repository, but our people were still there, and we could have rewritten the project very quickly and much better. Because in the process of doing projects, the thinking and design we experience will eventually become human experience, which is the most precious thing. Therefore, as a company, the most important thing is to cultivate people.
Conversely, as an engineer, what I value most is my own growth. Many engineers — myself included — have come to a point where they have a sense of who they are: I can handle all the needs, I can flexibly use a lot of UI frameworks, build tools, test tools, etc., I can program functionally, I can program responsively; Some engineers will say, I have more experience, the business is more skilled, I also take a few people to do business together. But you will still have a question in my heart, everyone realized, at this time to dig deeper into technology, input and output ratio is not high, for example, we may be able to spend a lot of strength to the working principle of the V8 completely understand, read it again all of the source, do this for us, may not have any help to the company. The problem is, we are confused. We clearly feel that we have reached a bottleneck, but we don’t know how to break through it.
When I met this question, I asked many people, including well-known figures in the industry, such as @ He Shijun, @ Gu Yiling, @ Xiaojue, @ Xiaotaro, my jue boss and his jue boss. Some of them were managerial and some were technical. They all gave me a lot of experience and guidance from different perspectives. Next, I would like to share with you the methodology from engineer to technical expert based on meituan’s talent cultivation philosophy after my reflection and digestion.
For us front-end engineers, even terminal engineers including the client, to advance to the technical expert level, mainly from the three aspects: planning, review and vision. Of course, in addition to these three, there is a higher level of business thinking, and by business thinking I mean that we are very skilled in the business, from the initial support of the business with technology, to the ability to develop some better technology, to drive the business back. One example that everyone is familiar with is artificial intelligence. But this capability is not easy to do on the terminal, so we focus on planning, review and vision, which are three different directions.
Do planning
Planning is to look ahead. It is to think and consider the overall, long-term and fundamental problems in the future, and to design the plan of the whole set of actions in the future. In plain English, it is an action plan to implement the overall objective. Many people don’t focus on planning, whether it’s for individuals, teams, or projects. But without a plan there’s really no way to work results-oriented, no way to measure what we’re doing to our expectations, because there are no expectations.
Common situation is that some of the ideas of students, may sometimes can think some good idea, then want to let the company to give him a chance to do, but most of the students will appear such a problem is: the only focus on technology on how to implement it, without a clear plan, target may be only said most solved a what kind of problem. A lot of times, you don’t get good results because you don’t plan.
So how do you plan?
First of all, when we make planning, we should make clear one premise, that is, we should do it around the business, we should do it with the understanding of the business, we should not be divorced from the business. For example, your company’s business is only on the client side, and you put forward a solution to solve the performance problem of the PC side, it is certainly not able to win resources to do it.
Then, on the premise of combining business, our first step is to determine our target income, such as what problem we solve and how much efficiency it can improve for us in which link.
Then the second step, is the most easy to pay attention to the specific design plan to achieve this goal, this design plan is actually simple to say how to achieve technology.
Then the third step is the landing path. The landing path is a plan of how we implement the design plan. For example, if we need to achieve this goal in 3 months, what should we deliver every month or every week? This is what some people would call a milestone. One of the most important things to do when setting milestones is to decide on priorities. Think and argue about priorities, define priorities, and set milestones. In addition, we have to set the extent of the problem in what circumstances, we have to stop the loss.
The fourth step is the measurement standard, we should develop some quantifiable objective standards, so that when we deliver, we can have a standard to measure our income, to see whether we meet the initial goal.
It should be noted that the measurement is done at the time of planning, and many people tend to measure it at the end, which is actually putting the cart before the horse.
For checking
The “measure” thing is really a second set.
While planning is looking forward, review can be said to look backward. It refers to the way that we learn from past experience and actual work to help us effectively sum up experience and improve our ability. There are even more people who don’t plan than those who don’t plan. A lot of people just look at what we’re going to do later, but don’t go back and look at what we’ve done before, so we don’t know how well we’re doing.
So how do we make a rematch?
First, we need to review our original goals; And then we’re going to evaluate what we get when we do that; The third step is to analyze the difference between the goal and the outcome. The fourth step is to summarize and sum up what we found in the review process that we did not do well enough. If let us do it again, how can we do it better? And what lessons can be learned from doing this that we can reuse elsewhere.
So in the second round, we are likely to find some problems.
For example, in the most serious cases, we do not plan at all, have no goals, or the goals are not clear, or there is no consensus among team members on the goals, or even our goals are disconnected from the plan. Such problems can be found in the first link. So that we can know in this aspect, we are not doing enough good, we get a lesson, we will know, before the next time we do project, must first plan, to set clear goals, and ensure that all project members can agree on a target, and we design our plan is to meet our target.
For example, we may find that in the process of evaluating results or analyzing differences, the results we end up with are not as good as we expected. So we need to analyze, which link is the problem, why such a problem, we can optimize the process and so on, can avoid such a problem?
Again, for example, we might have accumulated some experience in this program, learning a technology or get what comments, etc., then we can summarize it, we can look at in other project, to reuse the experience, to improve the development efficiency of our team in the future.
Maintain technical vision
We have just said that planning is to look forward and reviewing is to look backward, but this is one-dimensional. We also need to look outside and turn our capability model into a two-dimensional one, so that we can find ideas or problems more effectively when planning and reviewing. So what about looking out, maintaining vision.
The field of vision is the field of our thoughts or knowledge. However, our vision is not fixed, because the world is constantly changing. We should not stay behind closed doors. We should embrace the changes and adjust our development direction accordingly. For example, when we make planning, we can extract references from other people’s projects or sharing, and then combine them with our own business, so that we can make better planning. So keeping our vision is key.
So how do you keep your vision?
We can draw three circles, namely core circle of concern, general circle of concern and literacy circle. The three circles are logically divided according to team business, individual interests, and industry hot spots.
- The core circle of concern refers to the things that we may use every day in our team’s business, or that we are interested in, or that are very popular in the industry, and we should keep a high level of attention. It would be good to know how it works and how it or its ecology changes from day to day.
- General attention, is that we in the business of the team may not be used to, but then is likely to be used, or own a bit of interest, or we can yupan industry is likely to be after fire, we must keep a certain attention, we want to know what it is about what to do, solve the problem, the industry how to evaluate it, How many companies are using it and what are the trends. Faster speed and low cost
- Literacy concern circle means that we may not use it in our business, we are not very interested in it, and the industry may not be very popular. We do not need to put too much energy into it. We just need to know what it does and what problems it solves.
conclusion
So finally, let’s make a summary of what we have shared today and also answer a question from a friend in front. We believe that an effective front-end team has three elements — architectural patterns, infrastructure, and cultivation systems — that are constantly influencing each other.
We have standardization and automation methodologies, we have architecture patterns, and we have infrastructure that optimizes our architecture in reverse.
At the same time, we also have our training system, we can train different levels of engineers. For lower-level engineers, we can train them on a specific design learning path or technical panorama against our architecture and infrastructure. For senior engineers, we use the same methodology that engineers use to develop their ability to plan, review, and maintain vision to reverse the optimization of our architecture model and infrastructure.
QA
Want to know how to measure the effectiveness of the front end team? What are the elements of a mature and effective front-end team?
That’s a good question, but I don’t want to go over it here as we talked about the elements of a mature and effective front end team. Let’s talk about how to measure the effectiveness of the front end team.
Efficiency is actually invisible, but it is objectively real. In general, then, is the size of the task that can be accomplished in a given period of time. We can measure efficiency in several ways. One is that we can measure how much it costs to do something similar; Or vice versa, how much we can do for the same cost. There is another direction, which is that if we want to do something, how much of it is redeveloped from scratch, and how much of the previous accumulation (experience and infrastructure) can be reused? How much faster can we do the same thing with tools and proficiency. The same complexity of requirements, how many fewer people to implement.
Want to know what is the most efficient technology system development with a five-person front-end team?
That’s another good question.
The biggest difference is that we can produce scale effect. We may spend 100 PD to make a tool, which saves 50% of our manpower each time. A team of 100 people may only make two demands and then recover the cost. But with a team of five people, you might have to do 40 times to make it back. So small teams can use our model, but not exactly the same. Consider just doing standardization, not building your own tools for automation.
But small teams are actually different from us in one way, that is, small teams are very agile. Agile means that it’s really cheap for you to switch stacks and tools, and you can use that agility to try and error quickly, to reuse proven solutions to get things done as quickly as possible.
How does the team balance business development with technical advancement?
In fact, I don’t think business development and technology improvement are two contradictory things. On the contrary, when we talked about how to do planning, we mentioned that one of the premise of planning is that we should optimize user experience and improve conversion rate by focusing on business and focusing on business pain points.
One of the abilities of advanced engineers is to think about the direction of technology based on the business, so I would recommend students to improve their technology based on the business.
Just from development to management, a little not adapt, how should answer the question sheet transition? Meituan dianping front end department in the interview will mainly examine what aspects of ability? What’s the interview process like?
The transition from development to management is a transition from individual contributor to team contributor. The essential difference between the two is that technology takes results directly, while management takes results through others. In the beginning you may feel that a lot of things are not handled as quickly by others as they are handled by yourself, but you need to adapt to this transition, because as you grow, as your coaching helps others, your team will grow to scale. As a manager, it’s more about planning and reviewing more deeply, both for yourself and for your team.
Our interview mainly tests the abilities: learning ability, problem solving ability, professional ability, past experience, potential for follow-up growth…
Interview process: two rounds of technical aspect, one round of comprehensive aspect, the ability to be examined above can be basically reflected from these three rounds.
Want to learn more? Want to join us?
If you are interested in our company with a deep technical research atmosphere after listening to this live, welcome to send your resume to us. The email address is [email protected]. At present, we still have hundreds of front-end positions in the recruitment, as well as other technical positions, welcome to join us.
If you want to know more about technology and team related content, you are welcome to follow the wechat public account “Meituan-Dianping Technical Team”, where we regularly write articles and organize activities.