The first session of the front-end technology sharing conference of Master Education has been closed on January 23. The following is the edited version of the lectures delivered by the big lecturers. Thank you for your support:

introduction

Cheng Bo, front-end technical architect, from Zhangmen Education Business system team

The following is part of Cheng Bo’s wonderful speech:

Big front-end era, front-end technology architecture design

When I first started working, I joined the UED team. There were nearly 30 members in the team. Most of them were engaged in interaction and page design, and only about 10 students wrote codes. Of the 10 of us, only 2 write JS code, the rest of us write HTML, CSS; In terms of work flow, I transformed the design draft into HTML and CSS codes and handed them to JS development students, helped us add interactive effects such as pop-up boxes and banner rotation, packaged them into ZIP packages and sent them to the PHP team. After that, all business data integration, deployment, monitoring and so on have nothing to do with us.

Why was your previous job so limited and narrow? I would like to make a simple guess as follows:

  1. Electronic equipment is not popular, the vast majority of people do not touch a computer, notebook several times a day
  2. The morning was expensive, the Internet was slow, and the experience was terrible
  3. There was almost no social Internet culture, big data, visualization, informatization, and so on, which we now consider necessary concepts for enterprises. At that time, there was a blank. In short, front-end development lacked specific business implementation scenarios

Now, not the same, is the age of front-end business scenario blooms, I go to the mall to have a meal before, beside the escalator see a vertical floor signs, I went up and slide the screen to see what the 4th floor has stores, row 2, 3 seconds, the screen doesn’t move, I was very surprised, think it is bad to the screen, Later it was discovered that the screen was fixed, making a joke;

And then I thought, why do I feel like if the screen doesn’t move, the screen is broken? The answer is simple, because I think any screen that I can see is bright, it should be interactive;

So, it’s a great time for the front end, because we have a lot of business scenarios!

Big front-end era, we have higher requirements for front-end technology architecture

One person to do the project, and 100 people to do the project, the team’s requirements for engineering are definitely different; Working on a single project requires different levels of automation than working on 100 requirements at the same time. In the past, our front-end products were only used by hundreds of people, thousands of people and tens of thousands of people. Now our front-end projects are online, and we may face tens of billions, hundreds of billions, and trillions of traffic, which also puts forward higher requirements for our monitoring, early warning and so on. The list goes on

For all the reasons above, in this era, teams and companies require front-end engineers not only to be able to write H5 pages and do interaction; Now front-end involves more and more fields, the quality and ability of developers are more and more high requirements, this is an era of more scenes to empower, power, pressure coexist

Technical architecture design for our front end

The graph is closer to the business and closer to the support. On the right side is the monitoring of the whole life cycle. I would like to describe [environmental management], [cluster management] and [Monitoring Management] :

Environmental management: In the past, our team made a demand for a wechat public account, and we have more or less understood the development process of the public account. Wechat gave us a key and secret, and we exchanged these two fields for tokens, and then cached them. In business scenarios, we took tokens to get users’ information data. WeChat ID when our team is only A test, but there are many sets of test environment, each set of test environment is mutually exclusive, isolation, but in WeChat under this scenario, when A and B test students do the test at the same time, will cause the token application repeatedly, the service request each other play, eventually lead to resource depletion, the experience is very poor, and there are many similar scenes, Such as Redis, DB and so on, this is the problem of environmental management

Cluster management: In 2015 and 2016, we had a demand for one-hour seconds killing. We held activities at 12:00 and 19:00 every day, which only lasted half an hour. At that time, Ali Cloud did not provide the functions of rapid expansion and quick release. And our back-end because of various reasons, also is not very good do kill requirements, then I said to my boss, the front-end to implement this function, we develop the submitted test, the test is passed, function without any problems, then our ops to develop students come and tell me, we kill scenes around 20 w QPS, reported to the front end need how many sets of ECS? I was stunned, because I had no idea what the server load was, and we did a crunch test that required about a dozen 4C8G ECS, which was a cluster management problem

Monitoring management: When in November last year, our product manager told us the needs of a shopping cart, then are the two version of PC, mobile terminal, the workload is very big, and then we develop a friend to come looking for me, ask I can communicate with products that do not support of IE and I say there is no problem with friend, later I find our ops students, I asked him if he could help me pull the production traffic data. After we got the data, we looked at it and found that 95% of the traffic was on the mobile end, and 5% on the PC end, and there was almost no traffic from IE on the PC end. I sorted out the data and sent it to the product, indicating that we did not support IE, which was very reasonable and well-supported

