This is 42 not original mix into water, want to get more original piece, please sweep over 👆 qr code attention we ~ in this paper, starting from the front early public chat number: front end early chat | hall master – how to promote infrastructure construction of front-end team

One, foreword

This article is based on the “front-end infrastructure” special session of the 2nd “Front-end Early Chat” on February 29, 2020.02.29. The title of this paper is “How to Promote the Construction of front-end Team Infrastructure”. Firstly, it is in line with the requirement that all sharing of the conference should start with “how”, and at the same time, it is a summary of how the team I am in charge of has gone from 0 to 1 in the construction of front-end technical infrastructure in the last year.

Thank you very much @Scott, to the organizers and participants, and to this topic. There are not many sharing outputs about front-end systematic infrastructure construction in the industry. I hope that these words from personal perspective can bring some students some start and make some changes.

In a broad sense, technical architecture and technical construction are a true subset of r&d team infrastructure construction. Besides these, team infrastructure also includes other aspects such as system, process, culture, echelon, training and so on. In this sharing, we are oriented to the narrow sense of “technical infrastructure construction”, in addition to soft ability, please refer to “How to influence and promote the growth of front-end team” shared by @Tang Zhu in the first Conference of Front-end Early Chat.

Second, the introduction

The founder, whose real name is Ma Chong, has been doing pioneering work since 2006. During college, she changed departments, took a break from school and failed to start her 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 @ Tang Leader). In 2016, he joined Mogujie (flower name @ Mingchun during mogujie period) and worked as a front-end TL for Mogujie for 2 years. August 2018 ~ now, in charge of the front-end team work of Zhengcaiyun (the flower name was changed back to @ Tang Master).

The front end team of zhengcai Cloud currently has more than 50 people, with an average age of less than 28 years old. The team name is ZooTeam and the team site is zoo.team. Z is the initials of Zhengcaiyun pinyin, oo is the symbol of infinity (♾), and Zoo has the meaning of biosphere. It is hoped that the subsequent front-end team of Zhengcaiyun, whether it is the talent team or the technical system, can be equipped with all aspects and gradually grow into an ecology.

Below is my WECHAT QR code. If you want to communicate with me further, please scan it and add it to my wechat.

Iii. How to understand “Technology Infrastructure”

“Technical infrastructure” is the technical infrastructure construction of the R&D team, which is the precipitation of a team’s common technical capacity. Most of the content of this share will be centered around this center, but before we do, let’s take a look at some of the questions that some students have (the same questions I mentioned in the first early Talk conference share last month) :

The above three questions are typical, not imaginary, and all stem from the anonymous community of the pulse. You can see that there is confusion about “doing business” and “doing architecture”, and there is also the question of ability rating — how much knowledge and skills are needed to get a higher rating. As for the latter question, Don wrote a long article titled “The Interviewer’s Perspective: What’s the problem?” To elaborate personal views, divided into the first and the next two, you can click the link to view. What I want to say about the difference and understanding between “business” and “architecture” (or, as I call it today, infrastructure) is:

The value of technology is to solve business problems, and “business support” and “infrastructure” have always been two sides of the same thing, which is to help the business solve problems. Any infrastructure launched outside of a real-world scenario needs to be reconsidered and should not even be encouraged.

Infrastructure initiatives arise from business problems and are not just about helping business solve problems. The virtual team in charge of the construction can provide students with different dimensions of training scenarios during the construction process. It can provide space for practice and growth in the identification of business problems and scenarios, scheme design, new technology practice, project management and product thinking, and play a role of training soldiers. At the same time, a virtual construction team is also a team in nature. During the process, different roles can be exercised and inspected, which is conducive to the improvement of the team echelon. The promotion of the construction results to the business is easier to gain the recognition of internal partners; The accumulated good experience can be exported and shared, which is also a powerful help to influence.

What about infrastructure

For a research and development team, if all the time by squeezing, pure overtime such as brute force to support the business, the team will be very dangerous, the business will be dangerous. You can’t grow your business by leaps and bounds — you can’t expect your r&d team to grow 10 times as much as your business. Costs will get out of control. Sometimes, periodical busyness and overtime work are inevitable, such as the double 11 promotion of e-commerce, or the delivery of major customized projects of toB business. The time points are inverted, and punctuality and performance have a great impact on the results. Overtime is supposed, no overtime is also supposed, only can’t finish the work is not supposed. When this time passes, the team must think about how it can be more efficient. Standing in the future today, if one year or two years later, the business volume increases by N times, then how to support, the current way can meet? We can only rely on technology construction to improve efficiency and reduce cost, which is the core value of infrastructure: to help businesses live better in the future.

