The front end early chat conference, the new starting point of the front end growth, held jointly with the Nuggets. Add wechat CodingDreamer into the exclusive inner push group, win in the new starting line.

The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :

  • Team set up 3 years | small Jue landing – how to promote infrastructure projects
  • Team set up 4 years | hall master – how to push the front team infrastructure
  • Team was founded five years | how Scott – when people stretch thin project to promote infrastructure
  • Team was founded six years | taro – how to implement infrastructure value breakthrough in big front team
  • Team set up 12 years | chung chi – how to design large front team construction route

This article is the text version of the lecture of the second lecturer. Listen to his views. The video and PPT will be posted on the public account in the future.

The text start

One, foreword

This article is based on the “front-end infrastructure” special session of “the second Front-end Early Talk Conference” on February 29, 2020.02.29.

This article is in line with the requirement that all the sharing of the conference starts with “how”. It is also a sediment summary of how the team I am responsible for in the construction of front-end technology infrastructure from 0 to 1 in the recent year.

And thanks a lot to @Scott, the organizers, the participants, and the topic of this episode. The industry has not shared much about the front-end system infrastructure construction. I hope these words from personal perspective can bring some inspiration to some students and make some changes.

In a broad sense, technical architecture, technical construction, etc., is a true subset of the r&d team’s infrastructure. In addition to these, the team’s infrastructure includes other aspects such as system, process, culture, echelon, training, etc. In this sharing, we are focused on the narrow sense of “technology infrastructure construction”, in addition to soft capabilities, please refer to @church in the first front end early Talk conference share “How to influence and promote the growth of the front end Team”.

Second, the introduction

1. Who am I?

The head of the school, whose real name is Chong Ma, started his work in 2006. He changed his major in university, took a leave of absence and failed to start his own business. In 2011 before graduation, I worked as an intern in the front end team of Taobao for a whole year. After graduation in 2012, I joined Taobao (flower name @Tangzhu). In 2016, I joined Mogujie (flower name @Mingchun in mogujie period) and worked as a front end TL in Mogujie for 2 years. From August 2018 to now, I was in charge of the front-end team work of political cloud adoption (the flower name was changed back to @landlord).

2. Our team

Zheng CAI cloud front end team currently has more than 50 people, the average age is less than 28 years old, no problem youth army. The team name is ZooTeam and the team site is zoo.team. Z is the first letter of Zhengcai Yun pinyin, OO is infinite symbol (∞), combined with Zoo has the meaning of biosphere, I hope the subsequent zhengcai Yun front end team, whether it is talent echelon, or technical system, can have all aspects, and gradually grow into an ecology.

3. How can I be contacted?

The following is my WECHAT QR code. If you want to have further communication, please scan and add my wechat.

Iii. How to understand “Technology infrastructure”

1. What is infrastructure?

  • “Technical infrastructure” refers to the construction of technical infrastructure of the R&D team, and is the precipitation of a team’s general technical capabilities.

2. Students’ confusion

Most of this share will be centered around this, but before we get there, let’s take a look at some of the puzzles (the same thing I mentioned in the first early Talk session last month) :





All three of these questions are very interestingtypicalityAnd they’re not imaginary, they all come from the anonymous community. You can see that there is a lack of understanding between “doing business” and “doing architecture,” as well as questions about the ability rating — how much knowledge and skills are needed to get a higher rating. As for the latter question, he wrote a long article titled “The Interviewer’s Perspective on the Job: What’s the problem?” To make a personal point, divided intoon,Under theTwo, can click the link to view. As for the difference and understanding between “business” and “architecture” (or as I would say today, infrastructure), I would like to say:

The value of technology lies in solving business problems“Business support” and “infrastructure” are always two sides of the same thing, and that “same thing” is helping the business solve problems. Any infrastructure initiative that is divorced from addressing real scenarios needs to be revisited and should not even be encouraged.

3. Significance of infrastructure

From business problems to solving practical problems, infrastructure construction has the following significance:

  • Problem solving: Help solve business problems.
  • Team training: The virtual team undertaking the construction can provide students with different dimensions of training scenes during the construction process, and can provide space for practice and growth in the identification of business problems and scenes, scheme design, new technology practice, project management and product-oriented thinking, and play the role of training soldiers.
  • Echelon building: A virtual building team is also a team in essence. In the process, different roles can be exercised and investigated, which is conducive to the improvement of the team echelon.
  • Influence building: the results of the construction can promote the business and be more easily recognized by internal partners; The accumulated good experience can be exported and shared, which is also a powerful help to influence.

