Ever in the knowledge of a question and answer < engaged in front-end really do not have back-end high salary? > < p style = “max-width: 100%; clear: both;

In my opinion, with more and more Internet products, users will also continue to ask for better user experience, and the front-end students will play an increasingly important role. The higher the responsibility, the higher the ceiling. (No need to add a quote,….)

At that time, the perspective was focused on product experience. Now I have been working as an ant for about a year, and I have some new ideas about it. While the front end is getting more powerful, the technology stack is getting more demanding. But from an engineering point of view, the front end is currently at a lower class level.

First, how do we, as front-end engineers, define “engineering”?

What is front-end engineering

When I just graduated, I was doing full stack in a startup company with a title of Web development engineer. There was no separation between the front end and the back end, and the project in my heart was the whole back end engineering code that I had. There was no concept of front-end engineering. To me, front-end was JS + CSS + HTML, which made no sense without the server. By itself, I wouldn’t call it a project.

Later, the three frameworks appeared, and the front and back ends were gradually separated, and the concept of “front-end engineering” began to appear. At the beginning of 17, I was interviewed by a small startup company. The interviewer asked me how to do front-end engineering. At that time, I replied, “Front-end engineering is: code modularization, function component, packaging, build, release automation, process.” Over the next year or so, my engineering concept will remain roughly the same, with the possibility of adding a development specification.

Under this concept of “engineering”, WHAT I think of as “front-end engineering” is the “front-end code” in front of me, whose ultimate purpose is to output front-end pages for users. What I focus on most is how to produce better and more powerful pages for users with higher efficiency and quality. Front-end Coder has done a lot around this over the years:

High efficiency

  • ES6+
  • Multiterminal unified
  • Interface management with Mocker
  • Framework, tool library, component library

High quality

  • High quality development
    • git
    • code review
    • The development of specification
  • Online quality assurance
    • The monitoring system
  • Emergency – Fast rollback capability

Better experience

  • Multi-size fit
  • Small program
  • A high performance

Ability to more

  • Complex interactions
  • Native ability
  • Animation, games

Of course, there are some intersections, such as the emergence of the three frameworks to provide the possibility of highly interactive pages, but also improve the overall efficiency and quality of development. For example, a front-end iteration management system will be unified around high efficiency and high quality, responsible for engineering iteration, construction, release and rollback.

In fact, I’m just going to list it casually, there are a lot of things that I didn’t cover, but I can feel the advance of the front end in the last few years. Stand again in this period now, look before and after the end of the separation of the period, that backend part-time JS, visual part-time CSS of the ancient times, really can not be called front-end code “engineering”, more not too shy to say front-end programmers for “engineers”. It is no wonder that many college teachers and students at the back end disdain the front end.

But today, the scope of the front end is much larger than it was then, and the complexity and capabilities of our “engineering” are far greater than we could have imagined. We can proudly call ourselves front-end engineers. But IT seems to me that we are still a little short of being software engineers.

Front-end engineers, first of all software engineers

There are a lot of people on the Internet who have said that. It seems to make a lot of sense, but it doesn’t feel good. I’ve come to appreciate this phrase more in recent days, thanks in large part to ant’s extensive practice on Node.

Ant should be the practice of Node more companies. At present, most of ant’s mobile terminal services have corresponding experience adaptation layer -BFF layer, also known as the Node middle layer in popular understanding. Its main responsibilities are: connect the page to the back end, aggregate the back end interface, do a good job of data transformation, output data results that best meet the page expectations. Its main purpose is to make the back end more focused on the domain model, the design of the page data to the front end, more professional and efficient each other. More generally: let the business development faster!

After adding ants, the BFF layer added a lot of work to me. We need to start to give their own page design interface, need to connect to multiple background systems. The new interface may need to consider extensibility; Old interface changes need to be considered for compatibility. If back-end changes are involved, you need to assess the impact of the changes, and you need to assess the dependencies of the system and the order of release. In addition, gray scheme, monitoring scheme and emergency scheme of node layer and front end should be considered when the demand goes online.

Therefore, in our group, front-end changes involved in business requirements need to do system analysis, and back-end system analysis also needs to participate in, which involves all the above mentioned. Especially when the demand changes are large, the impact is wide, and even involves the migration, upgrade, and reconstruction of multiple systems at the same time, the complexity will rise rapidly. For the larger volume, more users of the business, this is a test of engineers.

As you continue to experience these challenges, there may come a moment when you feel that as an engineer, you have only focused on the front-end code you have at hand, and have given too little thought to software systems engineering as a whole. What role does front-end engineering play in this software system? What systems affect it? What systems does it affect? What will be the impact of their changes?

So the front-end engineer, as a software engineer, should look at the whole software system engineering. The front-end engineer does not only complete his own front-end engineering, but also completes a part of the entire software system, and it is not independent of the whole system. As a part of the whole system engineering, front-end engineering should know how to ask for, know how to influence, understand the ability and pain points of the overall project, and think about how to improve the overall project.

Let’s look at this: front-end engineers, first software engineers. I don’t know if you can feel a little bit more.

Low front-end status

But if we look at software engineering as a whole, then we realize a painful truth: front-end engineering plays a very low role in systems engineering as a whole. At Ant, the front-end engineer took a step back and added an extra layer of Node to expand their share of the overall systems engineering, which is still better. For most of the students only involved in web page engineering, looking at this huge software system engineering, even if they have a heart, it seems powerless.

