How to build gay infrastructure for small front-end teams?

preface

Why am I thinking about this? It all started with a speech:

Front-end gay | building hall master – how to push the front team infrastructure – zhihu

Above, the original is probably in April and May 2020 when see (was on language finches, but link failure, now on zhihu also find), the author introduced in detail in the speech to the team in more than a year of time how to constructed from zero to a large front infrastructure system, And how useful that infrastructure really is; After reading the whole speech, it suddenly dawned on me that the front-end could be so efficient and systematic. After reading it, I was really drooping over the front-end infrastructure that the team had, and then imagined that it would be a happy thing to work in such an efficient front-end system.

However, given that the large, mature front-end infrastructure described in this article is built on the accumulation of a large front-end team and a large number of front-end business scenarios, what about small teams?

So naturally I thought of that question, and I’ve been trying to find the answer to that question; After more than half a year of infrastructure practice within the team in 2020 (relatively primary), I think it is time to answer and sort out the thoughts on this question.

The realities of small teams

Considering the reality, after all, most front-end teams do not have as much team staffing as large factories, and most of them are still small teams. Small teams will inevitably encounter very realistic resistance when implementing infrastructure:

• The biggest obstacle is the small size of the team and the inability to focus on things that don’t directly affect the business
• Secondly, there should be insufficient understanding of the necessity and enthusiasm of infrastructure construction within the team (the idea of doing just enough).

The need for small team infrastructure

Based on the above practical problems, can we conclude that front-end infrastructure is the exclusive right and obligation of large companies/teams? After all, it looks a little difficult and thankless;

In my opinion, infrastructure is all the tools and methods that can improve coding efficiency, teamwork efficiency, and business robustness. As long as the project is still iterating and expanding, it will inevitably encounter new problems and efficiency bottlenecks, not to mention many business pain points within the project. The current approach to problem solving in many projects is to not solve problems until they arise (even when they are serious);

This is the core value of infrastructure: helping your business live well into the future. 1

I quite agree with the above statement. Infrastructure can not only improve the current efficiency, but also avoid some problems, so that the business can be better sustainable development.

What infrastructure should small teams build?

Given the need for infrastructure and the reality of small teams, my answer is:

• Priority: Give priority to areas with large input-output ratios
• Scope: Focus on business sediment and business needs
• Degree of automation: Do what one can. Do not pursue systematic automation front-end infrastructure owned by large teams at the beginning. “Automation of local R&D links” is recommended.

In the communication related to design tools, we also found that some teams began to incorporate the functions related to interaction, such as page skipping, back-end processing flow logic, visual editing, automatic generation of corresponding interface and flow code. This exploration can be summarized as “automation of local R&D links”. It is a very useful method for early improvement. We have found two useful suggestions in our external communication:

First, any team can and should do it. There is no need to feel that our team is not strong enough in RESEARCH and development, and wait for big companies to launch corresponding solutions. The key to partial automation is actually a summary and thinking of their own business and division of labor. In technology, when their business is relatively certain, through some simple methods can be achieved. And large companies to consider large and comprehensive, not necessarily suitable. In terms of personnel organization, almost all automation schemes have certain division of labor requirements, which also varies from organization to organization. Partial automation is a key prerequisite for the overall architecture change that follows. 2

Where the input and output are relatively large

• Normative document: PERSONALLY, I think the normative document should be the soul of the entire infrastructure, because the normative document can be regarded as the consensus of the whole team. In the absence of consensus, there will be a lot of incomprehension in the construction. And the formulation of corresponding specifications can refer to the common industry, and then discuss the internal details, it does not take too much time, but the benefits are absolutely great (effectively improve team collaboration consensus and efficiency);
• Business (generic) components: The front-end project naturally abstracts business components that can be reused as the business scales, which is also a business sediment; However, IN my opinion, the output process of components should be included in the infrastructure, standardized and processed, otherwise it is easy to cause problems such as low component reuse rate, poor scalability and high coupling.
• Tool functions: actually similar to business components, but components in the front end of the project to the view layer, and tool functions are the logical layer, similarly the output process of tool functions should be normalized;
• Code detection: this is actually the match code specification document is a kind of auxiliary means, because the mouth says, specification, after all, is not an entity of the nature of things may occur in the process of actual coding do not obey and forgotten code specification, if the lack of a compulsory means to test specification, the binding code related specification will sell at a discount greatly; In fact, there are various mature code detection tools in the community, which only need to modify the configuration according to the internal conventions.
• Scaffolding: when there is a high degree of similarity between the company’s business projects, the scaffolding can be used to standardize the project configuration before precipitation, complete the standardization of the project creation process, can meet the purpose of rapid project creation, and the project initialization work is significantly reduced, but also can reuse some of the precipitation project configuration;

Construction practice

Having said that, how do you implement front-end infrastructure in a project? Here is an example of my internal project practice:

• Project Background:APPCompanion useBusiness background; The early work is from the old project migration (reconstruction), later added a variety of new modules;
• Project features: Various modules, some of which have high function similarity and form complexity;

The figure above is an overview of some infrastructure-related practices I did in the project.

Common component output process

Render model /DSL

other

• Solve the multi-branch parallel development of several public file maintenance scheme | snowdream

Effect of infrastructure

• Team cooperation efficiency has been improved and standardization has been significantly enhanced
• Through the accumulation and precipitation of early components/common, the subsequent development speed is significantly improved (building block development)
• Code reuse rate significantly improved, reduce copy and paste times

The latter

There is much to be gained from trying infrastructure

After actively practicing/promoting infrastructure in the project, I realized that there are many things I can gain from trying infrastructure:

• You will have a deeper, more fundamental understanding of the front-end project as a whole and be able to identify more business and coding pain points
• Can expand more ideas to improve efficiency, access to more efficient coding systems and tools
• You can strengthen the global concept, recognize the specific application scenarios of various architectures and solutions, and then try to propose architectures and solutions that are more suitable for specific business scenarios

In short, actively experimenting with infrastructure not only improves immediate projects, but also improves your problem-solving skills; In the practice of less than a year, a variety of solutions have emerged in my mind, some have been applied, and more are still being explored and tested. In short, I have gained a lot of inspiration:

• A feasible by the skeleton of the whole railway network screen generation scheme | snowdream

There is no end to infrastructure

I personally feel that there is no end to infrastructure as long as the project is developing/iterating; This point is the same from the practice of Dachang, dachang are step by step from visual construction (semi-automation) to intelligent construction (full automation) exploration road;

The related documents

• Front-end gay | building hall Lord – how to push the front team finch: infrastructure, language has failed
• Front-end DSL Practice Guide (PART 1) – Internal DSL – Zhihu
• How to improve technology from Business Code: Using Domain Specific Languages to eliminate duplicate code – Do you know
• Front-end gay built | how Scott – when people stretch thin project to promote infrastructure finches, language