Iv. What is infrastructure

1. Why do gay builders?

  • For a research and development team, if it has been using brute force to support the business by squeezing and working overtime, the team will be very dangerous and the business will be dangerous.
  • You can’t grow by leaps and leaps in a brute force model — you can’t expect your R&D team to grow 10 times as much as your business volume. Costs can get out of hand.
  • Sometimes it is inevitable to be busy and work overtime for a period of time. For example, the Double 11 promotion of e-commerce, or the delivery of big projects customized by toB business, the time point is inverted, and punctual performance has a heavy impact on the results. Overtime should be, not overtime should also be, only can not finish the work should not be. When that time passes, the team must think, how can we be more effective?
  • Looking at the future, if in one year or two years, the business volume will grow by N times, how should we support it at that time? Can the current way meet the needs of the future? It is impossible to rely on the pile of people, can only rely on technical construction to improve efficiency and reduce costs. That’s what infrastructure is all about: helping businesses live into the future.

2. What should we do with infrastructure?

  • First of all, we should say that the content of the infrastructure is inseparable from the precipitation of the existing construction of the business phase team.
  • The more the team is in the initial stage, the more the construction of the team tends to focus on the basic technical benefits, such as scaffolding, component library, package deployment tools, etc.
  • The more mature the business and the mature precipitated team are, the more the construction will be inclined to obtain more business benefits, such as the system that directly serves the business, and the technical efficiency improvement can bring more direct business benefits.
  • Most of the research and development teams in the industry, are not Ali, Tencent, tiaotiao such a complete foundation of precipitation rich situation, the starting period and fast climbing period, the construction lag. In terms of infrastructure, there may be little more than a webpack-based scaffolding and a third party open source UI component library that encapsulates your own business component library. If that’s exactly what I’m talking about, don’t worry. When I first came here a year and a half ago, it was the same at the front end. In the following more than a year, we have preliminarily built and put in place a series of infrastructure, which has received good feedback.

3. What is the infrastructure R&D process?

Looking back at the beginning, to determine the construction strategy and steps, mainly from the dismantling of the RESEARCH and development process:

As the figure above shows, a basic r&d process is closed loop, Generally, requirement import => requirement disassembly => technical solution development => local coding => joint debugging => self-test optimization => test and Bug repair => packaging => deployment => data collection & analysis review => iterative optimization — a new round of requirement import. In this basic closed loop, each node has its further internal links, and each link is connected to form a research and development cycle. When the cycle goes well, the r&d process goes well. The fewer choke points at each stage of the cycle, the more efficient the r&d will be. The initial infrastructure is to start from these r&d delay choke points, according to the universal + high-frequency priority standard, one by one breakthrough.



Improve efficiency, experience and stability, is the most important goal to be solved by the infrastructure. The general formula is standardization + standardization + instrumentalization + automation. After the capability is complete, it can be further promoted to platformization + productization. In terms of direction, our team categorizes and builds from the following eight main directions for your reference:

  • Development specifications: This is where the team’s consensus on standardization is settled, and standardization is a prerequisite for effective teamwork.
  • Research and development process: standardized process directly affects the division of labor and efficiency of upstream and downstream cooperation, and excellent process can bring more professional collaboration.
  • Basic assets: In our team, the asset system includes the tool chain, the team standard DSL, and the material library (components, blocks, templates, etc.).
  • Project management: low cost management for the whole life cycle of applications, from application creation to local environment configuration to low code construction to package deployment.
  • Performance experience: An automated tool to find performance bottlenecks and provide optimization suggestions.
  • Security prevention and control: The three-party package relies on security, code compliance inspection, security risk detection and other prevention and control mechanisms.
  • Statistical monitoring: burial plan, data collection, data analysis, online abnormal monitoring, etc.
  • Quality assurance: Self-test CheckList, single test, UI automated test, link automated test, etc.

These are the main directions and partitions of general front-end infrastructure, whether PC or mobile, where the foundation is built. The difference between the phases of the business and the capabilities of the team, reflected in the infrastructure, lies in the integrity, granularity, depth of the output and the reach of the automation.

V. How to build infrastructure

In the following, some cases of front-end infrastructure products will be listed for your reference based on some of the directions that everyone is interested in and the construction output of our team in the past year.