I actually think a lot of front end engineers are pretty good. Especially in recent years, more and more excellent graduates joined the front end. Sometimes I feel that the interaction logic on the front end is so complex that its code level requirements are far higher than most business scenarios on the back end. But the sheer level of code does not determine the impact of front-end engineering. Even if you can knock out zeros and ones and make a page out of it, it’s still a page.

Front-end engineering is the most upstream (user entry) in a software system. As a result, there are no other systems that need to access the services of the front-end system. In the whole software system, the front-end interconnection of the system is less, the impact of the system is less, the engineering status is low. Unlike the back end, it needs to provide capacity for the front end, and need to ask the background, data layer to obtain capacity, but also may need to ask other business back-end to obtain capacity, many docking systems, engineering status is naturally high.

As a result, the front end is often not the decisive factor in whether or not a product can be implemented. In the software system, the upstream system needs to access the downstream system services. In other words, upstream depends on downstream. This naturally leads to technology assessment starting downstream. By the time you get to the front end, it’s the last hurdle. And this obstacle, business side often is anyhow also get. If the kanbi is high (interactive vision is difficult to achieve), the final solution is to reduce the complexity of interaction and user experience to ensure that product features come first.

A lot of students think that the front end is too little involved in the business. But we feel very involved in the business. I know what the pages are and what the features are. But understanding is not participation, influence is participation. The engineering impact of the front end, as well as the business impact, causes the front end’s engagement with the business to be intrinsically low. In this case, to put it bluntly, a lot of the front end is just assembly line workers. Here comes the visuals. Implement it. It can’t be realized, so I’ll switch back to a simpler visual draft. Not willing to be an assembly line worker ah, it seems to see the end of old age after being laid off. So what do we do here?

Front-end anxiety

The front end seems to be in constant anxiety. Our main conflict in the last two years has been between the explosion of new technology on the front end and the inflexibility of front-end programmers. In the last year or two, the front end technology stack has stabilized and wheels are relatively few. In addition, front-end programmers are also more difficult to learn, the feeling of not moving along with countless nights of learning and gradually dissipated.

That’s when the front end starts worrying about whether the ceiling is too low. Is the salary less than the back end? What are the barriers to front-end development? I think our principal conflict has changed, and it’s between the demands of the growing engineering status of the front end and the limitations of the front end.

Smart or hard work, plus the accumulation of time, always can solve the “learning” problem. But the front-end engineering status of the demand for fear of their own no matter how hard they can not be solved. The only way to solve the current front-end anxiety is to break the limitations of front-end engineering, increase the influence of front-end engineering, and elevate its engineering status. Finally, front-end personnel can also be masters in software system engineering and participate in the construction of software systems on an equal footing.

Only when the front end is up can the front end engineer get rid of the anxiety, and this is not a fight of one or two people, it needs to be achieved by everyone. I personally came up with three strategies.

Rise of three meter

Out of thin air

Can identify pain points in existing projects to create a system or service that improves performance and drives business results. The typical Node layer uses the Node server capability to build a BFF layer for front-end service. Thus, in a software systems engineering, a layer of systems was created, expanding the engineering domain of the front-end engineer.

Outbred recent attack

In a systems engineering, if we do more work, it is natural for someone to do less. What we have created out of thin air is “dirty work” that others do not want to do. If I need to encroach on downstream core capabilities, they won’t necessarily give in. At this time, we can adopt a “distant enemy”. If we can connect directly to downstream downstream, but also have downstream capabilities. So what’s the point of our existence downstream? Now popular FaaS seems to provide us with an idea, or is a chance.

Going to

The front end, while an upstream system, can proactively expand business possibilities by improving its engineering capabilities. By dropping the bottleneck of possibility, the downstream system is encouraged to improve its own capacity. Change passivity into initiative, change acceptance into influence, and then improve their engineering status. Typical of small programs. The small program was originally implemented by the client students, and in fact, it was also dedicated to the platform ecology at the beginning. Because the technology stack is basically aligned with the front end, it’s a huge benefit for front-end developers (as opposed to client-side developers). Front-end development students crazy influx, on the one hand, do a lot of infrastructure work, greatly improve the small program development efficiency. On the other hand, the large number of small programs shows businesses the infinite possibilities of small programs. In addition, there are many demands on the small program itself, such as wechat small program support Npm package. In the community, front-end programmers are constantly working on small programs, and when it comes to small programs, everyone seems to be bragging about the front-end.

I believe that with the continuous struggle of countless outstanding front-end students, a few years later, the front-end engineers will certainly be another achievement. Hopefully, we can proudly call ourselves a software engineer. We’re still learning, but it’s not about anxiety anymore, it’s about pure love of engineering and code

Come on front-end programmers! Let’s program for the rise of front-end engineering.

​

About us:

We are ant Insurance experience technology team, from the Insurance business group of Ant Financial. We are a young team (no historical technology stack baggage), current average age is 92 years (remove a highest score 8x years – team leader, remove a lowest score 97 years – intern young brother). We support almost all of alibaba group’s insurance businesses. 18 years our output of mutual treasure sensational insurance industry, 19 years we have a number of heavyweight projects in preparation for mobilization. With the rapid development of the business group, the team is also expanding rapidly. Welcome to join us

We want you to be: technically grounded, deep in a specific field (Node/ interactive marketing/data visualization, etc.); Good at precipitation, continuous learning; Personality optimistic, cheerful, lively and outgoing.

If you are interested in joining us and working together for the rise of the front end, please send your resume to [email protected]

In this article: Ant Insurance – Experience technology group – a Xiang

Gold address: Xiangxuechang