Why do we have to do technical transformation

Some of the projects in our team now have a history of 3 to 5 years, which is actually very difficult to do technical transformation. Why do we need to set up a special project to do technical transformation? I asked myself a few questions

  1. Some of our current projects have different styles, such as variable Config, interface request proxy, development dependency, runtime dependency and so on. If the project is urgent, many people will cooperate to develop it. By looking at the historical remarks, can we achieve seamless and quick development for non-involved developers?
  2. Compared with the front-end technology architecture diagram we designed before, if we do not make intensive transformation in the most pre-oriented application layer, will the hidden cost be controllable in the future in terms of environmental variable management, ECS cluster management and monitoring?
  3. If the technical transformation of these projects is not done as a special project, is it feasible to do it according to business requirements?
  4. Can we tolerate teams falling behind in technology?

As soon as these problems came out, we felt that we must set up a special project to do technical transformation

Technical modification of trample pits

Step pit 1: too many ideas, technical transformation steps too big, can not Hold!

At the beginning, the technical transformation we made was very extensive, and it took us a long time to optimize it. After testing, the test students also sent back a lot of style bugs, because there were too many details of the historical business, and it was too risky to do it all. At last, we had no way to return all the codes in this part. The second project was provided, we will make down the MVP principle (minimum value), around in front of us the technical architecture design, design standard, then just do this construct, environment management, API agent, unified dependent libraries, and so on, to achieve the goal of a few other problems, we properly on the business needs to do

Step on pit two: for the sake of technical transformation, technical transformation of the project is completed, and manpower is wasted

Among us have a project to do technical transformation, test resources very nervous, after the test, is almost two requirements before and after the pressure release plan to do regression test, then the project successful online, but awkward is, then the project, there is no big demand, some time ago I went to see the record about the release of this project, After the technical transformation, only one optimization demand online; This is caused by the insufficient research on project background, urgency of business needs and frequency of development before technical transformation

Related party communication is not in place, do not pay attention to business value, no one acceptance

When doing the project design, technical transformation, I actually also pretty think we plan to do well the particle size, business, the development, the acceptance of the party, the result is stepped on a big pit, our financial system, release the modification on UAT environment test running, code is also close to the master branch, we rush to pull the product classmates to our technical group of inside, I hope he will do the acceptance inspection. The product student said: At this point, he will not do the acceptance inspection. I used to communicate with our classmates, hopes to persuade him to do the acceptance, chat, I found that our students are right, because is our company’s sales monthly in December, it is because at the end of the year, this is a super monthly, or half a month late on half a month in advance is no problem, but this point is risk is larger; Later, the technical reform of this project was delayed for 20+ days. In the middle, due to the iteration of some business requirements, some code conflicts occurred. In fact, we calculated that about 4 people per day were wasted. On the one hand, technical transformation is to meet the needs of our front-end technology team. At the same time, business demand and business guarantee is one of our most important and core values

Technological transformation is more than technology

In the middle and late October, when we first started to do the technical reform plan, we were always thinking whether we should use webpack5 or even make jokes about Vue3.0, etc. How could this technical reform reflect our high technology? On the other hand, we often joked about the poor technical design of these projects in the past

But later, I think carefully, I found that the cognitive bias is not very accurate, there’s a survivor bias, our department in the past few years, done projects must be more than we are now, seven or eight items of the modification or even poking fun at most of the old project, we actually only three or four of our technical quota, now we have 50 + project team, There will only be more history items, where are the other items? Because there are no requirements iterations, or the business is being dropped, a lot of the business code is customized to follow the company’s phased goals, and it doesn’t seem like a problem

My other non-technical thinking is that technological transformation is a process that will continue repeatedly. With business iteration, technological evolution and continuous progress of time, in another 3 or 5 years, especially in the front-end field, technological transformation will be a cycle again. Therefore, we pay attention to the underlying support, such as environmental variable specification, API request specification, construction specification, dependency library specification, traffic gray scale, log monitoring and so on

We often describe technical transformation, it is in the process of marching rocket in parts, in part it is a “ecomax” brave of live, but it is a prerequisite for a rocket can fly, at least can also be modified, it actually requires that the rocket itself to high quality itself, technical transformation, so this time we are very concerned about support this layer, it is for this reason, too

Thanks for reading, more exciting content, welcome to pay attention to our front-end education technology