preface

I’ve been reading some books and blogs about front-end architecture lately, and I feel a bit self-inflated and want to point the finger at front-end architecture. From the beginning of my career, I have always felt that architects are the people at the top of the technology pyramid, the people who guide the technology direction of the industry or the team. However, from the definition of front-end architecture in the industry and the necessary skills, feel that front-end architecture is a fake concept, or to promote their identity.

Analogy to building a house, considering the cultural factors, there will be Chinese and Western style; Given the geography, there will be north and south; Considering simple and convenient, there will be combined container houses. Designers will use their expertise and combine various factors to create a house that fits the current environment. The same is true for architects, who need to construct a sound organizational structure from business, technical, and other perspectives. Front-end technology continues to evolve, from the exploration of modularization, to the practice of MV*, and now the prevalence of componentization. These technologists are constantly tweaking the front-end architecture to make it more relevant to The Times. Under the screening of the market, the most suitable front-end technology solution was finally left. However, most front-end architects do not have this capability and are at best experienced contractors, practitioners of some kind of front-end technology solution.

How designers do it, we don’t know. But by analogy with a contractor, we still know what a front-end Leader should do.

Preliminary preparation before commencement

Pre-preparation here refers to the preparatory work we need to do to start a project from scratch. Most of the technical content of the project is estimated to be here. As a contractor, it’s not about how well I can lay bricks, it’s about knowing the resources and workflows that are out there and putting in place the infrastructure to get a head start on future projects.

In the early days of data and view coupling, there was nothing on the front end, and it served as a template for the back end, or drawing static pages for presentation. With the rise of Ajax, the relationship between data and view began to loosen, and the front end ushered in a big development with the power of data. If people want to interact with data, they must use a certain media, and the front end promotes the interaction between people and data after obtaining the rights of some data. Even the latter Node, I think, is an effort by the front end to gain access to the data. After all, data is king these days.

How does the view get its data? How does a view present data? How does the view get the data better? How do views better represent data? (… Not that much…)

Architecture design

From the early server-side straight out to the current server-side rendering, view rendering seems to have come full circle back to where it started. But one is not the other. With the adoption of Ajax by Google came the separation of the front and back ends. Front-end applications also follow The Times and present different architectural designs, such as multi-page applications, single-page applications, isomorphic rendering, micro-front-end and so on. They were created as a technical solution to some problem, so they are still valuable even if they are outdated.

Multi-page applications are relatively simple. Simple multi-page applications, such as static pages, may not have JS at all. Complex multi-page applications may need to introduce template engines, routing, etc. If natively manipulating the DOM is inconvenient, you can use jQuery instead. Multiple pages should load the required resources when the project starts, and because of browser caching policies, a second load of the same resources may not require a repeat request. Combined with a bit of MV* mode, kuai is no different from a single page app. However, the popular single page does not need to manipulate the DOM directly, but is handled by the framework layer.

The above applications may all be the same. In some scenarios, multiple front-end applications need to be aggregated, such as routing distribution schemes and iframe container schemes.

The front-end specification

“Book with text, train with track”

Since it is a contractor, nature is unlikely to be a smooth commander. The formulation of norms, not only can make the member code style tends to be unified, but also can make novice develop good coding habits. For the front end, HTML, CSS and JS represent the structural layer, the presentation layer and the behavior layer respectively. At the code level, they all have their own set of standards that can be easily standardized with their respective Lint tool + Prettier. From the perspective of component specification, it also includes UI component specification, modular specification, project component design scheme and so on.

Editors should also be unified, and if they can find a set of ways to use them more efficiently, then they should be synchronized to the entire group.

Automated build

By 9102, automated construction has become an integral part of modern front-end engineering. Automated builds can do many things, such as file compilation, resource consolidation, compression optimization, and so on. There are a lot of building tools, but the things we do are basically the same: read import configuration file ‘make module dependency plan’ load module file ‘compile’ process ➡️ module file ‘merge ➡️ file resource optimization’ export final resources.

Build tools need to be involved in both production and development environments. Production environments focus on performance, such as file compression optimization, removal of unwanted code comments, and so on. The test environment focuses on the development experience, such as module hot replacement, generating sourcemap, etc. Like the previous code specification, build tools can also automate the formatting of code or prompt errors.

Project code Examples

Before a project can be launched, it needs to verify that the program is performing as expected. Once you verify that it works, write sample code that follows your own set of specifications to help other members understand the project’s specifications. At the same time, the internal organization of technical training, introduce the system architecture and matters needing attention.

