Guide language

“Front-end engineering” is a common topic in today’s front-end field. Today, as the front-end field is becoming more and more prosperous and the business is becoming more and more complex, front-end engineering construction is the general trend, and each front-end team is building its own engineering system. But we can not blindly pursue engineering, engineering for the engineering, the construction of any system is need to cost, we need according to the characteristics of the own organization and business are clear that the current stage, the input and output than by calculation, the suitable for your own organization and business of engineering solutions. With the rapid development of smart enterprise business, there are more and more business lines. In such a multi-business scenario, the front-end team of smart enterprise also starts to think and build its own front-end engineering system.

What is front-end engineering

The so-called engineering is a process of systematization, modularization and standardization.

The engineering in “front-end engineering” refers to software engineering, which is essentially a kind of software engineering. Front-end engineering is different from traditional software engineering, but the problems are the same. The traditional software development model is divided into requirements analysis -> design -> code -> test -> run -> maintenance and other stages. In terms of front-end engineering, the problem to be solved is how to improve the production efficiency in the coding -> test -> maintenance stage.

Therefore, all work aimed at improving front-end development efficiency, reducing front-end development cost and improving front-end application quality is “front-end engineering”.

What front-end engineering involves

Generally speaking, front-end engineering includes modularization, componentization, standardization and automation. The following is a brief introduction.

1. Modularization

“To put it simply, modularity is breaking up a large file into smaller, interdependent files that can be assembled and loaded uniformly.”

Front-end modularization includes JS modularization, CSS modularization, resource modularization and so on. Nowadays, the exploration of modularity in the front-end field has become more and more mature. For example, JS modularization. Before ES6, JavaScript did not have a module system, and usually used some module loading schemes such as CommonJS, AMD and CMD. Now ES6 has specified the module system at the language level, which can completely replace the existing CommonJS, AMD and CMD specifications, and is easy to use.

2. Componentization

Componentization ≠ modularization. Modularity is the separation of code or resources at the file level. And componentization is at the design level, the separation of user interface, in other words, all the things can be a component on a page, the page is a large business components that can be split into multiple medium business components, and then can be split into multiple composite components, composite component based components, and then split into multiple until it into the Dom elements. In real development, the front end engineer only needs to build pages with these components, like building blocks. Nowadays, after continuous exploration by front-end engineers, componentization idea has been widely used in current front-end development, such as the most popular React, Vue, etc., which are based on componentization idea.

3. Normalization

Generally speaking, front-end standardization can be broadly classified into coding specification, development process specification and document specification, etc., and there are some sub-categories in each category, such as coding specification contains directory specification, file naming specification, JS/CSS code specification, etc.

4. Automation

Automation is a powerful tool to improve the efficiency of front-end development. “Any repetitive work done by simple machines should be done by machines.” Front-end engineering automation basically includes the following aspects:

  • Icon to merge
  • Continuous integration
  • Automated build
  • Automated deployment
  • Automated testing

Why do we need front-end engineering

With the continuous development of smart enterprise business, there are more and more business lines. The problem we are faced with is not only choosing a front-end framework and technology, developing business pages and supporting a single business. In multi-business scenarios, we need to face some more complex systemic problems:

• In multi-service scenarios, each line of service is configured with tedious construction and packaging configuration, and repeated production is time-consuming and laborious, and some best practices cannot be easily shared;

• In multi-business scenarios, each business line develops independently in terms of front-end technology selection and technical solutions, and technical solutions are not unified, resulting in low technology reuse rate and resource waste;

• In multi-business scenarios, there are more and more team members. How to conveniently unify the coding specifications of team members to facilitate team collaboration and code maintenance is a problem we have to consider;

• When a new business needs support, how to quickly replicate the existing best practices and development experience to help more businesses

Faced with these problems, the idea of building our own front-end engineering system came naturally.

How do we do front-end engineering

First, we need to analyze the current state of the organization and business. Wisdom enterprise in modular and componentization has made some exploration and practice, and achieved good results, but as the business development, the continuous extension of team personnel, standardization and automation needs more and more highlights, based on the demand, we carried on the construction of standardization, unification and automation.

The canonical

As the team continues to expand, we need to develop some unified norms to make certain constraints and guidance on the usual development work. After preliminary investigation and discussion on the current situation of business and organization, we developed our own “smart enterprise front-end specification”, which includes A series of specifications such as JS code specification, Less code specification, file naming specification, component library management specification, Git branch management specification and so on.

unification