What about the infrastructure? First of all, we should say that the content of infrastructure is inseparable from the business stage and the existing construction precipitation of the team. The more early-stage teams are, the more they tend to focus on basic technical benefits, such as scaffolding, component libraries, packaged deployment tools, etc. The more mature the business and the more mature the team, the more inclined its construction will be to obtain more business benefits. For example, the system that directly serves the business can bring more business benefits directly while improving the technology efficiency.

Most r & D teams in the industry are not such as Alibaba, Tencent and Toutiao with complete foundation and abundant precipitation. Most of them are in the initial stage and fast climbing stage, and their construction lags behind. In terms of infrastructure, there may be only a webpack-based scaffolding, and a third-party open source UI component library to encapsulate their own business component library, and nothing else. If the situation is exactly what I said, don’t worry, I just came to the political cloud a year and a half ago, when the front of the same situation. In the following more than a year, we have initially built and implemented a series of infrastructure and received good feedback. Looking back at the beginning, the strategy and steps to determine the construction were mainly started from dismantling the R&D process:

As shown in the figure above, a basic R&D process is closed loop, which is generally requirements import – requirements disassemble – technical scheme formulation – local coding – joint commissioning – self-test optimization – test Bug repair – packaging – deployment – data collection & analysis review – iterative optimization – that is, a new round of requirements import.

In this basic closed loop, each node has its own further internal links, and each link is connected to form an r&d cycle. This cycle is smooth, the research and development process is smooth. The fewer choke points there are in each part of the cycle, the more efficient r&d will be. The initial infrastructure is to start from these blocking points that delay r&d time and make breakthroughs one by one according to the priority standard of universality + high frequency.

Efficiency improvement, experience and stability are the most important goals for infrastructure construction. The common formula is standardization + standardization + tool-based + automation. After complete capability, it can be further promoted to platform + product. In terms of direction, our team classifies and builds from the following 8 main directions for your reference:

  • Development specifications: This part of the sediment is the team standardization consensus, standardization is a prerequisite for effective team collaboration.
  • R&d process: Standardized process directly affects the division of labor and efficiency of upstream and downstream cooperation. Excellent process can bring more professional cooperation.
  • Underlying assets: On our team, the asset system consists of a tool chain, a team standard DSL, a material library (components, blocks, templates, etc.).
  • Engineering management: Low-cost control of the entire application lifecycle, from application creation to local environment configuration to low-code setup to packaged deployment.
  • Performance experience: Find page performance bottlenecks and provide optimization suggestions in an automated and tool-based way.
  • Security prevention and control: Third-party packages rely on security, code compliance inspection, security risk detection and other prevention and control mechanisms.
  • Statistical monitoring: buried point scheme, data collection, data analysis, online anomaly monitoring, etc.
  • Quality assurance: self-test CheckList, single test, UI automated test, link automated test, etc.

The above are the main directions and zones of general front-end infrastructure, whether PC or mobile, which are the basic construction points. The difference in business stage and team capability is reflected in infrastructure, and lies in the completeness, granularity, depth and coverage of automation of output.

5. How to build infrastructure

Below, we will list some cases of front-end infrastructure products for reference based on the construction output of our team in the past year in some directions that we are all interested in.

1. Specifications & Documentation (Docs)

Norms should come first. In the beginning of the unification of the six countries, “books, texts and cars are on the same track”. Norms mean standards, which are the consensus of the team and the basis of communication and cooperation. Documentation, on the other hand, is one of the most overlooked things. In addition to ostensibly important technical documentation and business stability, it also includes effective comments between lines. Think about how much time you spent trying to figure out the logic of someone else’s code, or how many times you had to figure out the warehouses in front of you when you took over a new business, or how many times things went wrong because you couldn’t figure out where your predecessor had left a hole.

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 collective aesthetic. Once the specification is established, it should be strictly implemented to create consistency in the team’s behavior. For documentation, writing documentation for the sake of writing is junk, better not to write at all. The point of documentation is to speak the language, to be effective, to be intuitive, to be easy, to be relentless. Think of a UI component library document that shows you an interactive Demo and then provides API information, or one that starts with a bunch of API text. Which is better for the reader and less psychologically costly?

2. Local Engineering environment (CLI)

Local development environment, I believe that any team will do the standard configuration, easy to directly embrace the frame selection of the corresponding family bucket, such as Vue family bucket, or with a scaffolding Webpack. More powerful scaffolds provide plug-in services such as Lint or Mock. From a simple local scaffolding to a complex engineered kit system, the aim is to dehumanize and automate the local development process.