1. Specification & Documentation (Docs)

  • Why regulate?

The standard is the most should first, the first emperor first unified the six countries, that is, “the book with the text, the car with the track”, the standard means the standard, is the consensus of the team, is the basis of communication and cooperation.

  • Why documentation?

Documentation, one of the most overlooked things, includes valid comments between lines, in addition to clearly important technical documentation and business stability. Think about how much time you spend figuring out the logic of someone else’s code, or how many questions you have to ask to figure out what’s going on in those warehouses in front of you when you just took over a business, or how many failures you have because you don’t know where your predecessor left you.

  • Teams develop normative principles

For the formulation of norms, it should be emphasized that the output of norms should be the consensus of most students in the team, and should be the collective aesthetic. Once a specification is established, it should be strictly implemented to form a consistent team behavior.

  • What is a valid document?

For documentation, writing for the sake of writing is garbage, better not to write at all. The focus of the document is to speak, is effective, is intuitive, save trouble, not around. Think of a UI component library document that shows you an interactive Demo and then provides the API information, or a list of API text at the beginning. Which is better and cheaper for the reader?

2. Local Engineering Environment (CLI)

  • The meaning of the CLI

Local development environment, it is believed that any team will do the standard configuration, save trouble may directly embrace the framework selection of the corresponding family bucket, such as Vue family bucket, or use Webpack a scaffolding. More powerful ones will also provide plugins such as Lint or Mock for scaffolding. From the simple of a local scaffold to the complex of an engineered kit system, the aim is to dehumanize and automate the local development process.

  • Talk about how do we do CLI?

Our team’s local development environment infrastructure is an engineering kit environment. The core concept is to try to “do everything in one step” and make the configuration and use of the local environment as stupid as possible. For example, the local initialization of an application environment, starting from the CLI command line operation (in fact, the policy cloud front-end team is now fully GUI), a zoo init command can do all the local environment setup, this is all after the terminal execute the press enter, Everything from repository local directory generation to automated installation of NPM dependencies to scaffolding plug-in initialization to invoking a browser window is done automatically. Yes, even NPM install and dev what all do not need to execute, can save a step operation to save a step, the King of Chu very small waist, less is sexy.

CLI Local Engineering Suite architecture diagram:

3. Visual Engineering System (GUI)

In fact, at present, the daily research and development of the team has been basically separated from CLI operation, and unified to the desktop client platform “Dunhuang” developed by the team. Based on the capabilities of the client, it can aggregate the dispersed engineering capabilities, and form the series capability of the link, combined with the intuitive and simple operation of the GUI, further save trouble. Through the desktop client, you can aggregate daily operations on the front-end development link, from component development to template development to application development. From arousing the editor to launching the debug environment, making package updates, to packaging deployment releases. At the same time, the desktop system can also be integrated with other research and development systems, forming more capabilities.

4. Component development and management

In general, the front end team will improve their component library architecture. In some cases, some UI component libraries may use community open source excellent third-party libraries, such as ANTD, but there will be more or less their own business component libraries that need to be encapsulated. The value of the tool is to smooth out differences and make the underlying criteria consistent. For component development, the CLI toolchain described earlier is the underlying dependency here, as is template development and usage, and application development described later. Through the tool to develop and manage components, we can better realize the standardization of component naming, standardization of version, convenience of finding, simplification of development process, and other necessary statistics of component application scenario statistics and version coverage, which are related to the updating cost of components in access scenarios.

5. Template development and management

Similar to Flyice, we have also developed a similar set of templating capabilities to facilitate the rapid development of middle and back office business scenarios. Because the business scenarios in the middle and background are relatively fixed, such as forms and lists, the template-based approach can save a large part of the cost of making Demo and realizing interaction. The premise of the template is that the UI component library is complete, and the background interaction and visual design are standard. Based on this, the standardized service template library is precipitation. Select the appropriate template according to the scenario, configure the page information and path, and then install the template locally with one click, automate the configuration of routes, and install dependencies.

6. Project creation and management