In fact, the process of technical verification should not be part of the overall development process. In our spare time, we can learn more about new technologies and try out new architectural designs. In uncharted territory, we could not accurately assess the time, and temporary sharpening of the gun could lead to the delay of the entire project.

starts

Technology is for the business, and when the project starts, it’s time to pay back the business debt. The responsibilities of the front-end Leader also begin to change. They are not only engaged in technical activities, but also participate in non-technical activities such as team management and project management. Once the project was on track, everyone became a screwworker, and technical problems were rarely encountered. But that doesn’t mean the whole development process will be smooth sailing.

Communication and coordination

“Everything has an answer, everything has an answer, everything has an echo.”

Both ordinary members and team leaders should have such a working style and have an account for themselves and others.

The front end is a more awkward existence in the whole research and development team. This is especially true in business focused teams, where bad things keep coming. For example, with a page throw exception, the test partner looks to the front end first. Product partner unreliable, frequently looking for the front end. Encounter unreliable back-end partners, joint testing will also run to question the front end. You might end up with a boss who talks to you about how your front end team keeps having problems. Honestly, I can’t answer that. It feels that the front end is like a pot catcher. Over time, it has a great impact on team morale, which is also a problem that the front end Leader needs to solve.

For products, requirements review rigorously checks and delays or reduces priority for unreasonable or non-urgent requirements. For testing partners, technical training, understanding the simple use of developer tools, and common error analysis popular science. For the back end, specify constraints. The above specifications to form a document to save, convenient later.

Of course, there will be a lot of such problems. We should be sensitive to the problems and find them in time, analyze the root causes of the problems, and finally solve the problems step by step with appropriate medicine. It’s a simple thing to say, but in fact, people get used to the fact that there’s a problem and they don’t know or see the problem but they get used to the problem.

Improve team capability

When everyone adds wood, the flame is high. Only when everyone works together, can we produce the effect of 1 + 1 > 2. But coding is not hard work, members of the uneven, a great extent will drag the team back. For example, a novice’s code submission is not standard, which is likely to cause some people to howl.

Code review is a great opportunity to improve your coding skills. Previous Lint rules can be used to fine tune code style, while code reviews can find logical problems or learn ways to make code look better.

Refactoring can be a great way to improve your programming skills, but many people have a big misconception about refactoring and don’t necessarily see it as a priority in a project. Refactoring can make your program more readable and maintainable by taking small steps. When to refactor? What are the criteria for refactoring? If your program is too long to read, refactor it. If a program relies too much on comments, refactor it. If you want to add new features but can’t, refactor it. If it’s not readable, if it’s not maintainable, you have a reason to refactor it.

Another benefit of code review is that it helps familiarize us with the business. If the project business is complex, make sure at least two people have sufficient knowledge of the same module.

New employee training and technology sharing. When new employees just join the project, it is necessary to provide them with basic technical training, such as business training, technology stack related knowledge training, debugging ability training, etc., all of which should be provided with relevant documents. These seemingly insignificant training, for the novice, is often a big help.

Technology sharing is not expected to make all members learn a skill in a simple sharing, but it will greatly help the team’s technical vision and technical atmosphere. For those who share technology, there are different opinions. Some people advocate that the new person hosts the sharing, which can speed up the new person’s integration into the team, and the old person can also supplement the explanation. Some people, on the other hand, think let the people who are best at it do what they are best at. Don’t know which is better, no comment.

In my opinion, team capability should also include survivability, that is, even if there is a high turnover of members, new members can be quickly connected to the project. This requires documentation, orientation documentation, technical architecture documentation, business documentation, technical sharing documentation, development specification documentation, work transition documentation, etc.

Front and rear end intermodulation

The back end is deployed from the local development environment to the test environment, and at a normal pace, the front and back end tuning should go smoothly. However, in actual development, the proportion of joint adjustment will be very large. The main reasons are,

  1. The communication efficiency of the front and back ends is low.
  2. The back – end self-test strength is not enough, not comprehensive consideration.
  3. The interface protocol changes frequently.
  4. The interface documentation is incomplete. .

The simplest and crude way is to introduce interface management platform and performance appraisal system.

Sustained integration sustained delivery Sustained deployment

This part is not the front end of their own can decide things, if conditions can build their own code hosting platform, using GitLab, now they provide a dragon service, you can try a wave.

conclusion

It’s not scary to deal with code, it’s not scary to deal with people, it’s scary that the front end Leader has an idea.