When there are more and more businesses, each business develops independently in terms of front-end technology selection and technical solutions. However, many of them are unnecessary and will only cause some unnecessary troubles and waste of resources. For example, the two businesses use less and SASS respectively. So we need to do convergence and unification of the base technology stack. Therefore, after investigation and discussion with business development, we agreed on the “decision tree of intelligent enterprise front-end basic technology”, which includes front-end framework, component library, style, network request library and other common front-end basic technologies, such as:

  • Front-end framework: React
  • Component library: PPfish, PPfish-Mobile
  • Language enhancement: typeScript
  • Style: less
  • Quality inspection: ESLint, stylelint
  • Build tool: Webpack
  • Network request library: Axios
  • .
Typically, business developers can simply choose the technology in the decision tree if they don’t have a particular need for it. If there are special business requirements, other technical solutions in the same type of decision need to be introduced. Only after passing the technical review, can they be used in business. In addition, in business development, in addition to the front-end technology stack, there is also the unified convergence of tools at the business level, such as the unified release of online static resources to THE CDN.

Of course, in practice, the standardization and unification of multi-business scenarios is a difficult road, and there are many natural conditions that determine whether this road can go on smoothly. Especially, in the middle of the development of each business, how to smoothly promote the standardization and unification of each business has become a problem we must face.

There are some natural favorable conditions for the standardization and unification of all front-end businesses of smart enterprises:

Firstly, at the level of organizational structure, our organizational structure is divided into various business groups under the virtual large front-end group. Such organizational structure determines that our implementation can be carried out uniformly from top to bottom.

Secondly, in terms of technical architecture, most of our businesses are based on react framework at present, and the UI component library is uniformly developed by fish Design, so we have natural advantages in the unification of technology stack.

Finally, at the level of personnel awareness, team members have “empathy” for the pain points of the existing scheme, which is particularly evident when the development pain points are collected from all members in the early stage. Slow code packaging, cumbersome construction and configuration, and the inability to support new projects quickly are all the pain points that are widely mocked by everyone.

Therefore, internal drive + external force is the smooth implementation of standardization and unified weapon.

automation

The pain point highlighted by automation in the multi-business scenario of smart enterprises is the cumbersome construction and packaging configuration of each line of business, repetitive production, time-consuming and laborious, and some best practices cannot be easily shared. So we developed a unified automated build packaging tool. Only the design idea and general content framework will be introduced here. More details will not be covered in this article.

Design principles

In order to reduce unnecessary tedious configuration out of the box, and to integrate some common specifications into the tool as much as possible, our construction tool adopts the design principle of “convention over configuration”, and only provides necessary parameter configuration, not too many flexible parameter configuration. For example, we stipulate that, The front-end code to build must be placed in a directory named Web, and the compilation results will be output to the dist directory in your project root. Configuration is not recommended.

Design architecture

We hope that business development can only use this tool to complete most of the daily work, and also hope that some of our specifications can be really implemented through this tool, so we provide a series of CLI commands for each business call. In general, if the business organizes its code according to the recommended directory and uses the tools in a convention way, it can do business development with almost no configuration. Of course, we also provide the necessary configuration to meet the personalized needs of some special businesses.

Currently, our tools provide CLI commands such as build packaging, publishing (including static resource upload to CDN), local debugging, and initialization of new pages for business, and integrate automatic code checking into tools such as ESLint and Stylelint. At the same time, the directory specification is also integrated into the tool (page, Component and other directories are automatically generated when a page is initialized). Business developers only need little or no configuration, so they can use this tool to debug, build, package, publish and other processes, saving cumbersome Webpack configuration and improving development efficiency.

Application promotion

To make it more convenient for business developers, we also need to:

  • Document construction: Provides detailed usage documents, including background, purpose, design principles, and configuration details.
  • Continuous maintenance and upgrade: collect feedback from business development students, find problems and maintain and upgrade continuously.
  • Engineered integration: Integrating tools into the team’s scaffolding tools becomes the default solution for subsequent projects, and is completed during the project initialization phase.
  • Common usage problems: Update and maintain FAQs to help subsequent access users quickly find and solve problems.

conclusion

Front-end engineering is a systematic, exemplary and standardized process, which can improve the production efficiency in the stages of coding, testing and maintenance. It is a direction that we need to continue to learn and explore. However, the degree of front-end engineering can be large or small. The team needs to develop an engineering solution suitable for its own business according to its own business complexity, the status quo, pain points and input-output ratio, and the one suitable for itself is the best.

With the continuous development of smart enterprise business, we will continue to build and improve our engineering program, better enable more business. We will also continue to explore the industry’s cutting-edge technology, such as Webpack5, with advanced technology to better serve the business and customer services.