In the creation and management of the project, from the very beginning, our goal is to “decouple and Hold the whole process by one person” — that is, in the creation of the project, the construction of the local environment (including the upgrade of the environment), branch management, construction, deployment and other links, students at the front end can completely handle by one person. Do not need to ask for help to build the warehouse because of the permission problem; There is no need to learn new ones each time because of inconsistent standards for components, blocks, templates, application (SPA/MPA), and selection (React/Vue) in the local development environment; You don’t have to worry about having to ask questions about different versions of different business processes; No need to configure the packaging script; You don’t need someone (or operations) to help you with every deployment… In short, we wanted to use tools to smooth out too many asymmetries in our daily lives and bring developers’ focus back to as simple and pure coding as possible. Even a newcomer on campus who does not understand Git, command line and application management process can start coding happily with the help of the desktop visualization project system.

7. Front-end underlying assets

We mentioned the front-end team specification (standardization), the tool chain (CLI), the visual assistance client (GUI) on top of the tool chain, mentioned components (modules), templates, applications. The abstractions of tools and the reusable abstractions of the business are the fundamental assets of a team. Simplified to Webpack a scaffolding + a set of open source tripartite UI component library, the rest of the assembly production depends on human flesh; Complex such as Ali department is breaking through THE UI2Code, editor and other capabilities, standards, process more automation, further human flesh. In terms of basic assets, our team’s construction in the current business phase is as follows:

8. Automate CI/CD construction and deployment

The front end has its own build deployment system for better process control in terms of specialization. In the second half of 2019, the zhengcai Cloud front-end team built its own construction and deployment system, and realized cloud packaging, cloud detection and automatic deployment (through the deployment system of operation and maintenance). At the beginning of the design of the new independent system, the focus is to achieve a Flow mechanism, in order to achieve code compliance static detection capability. This part finally realizes a set of plug-in mechanism in the system, which can configure different detection items as required. For example, if a detection item fails to pass the detection, it will eventually block the release process. These detection items include:

  • Lint detection
  • Compatibility API testing
  • HTTPS detection
  • Package detection (Blacklist, package version)
  • Validity detection (domain, link)
  • 404 test
  • Basic UI checks (e.g. missing ceiling)
  • .

9. Visually build the system

The visual construction system is a superstructure for further efficient use of components. The page is composed of components (business modules). The system is built, and the assembly of the components is operated by local people and productized into visual jigsaw puzzle in the system. The page construction, data configuration, construction and deployment, data burial point and so on are productized and enabled to product and operation partners. Front-end output components, operation and construction pages, can not only save the front-end human efficiency, but also enable the front-end expansion of operational capabilities, further release operational business capabilities in marketing scenarios, and achieve win-win results.

For more on visual build systems, check out our team’s previous post: Visual Build Systems for Front-end Engineering Practices.

System Architecture diagram:

Deployment flowchart:

10. Data burial and analysis

In many companies, data burial and analysis are often the work of the BI department. In Zhengcai Cloud, due to the company’s relatively insufficient BI capability in the early stage, the front end team first initiated and promoted the whole system construction related to business-oriented Web data burial point collection, data analysis and visualization. Before and after the implementation of the buried point specification, buried point SDK, data collection and analysis, PV/UV, link analysis, transformation analysis, user portrait, visual heat map, pit granularity data penetration and other data capabilities.

For more information about data burial and analysis, check out our team’s previous post, “Data burial Analysis System for Front-end Engineering Practices”.

11. Automated page performance analysis

Page performance, 90% on the front end. Especially like our company at the current stage of toB mainly business, different from my old employer (Taobao, Mushrooms street) has been absolutely dominated by mobile terminal, we are still PC scene accounted for the majority, in the page performance is still more prominent. The past 1 year time, reference path is for everyone, we launched the first figure size optimization, to account for the bulk of bulk volume, number of requests page image optimization strategy, first USES the specification + tools to help business fast realization of figure size optimization, relevant to precipitate visible earlier this team the system under the comb again for you, Web experience optimization is all about diagrams. Afterwards, we gradually based on Node ability to tease out the influence of page, the performance of automated testing capabilities, and according to distinguish between different business scenario testing model, and then did a timed tasks to achieve performance of coherence analysis and data movement ability, then the market and increase the business performance data and red HeiBang weekly. For more details on the automated page performance analysis system, read our team’s earlier articles, “The Puppeteer Crawler Practice for Automated Web Performance Analysis” and “Automated Web Performance Optimization Analysis Solutions.”

12. 2019 Infrastructure Milestones

Part of the technical infrastructure construction of the front-end team of Zhengcai Cloud introduced above is basically built and landed gradually within one year of 2019 and achieved results. The following figure shows the construction milestones in the previous year’s cycle, showing the corresponding construction cycle and pace. In my team, there is no independent front-end architecture group. The teams under the front-end are all business teams. Our students precipitate problems from business support, think and collect them, and promote corresponding construction based on business problems.

For R & D students, the value depends on the ability to solve problems, on whether they have solutions to different business problems. Our team is very lucky that the business is in a period of rapid development, with many problems and few existing precipitation. We are very lucky to be able to help the business solve problems and follow the rapid development of the business, almost from scratch. This is a valuable and rare experience, because most companies are either not big enough to do this, or they are too old to see the whole system develop. Companies need to create an environment for their employees, but ultimately the growth of employees depends on their own. Therefore, students all agree that it is a valuable opportunity for them to participate in construction and even lead a direction in their spare time.

Six, infrastructure

1. Every construction, there must be data

All construction, there must be corresponding data collection and analysis, data to explain the changes brought by infrastructure, explain the input-output ratio. The design of data indicators needs to be designed and collected in the early stage of a special construction, and continuously collected throughout the promotion cycle and after landing, so that a relatively complete change curve can be obtained to testify the effectiveness of the work. The data doesn’t have to be completely accurate, but it has to show trends, be intuitive, and give accurate feedback.

2. Start with the scenario

In terms of manpower, manpower is absent in any case. But in many cases, our construction cannot be pushed forward, not because of manpower problems, but because of lack of clear thinking. There is a fable in The Biography of Zhuangzi · Leco that “Zhu Ping learned to slay a dragon in a fragmented and profitable way. It’s about a man who spends all his money to learn the skill of slaying dragons, but finds that there is no dragon in the world. For r & D students, there will also be the problem of looking for scenarios based on solutions. For example, if you want to learn Node and don’t know how to learn, you will learn from the examples in the book, but eventually you will find that the effect is very bad. No writer is born from fiction, no linguist is born from a dictionary, and no technologist is born from technical books. Learning by doing is always the fastest way. The valuable thing always starts from the business itself. The problem is the opportunity, the problem is the turnip pit.

3. Expand the boundaries of our capabilities without setting limits

The current situation that the front-end has a low voice in the R&D system has existed from the moment the front-end function appeared. Some R&D teams are not excluded. Due to their business model, they have a deep dependence on the front end, and the voice of the front end is relatively high. In most R&D teams, the front-end work, in the eyes of other r&d, is often “low technology content”, “very thin layer” and so on. Behind this situation, take a look at the following picture:

Horizontal, vertical, two dimensions. The “vertical” on the right, referring to the hierarchical system of network application system, the traditional work category of the front end, are concentrated in the “user interface layer”, rarely can go deep, deep into the gateway ~ infrastructure layer. The back end is different. From this perspective, the front end is indeed “thin”. Now on the positive side, Node capabilities provide the front-end with server-side capabilities that penetrate down. Some teams are also leveraging Node to scale out their engineering capabilities and extend their front-end systematization capabilities deeper into the business.

Let’s look at the horizontal on the left. Only a few front-end teams can build and develop the technical system more perfectly. For the front-end team with a relatively complete system, its technical system is more limited to the functional category of the front-end. It fails to penetrate into the business side with better interaction, and it is more self-satisfaction. The business perception is very weak. Transform engineering benefits brought by technology into business benefits; Translate technical impact into business impact within the department; Upgrade the technical scenario to the service scenario; Turn the team’s basic capabilities into business capabilities. Getting out of the front end, around and deep into the business, is something that everyone who is pushing the team system should think more about.

4. Phase matching of services

The content of the infrastructure is matched with the business phase. Different teams serve different phases of the business, and the content and breadth of the infrastructure will vary. It’s not how much you have, it’s how much you understand and support the business. Never sharpen an iron bar when all you need is a needle.

5. The value of technology lies in solving business problems

The value of technology lies in solving business problems; The value of a man lies in his ability to solve problems. But to solve the problem, the technology infrastructure is not a silver bullet, even in my opinion, is not in the top three.

Seven, finally

1. Ask yourself: What would be different because of you?

2. Get in the bowl, we’re hiring!!

For the latest recruitment information of the team, please scan the qr code below to follow the wechat official account of “Zhengcai Cloud Front-end Team”.

Resume recommendation, please send to [email protected]

The third phase of 2020.3.28 live online, the theme of “front-end construction”, scan the code to pay attention to the “front-end early chat” public number to participate in the registration: