preface

ToG project — a very rare and mysterious project field in our daily work, all experienced people, as if through a storm of baptism, who do who know.

The name alone is awe-inspiring — a new form of currency, a government partnership, full of unknowns and challenges. Indeed, it has been proved that this unusual project has a long link process from government side communication, product planning, business delivery, interactive visual design, material production, front and back end research and development, testing and project exercise. And in this process, the challenges of the ups and downs. The whole project team from the beginning of the panic meng new unprepared, but also gradually become the reality of the attack into a wall of iron.

So what kind of project is this, and how do we deal with it as the front end, this article will explain in detail.

directory

  • Project characteristics
    • More gold
    • emergency
    • mercurial
  • The premise of fast delivery
    • Comb activity state flow: See through the appearance to see the essence
    • Aggregated active data flow: Centrally manages data
    • On-demand decoupling: UI replication, logic reuse
  • Risk control measures
    • Reduce the number of risks: start with the release
    • Reduce the risk of transition failures: If I run fast enough, the bug can’t catch me
    • Reduce the scope of failure: the arcane meaning of module partitioning
      • Add a module loader
      • Define the appropriate deployment hierarchy
    • Shorten the duration of failure: nip customer complaints in the cradle
  • conclusion

Project characteristics

As of the publication of this article, jd has completed the registration, lottery and distribution process of the digital RMB project cooperated with local governments in Suzhou, Beijing and Chengdu.

The digital RMB project described in this paper is the H5 page of the application and visa query process in the main APP of JINGdong.

The main features of this project can be summed up in three words: abundant money, urgent and capricious.

More gold

The event budget is high, the single user high returns, users will be able to get every unsuccessful can be as high as 238 (chengdu) 200 yuan of naked earnings, based on past experience, high yield represents a high risk of customer complaint, so in terms of activity process and page content display must be extremely rigorous, there is no flaw that requires each character have high risk awareness.

emergency

The crazily compressed schedule in the early stage of the project poses a huge challenge to the rapid and high-quality landing of the project. At the same time, in the process of approaching the government delivery deadline and the exercise, there are often irresistible requirements adjustment, and the time left to the project team is often only 1 or 2 days, how to safely and quickly iterate is a big test.

mercurial

During more than a month of project promotion, a total of 6 large-scale demand changes were made, and one of them even cut off more than half of the business gameplay. Every change will bring unpredictable risks to the project. How to minimize project risk during each change, especially during activities, also needs to be considered.

These three project characteristics, translated to the front shoulder of the challenge, is how to achieve rapid project delivery and risk control balance.

The premise of fast delivery

The front end is a prerequisite for rapid project delivery, and it is also the early stage that is often overlooked or skipped by many activity development projects — detailed requirements analysis and architectural design. This kind of short cycle activity, during the development of the activity, the requirements for the necessity of architectural design are not high. Generally, as long as the function is satisfied, the test is passed, and there are no online problems within a week or two cycle, the mission of the project is completed. As for the rationality and extensibility of the architectural design, it doesn’t seem that important.

However, in a project with rapid iteration, complex process, and the possibility of deploying human resources at any time, preparation is especially important.

Comb activity state flow: See through the appearance to see the essence

As can be seen from the overall digital RMB interactive draft, the interactive process of the whole activity includes several stages: user registration link, review link, query link of the signing result and scan link of the offline site. The whole activity process is very long and complicated.

Therefore, before the development of the specific logic of the activity, the first step is to sort out the state flow of the whole activity, and to sort out and integrate the process nodes with bifurcation and intersection in the interactive process.

Numbers, for example, the interaction in the process of the project, each stage has some abnormal state, but in practice activities at the core of the process should not be included in the abnormal state of flow, therefore in the process of combing, we pulled out the abnormal state flow, the abnormal state in other places, such as request function, individually, The core process only retains key states such as registration, review and winning.

The goal of this step from beginning to end, are making the final rendering can flow state in the code as far as possible concise and clear, and so on after entering specific logic of development, can not need to spend too much energy focusing on such as “what is the current process and status” and “will there be other state with the current state is” or repeat the intersection of the problems above.

Aggregated active data flow: Centrally manages data

In the code of this digital RMB project, we stored all the core data in the page in the top layer Mobx for unified management, and distributed the data to each component from top to bottom or directly.

In addition, you need to avoid the child component directly changing the state or data of the parent component through callback functions. Instead, you are recommended to change the state field stored in Mobx through action, and update the state of the component that needs to be updated from top to bottom through Mobx.

As you can see from the following figure, before the aggregation of data flows, data transfer between components is chaotic and disorganized, which is obviously not conducive to subsequent iterations and maintenance of the project code.

Through data flow aggregation, it is very convenient to comb out the data flow direction of the whole page at the code level, where the data comes from, where the data goes, and what impact it has.

On-demand decoupling: UI replication, logic reuse

In software development and design, there is a well-known idea that “replication is better than reuse”, as explained in “Endogenous” over The Medium “, that “the pursuit of reuse deepens the coupling between systems. In the open source world, you can fork it based on different directions. “At the UI layer of the DIGITAL RMB project, we also want to follow the same idea, focusing on copying rather than reuse.

The essence of “replication” is “decoupling”. Coupling UI structure code of the same type and different styles into one component is not conducive to subsequent maintenance and rapid iteration.

In the digital RMB project, we follow the principle of “UI duplication, logic reuse”, that is, we prefer to start from the same type of UI structure, different styles of UI structure corresponding to different component files, and finally distribute these same type of different styles of UI components through the module loader. And extract the same logic code in different UI components to achieve maximum logic reuse. The specific approach will be described in detail below.

Risk control measures

In terms of risk control, we mainly think and practice from three aspects: reducing the number of risks, reducing the probability of risk transformation failure and reducing the scope of failure influence, so as to ensure the high availability of active pages. The Nature of High Availability presents a formula for risk expectations, as shown in the figure below:

According to the article “The Nature of High Availability”, in the above risk expectation formula, risk control is mainly considered from the four directions of nPRT, which corresponds to “reduce the number of risks, N”, “reduce the probability of risk becoming failure, P”, “reduce the scope of failure impact, R” and “shorten the duration of failure impact, T” respectively. Below, I will combine some of these directions with relevant practices in the digital RMB project to explain how we reduced the possibility of online failure through risk control in this activity.

Reduce the number of risks: start with the release

The Nature of High Availability argues that “nothing is 100% reliable” and that both humans and machines are subject to error — development will miswrite code carelessly, software will fail due to system bugs, and hardware machines will fail and break due to durability and abnormal environments. From the change of requirements to the launch of activities, our code goes through the process of development, compilation, packaging, deployment, there is the possibility of human and machine error. It is also mentioned in The Nature of High Availability that “from the perspective of probability, as long as there are enough changes, the probability of errors will be infinite toward 1”. Combining with the risk expectation formula in the paper, it can be seen that the more times of demand changes, the higher the risk expectation.

In daily projects, frequent releases will undoubtedly increase the number of risks.

In this project, we considered standardizing the demand process and isolating operational data and logic to minimize the number of releases.

I. Standard demand process When demand is proposed, the necessity and risk of demand change should be strictly evaluated; When confirming requirements, synchronize the information with each role in the project and record the information in a unified manner by email. Improve the threshold of demand change, filter the demand of low importance, reduce the frequency of demand change. This is the standard process that all large projects should follow.

Separate operational Data from logic First, clarify the meaning of two terms. Operation data refers to the data related to business documents and visual materials in the project, while logic refers to the main process of the page and the code files related to interaction. The deployment of logic, will go through compilation, packaging, upload, release several steps, each release, there is a certain risk of release. In this digital RMB activity, operation data and logic are managed through two independent platforms to minimize the number of logical releases.

In terms of operation data management, by accessing PPMS (Operation Content Management Platform) system, the content sources of predictably modified modules in the page are configurable. After the code goes online, if there is a sudden change in the requirement of non-core process logic, the page display content can be changed by changing the configuration item and updating the data source, without redeploying the logical code, which greatly reduces the deployment risk caused by frequent changes in the operation content.

Reduce the risk of transition failures: If I run fast enough, the bug can’t catch me

There is a risk in the active page, which is an unavoidable problem, but the existence of risk does not mean that failure will occur after the online, but there is a possibility of failure. In order to conduct investigation and detection of known controllable risk items before going online, a pre-going online checklist can be developed.

The checklist of digital RMB projects includes two types of contents, one is general check items and the other is project-specific check items, which maximizes coverage of foreseeable risk points and frees the developer’s mind to focus on development.

Reduce the scope of failure: the arcane meaning of module partitioning

Modular isolation of logic is one of the most important ways to reduce the scope of failure.

In this project, there are two main approaches: module isolation at the code level and module isolation at the deployment level.

Add a module loader

At the module design level, we added a module loader to uniformly collect and distribute modules of the same type, and completely decoupled and isolated these modules. In the past, when developing modules, we usually have the inertia of thinking and designing the use of modules, and often ignore the importance of reconstruction. For example, when we create a header component, the first thing that comes to mind is the following implementation:

class Header extends React.Component {
  render () {
    return (
      <div className='header'>I am header</div>)}}Copy the code

For now, everything seems fine, but unfortunately requirements are often capricious. Suppose that one day this header component needed to add an item display depending on the state, it would be natural for the code to look something like this:

class Header extends React.Component {
  render () {
    const { isGoodShow } = this.props
    return (
      <div className='header'>
        I am header
        {
          isGoodShow ? (
            <div className='good'>
              <img className='good-url' src='url' />
              <span className='good-title'>The head of goods</span>
            </div>
          ) : null
        }
      </div>)}}Copy the code

As you can see, we have written the logic of the header display directly into the only header component. Since the current component is not complex, the code logic seems to be very clear and there is no problem.

But imagine that when a variety of other modules need to continue to appear in a header component based on different conditions, the entire header component is jumbled with all the logic of those modules. In the future rapid iteration and requirement change, we may need to change and adjust the code of a module in the header component. At this time, the probability of error caused by adjusting the code will be greatly increased in the face of the header component which is jumbled with all the module code.

This is the case in the digital RMB project. There is also a head component in the project, and there are six situations in the head component: not logged in, not opened positioning, not registered, in review, approved and not approved. It is obviously inappropriate to couple the six situations in one head component.

There’s a saying in computing: “In the field of computer science can be any problem by adding an indirect middle tier to solve”, therefore in the process of the development of digital currency, we head component and module components are of a similar situation a refactoring, the component calls established a middleware layer between layers and components, we generally call it “module loader”.

The module loader’s job is simple: collect all the header components and distribute them according to different conditions. Let’s look at the following code:

import BaseHeader from './base'

class HeaderA extends React.Component { / * * * / }
class HeaderB extends React.Component { / * * * / }
class HeaderC extends React.Component { / * * * / }

class HeaderModuleLoader extends React.Component {
  render () {
    let Content
    swtich (headerType) {
      case 'a':
        Content = <HeaderA />
        break
      case 'b':
        Content = <HeaderB />
        break
      default:
        return <HeaderC />
    }

    return (
      <div className='header'>
        <BaseHeader />
        {Content}
      </div>)}}Copy the code

In the above code, we have nicely categorized the header components, extracting their reusable parts in the BaseHeader component, while the content presented in different cases is encapsulated in different header components, via switch… case… Distribute corresponding situations.

The above code is essentially an application of the policy mode. The HeaderModuleLoader module loader returns different content, but they are all one of the headers, but we have different policy judgments and distributions in the module loader.

After processing in this mode, we can successfully decouple the header components in different situations. When a certain header module needs to be adjusted or changed later, we only need to go to the corresponding HeaderA or HeaderB for corresponding adjustment, without affecting the function and use of the whole header component.

At the same time, we also reformed other modules with the same situation in the project. In the subsequent iteration and adjustment of digital RMB, there have been a lot of demand changes like “the head under the review state, I want to add a paragraph of text”. In the past, we needed to judge the activity state through conditional statements in the only head component to display the new or deleted content.

But after modified, we only need to go into the corresponding state head component can add or subtract code, don’t need to write any redundant judgments, also do not need to consider the current changes will not affect the other content and logic, visible, the development of this kind of design mode, gives us great convenience and efficiency.

In general, for the future extensibility and maintainability of front-end modules, we need more thorough decoupling of the UI layer of these frequently changing modules and more thorough reuse of the logic layer.

Define the appropriate deployment hierarchy

In keeping with the principle that all eggs should never be placed in one basket and all trees should never be placed in one basket, we have done two main things for deployment isolation in this DIGITAL RMB campaign: operational data and logical deployment isolation, and page-level deployment isolation.

The isolation of operational data from logical deployment is explained in detail in the section “Reducing the number of risks” and will not be covered here.

In terms of page-level deployment isolation, we refer to the micro-front-end idea to separate some processes and modules that are not closely related to the main process at the page level, and split the original only active page into four parts: the in-site H5 page, the off-site H5 page, the digital RMB APP download page and the abnormal situation handling page. Pages communicate with each other using URL query parameters. Each page is individually developed and deployed online.

The deployment hierarchy is defined this way for two reasons:

  1. From the source code level, logic exist mainly in order to guarantee the main page clean and concise, the main page code is the core of the whole event, will be the more to eliminate irrelevant detail, and the isolation, the more can guarantee its main process logic control is clear and clean, to some extent improve the stability of main process code and readability.
  2. From the perspective of risk, splitting an active page into four pages is to disperse risks. After fragmentation, no matter what happens to H5 outside the site, it cannot affect the H5 inside the core process, and vice versa. This is the same reason that investment and financial planning should do a good job in portfolio selection. Risk hedging is an important part of risk control.

Shorten the duration of failure: nip customer complaints in the cradle

Most of the time, a project, after a complete test case beat is far from enough, some hidden problems, without a large flow of erosion, is difficult to show. For example, during the exercise of this project, the “activity is too hot” interface has a higher probability than expected, which is difficult to expose through a small number of accounts and visits.

Product & Business student: “Some users feedback that the page jump is too hot, is there something abnormal in the interface?” Back – end student: “There is no abnormal data on the back – end monitoring. It may be that the request from the front – end has timed out.” Product & Business students: “The front end of the students to see if there is a problem.” Front end classmate: “Erm… There’s no way to see it on the front end.”

The access of online monitoring can find this kind of problem in advance to a certain extent, and deal with it in advance accordingly, stop the loss in time, race with the customer complaint, and even kill the customer complaint in the cradle.

In this project, due to time limit, front-end monitoring was not properly planned and connected. In the later stage of the project sometimes indirectly involved, but also encountered the project code iteration security risks, and the challenge of testing costs. The root cause is the non-mandatory access monitoring in the project development specification and the high time and mental cost of monitoring access.

The team has produced best practices in jingdong Mall PC home page project: interface availability monitoring, speed monitoring and code anomaly monitoring. Through interface availability monitoring, developers can be reminded in real time by phone or message push in case of low interface availability or abnormal transfer usage. The speed monitoring plays an important role in monitoring the performance of pages and interfaces. Code abnormality monitoring can report error information on the page, and the developer can screen and screen, to determine whether there are online problems that have not been detected during development.

Based on best practices, consider providing developers with an SDK that can quickly access monitoring systems to solve the “how to quickly access these monitoring systems” problem. Some necessary access operations are integrated into a set of SDK, and some business methods originally provided by the monitoring system are expanded to make it more flexible and applicable to more business scenarios.

conclusion

As mentioned at the beginning, the challenge at the front of this project lies in how to strike a balance between fast project delivery and risk control. In this project, we conducted targeted thinking and practice based on the previous experience and theory of promotion, and basically realized the risk control within a controllable range. However, all current measures still rely on the manual operation and subjective consciousness of the executive. Based on this, we will continue to explore and optimize, and maximize risk control with the goal of comprehensive access to the process of the digital platform, so as to better and sustainable support for T-level interaction.