The local development environment infrastructure of our team is an engineering suite 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, local initialization of an application environment, starting from the CLI command line operation (in fact, the front end team of the political acquisition cloud is now completely GUI), a zoo init command can do all the local environment setup, this all means that after the terminal hits enter, Everything from the generation of the repository’s local directory to the automatic installation of NPM dependencies to the initialization of the scaffolding plug-in to the invocation of a browser window is done automatically. Yes, even NPM install and dev what do not have to execute, can save a step to save a step operation, chu King good waist, less is sexy. The following is an architecture diagram of the CLI local engineering suite:

3. Visual Engineering System (GUI)

In fact, the daily research and development of the team has been basically separated from CLI operation, and unified to the desktop client “Dunhuang” platform developed by the team. Based on the capability of the client, it can aggregate the scattered engineering capability and form the serial capability of the link. Combined with the intuitive and simple operation of GUI, it further saves trouble. Through the desktop client, daily front-end r&d link operations can be aggregated, from component development to template development to application development; From evoking the editor to starting the debug environment to doing package updates to packaging deployment publishing. At the same time, the desktop system can also get through with other RESEARCH and development systems to form more capabilities.

4. Component development and management

In general, the front end team will complete their own component library architecture. In some cases, some UI component libraries may use a good third-party library, such as ANTD, which is open source in the community, but they will more or less have their own business component libraries to encapsulate. The value of tools is in smoothing out differences and unifying the underlying standards. For component development, the PREVIOUSLY described CLI toolchain is the underlying dependency, as well as template development and use, and application development, described later. The development and management of components through tools can better realize standardization of component naming, version, search convenience, simplification of development process, etc. It can also realize the statistics of application scenarios and version coverage of components related to the necessary statistics of component updating cost in the access scenario.

5. Template development and management

Similar to Feibing, we also precipitated a similar set of templates to facilitate the rapid development of back-end 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 Demo production and interaction. The premise of the template is the complete UI component library, and the standard background interaction, visual design, based on the precipitation of standardized business template library, according to the scene to choose the appropriate template, configure the page information and path, you can be installed to the local click and automatically configure routing, install dependencies.

6. Project creation and management

In project creation and management, our goal from the very beginning was to “decouple and Hold the whole process by one person” — that is, in project creation, local environment construction (including environment upgrade), branch management, construction, deployment and other links, front-end students can handle all by themselves. There is no need to find someone to help build a warehouse because of the problem of authority; Don’t have to learn new standards every time because of components, blocks, templates, applications (SPA/MPA), and React/Vue. There is no need to worry about the inconsistency of the different versions of the business process. Don’t need to be human to configure the packaging script; No need to hire someone (or o&M) to help with every deployment… In short, we want to use tools to smooth out too many asymmetries in our daily lives, and bring the developer’s focus back to as simple and pure coding as possible. Even a freshman who is not familiar with Git, command line and application management process can start coding happily with the help of the desktop visual engineering system.

7. Front-end infrastructure assets

Earlier we talked about front-end team specifications (standardization), toolchain (CLI), toolchain based visual assistance client (GUI), components (modules), templates, applications. The abstraction of tools and the reusable abstraction of the business are fundamental assets of a team. Simplified to Webpack lift a scaffolding + a set of open source tripartite UI component library, the rest of the assembly type production depends on human flesh; More complex such as Alibaba is breaking through UI2Code, editor and other capabilities, the standard, process more automated, further human flesh. As for basic assets, our team’s construction in the current business stage is stratified as follows:

8. CI/CD automated build and deployment

The front end has its own build and deployment system for better process control in terms of specialization. In the second half of 2019, the front-end team of zhengzhou-Mining cloud built its own construction and deployment system, realizing cloud packaging, cloud detection and automatic deployment (integrating the deployment system of receiving and maintaining). At the beginning of the design of the new independent system, the focus is to realize a Flow mechanism, so as to realize the static detection ability of code compliance. This part finally realizes a set of plug-in mechanism in the system, which can configure different detection items as required. If a certain detection item fails to pass, it will eventually block the release process. These detection items include:

  • * Lint detection
  • Compatibility API Checking
  • HTTPS detection
  • Packet detection (Blacklist, packet version)
  • Validity detection (domain, link)
  • 404 test
  • Basic UI detection (e.g. missing ceiling)
  • .

9. Visual building system

The visual scaffolding system is the superstructure for further efficient use of components. The page is composed of components (business modules). The building system will implement the assembly of components by local people and transition them into visualized puzzles in the system. The page building, data configuration, construction and deployment, data burying point and other products will be productized to enable the product, operation and other collaborators. Front-end output component and operation building page can not only save front-end human efficiency, but also enable operation capacity to be advanced, further release operation business capacity in the marketing scene, and achieve win-win situation.

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

System Architecture Diagram:

Deployment flowchart:

10. Data burial point and analysis

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

For more data burying points related to analytics, check out our team’s previous post on data burying Points Analysis Systems for Front-end Engineering Practices.

11. Automatic analysis of page performance

Page performance, 90% in the front end. Unlike my old employer (Taobao, Mushroom Street), mobile terminal has already dominated the business, especially for the toB-oriented business of our company at the present stage. We still have a large number of PC scenes, with prominent problems in page performance. 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: What to do with graphics. 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 “Puppeteer Crawler Practices for Automated Web Performance Analysis,” and “Automated Web Performance Optimization Analysis Solutions.”

12. 2019 Infrastructure Milestone

Part of the technical infrastructure construction of the front end team of zhengcai cloud introduced above is basically implemented and achieved results gradually in 2019. The following chart shows the construction milestones in the previous year’s cycle, showing the corresponding construction cycles and rhythms. In my team, there is no independent front-end architecture group, and the teams under the front-end are all business teams. Our students accumulate problems from business support, think and collect problems, and promote corresponding construction based on business problems.

For r & D students, the value depends on the ability to solve problems and whether they have solutions to different business problems. Fortunately for our team, the business is in a period of rapid development, with many problems and few existing deposits. We are lucky to help solve the problems and follow the rapid development of the business, and do these constructions almost from scratch. This is a valuable experience, because most companies are either not big enough to do this, or they are too far gone to see the whole thing through. Companies have to create an environment for their employees, but ultimately, employees grow on their own. Therefore, students all recognize that it is a valuable opportunity for their growth to participate in construction or even lead a certain direction in their spare time.

Six, infrastructure

1. All construction, there will 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 project construction, and continue to be collected in the whole 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 does have to be illustrative, intuitive, and accurate.

2. Start with the scenario

In terms of manpower, manpower is missing in any case. But most of the time, our construction fails, not because of manpower problems, but because of a lack of clear thinking. There is a fable in The biography of Zhuangzi Lyko, “Zhu commented that he learned how to slaughter a dragon in a fragmented way, but failed to use his skill in three years.” It’s about a man who spends all his money to learn dragon slaying skills, only to discover that there are no dragons in the world. For r & D students, there will also be the problem of looking for scenes from the scheme. For example, if you want to learn Node and do not know how to learn, you will learn from the examples in the book and finally find that it is not good to forget the effect. No writer is read a novel, no linguist is read a dictionary, and no technologist is read a technical book. Learning by doing has always been the fastest way. The worthwhile thing is always a matter of business itself. Problems are opportunities. Problems are pits.

3. Expand capabilities without setting limits

The present situation of low discourse power of the front end in the RESEARCH and development system exists from the moment the function of the front end appears. Individual R&D teams are not excluded. Due to their business models, they rely heavily on the front end and have a relatively high voice in the front end. In the vast majority of r&d teams, front-end work is often seen by other developers as “low-tech”, “thin layer”, etc. Take a look at the picture below:

Horizontal, vertical, two dimensions. The “vertical” on the right refers to the hierarchical system of network application system. The traditional work category of the front end is concentrated in the “user interface layer”, and rarely goes down to 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 capabilities that trickle down. Some teams are also expanding their engineering capabilities horizontally based on Node, and expanding front-end systematization capabilities to business depth.

Let’s look at the horizontal on the left. There are very few front-end teams that are better at building and developing technology systems. For the front-end team with a more perfect system, its technical system is more limited to the functional scope of the front-end itself, failing to better interaction to penetrate into the business side, more self-promotion, business perception is very weak. Turn engineering benefits from technology into business benefits; Turn technical impact into business impact within the department; Upgrade the technical scene to the business scene; Turn the team’s basic capabilities into business capabilities. Jump out of the front end, around and in-depth business, this is every student who is promoting team system construction to think more.

4. Phase matching of services

The content of the infrastructure is matched to the business phase. The content and depth of infrastructure varies from team to team at different business stages. The difference is not in quantity, but in understanding and support of the business. Never sharpen an iron bar if all you need is a needle.

5. The value of technology is to solve business problems

The value of technology is to solve business problems; People are valued for their ability to solve problems. But technological infrastructure is not a silver bullet, not even in the top three, in my opinion.

Seven, finally

Finally, here’s a question for everyone to think about: