On how T-level interactive development shines in our hands

What is T-Class Interaction

Before discussing how to develop and improve T-level interaction, let's first define what a T-level interaction is. T-level interaction is the abbreviation of No. 1 interaction. It is different from other smaller-scale S-level interactions, A-level interactions, etc. It has the characteristics of large traffic, large amount and strong timeliness. It is often concentrated in the Spring Festival, 618, and Double Eleven. Three special e-commerce nodes drive user growth and conversion for the group. The biggest feature of T-level interaction is the integration of multi-terminal resources, which requires a closed loop on the site and WeChat. When developing, it is necessary to carry out H5 and applet at the same time, and to ensure that the experience of the two is similar. The second is to create a national private domain, create exclusive pages for merchants, and increase traffic.

What T-Class Interactions Need Us to Pay Attention to

There is so much content in T-level interaction, which integrates double-end and private domains, and has different gameplay every time. Therefore, in the development stage, it is necessary to ensure that the development efficiency is high, the development experience is good, and the double-end experience is consistent; in the testing stage, it is necessary to Ensure that the quality of the test is high and problems are repaired in a timely manner; in the online stage, it is necessary to ensure the smooth operation of the project, and there will be no mistakes if there is no error. If there is an error, there is a timely error correction mechanism.

Therefore, we can conclude that what we need are tools for efficient development at both ends, a good development experience, a system to repair problems in a timely manner, a system to ensure the smooth operation of the project, and fault tolerance. Then we will explain the above content through the three interactions of the National Games, the Double Eleven Love Tour, and the 2022 Beast of the Year.

Taro —— Double-end efficient development tool

why need

In the current e-commerce environment, only the single-end development of the APP can no longer meet our needs. We also need to open up the process in the WeChat domain. In multi-end development, there are problems such as separate development by multiple teams, coexistence of multiple technology stacks, different page representations, and code duplication. Therefore, we need to change our thinking, from multiple teams developing with multiple technology stacks to multiple teams using an excellent technology stack for cooperative development. In addition to solving the problems of highly repetitive code and different page experience, this move also ensures that people from different teams can help each other and work together, and also solves some human efficiency problems.

What Taro offers us

As an excellent framework for multi-terminal development, Taro is fully capable of developing a large-scale interaction. However, if you want to run normally in the Jinggou applet, you still need to make some appropriate adjustments. We provide a plug-in here to make the Taro3 project run in the Jinggou applet - "Using Taro3 to run the project as an independent subcontract in the Jinggou applet"

The above plug-ins solve some problems in the development process of the applet, but there are still many problems that we need to continue to explore and solve.

We first used this plug-in in the 618 interaction in 2021. At that time, the plug-in code was included in the project. During the development process, the project itself and the Jinggou applet project need to be run at the same time. We will pass the compiled content in our own project through The plug-in is copied to the Jinggou project, and the environment in the Jinggou project is used to run, develop and test. This method is continued in the project of Jingdong Games, and in order to improve the reuse efficiency, the code is extracted into Taro3 plug-ins, which can be used in any Taro3 project.

what problem did we encounter

However, in the Double Eleven Love Tour project, we encountered the compatibility problem of the operating system. In some developers' Windows systems, the plug-in could not run normally. While solving the compatibility problem, in order to improve the development efficiency, our development mode has been adjusted. The existence of the plug-in is to be able to use the functions in the Jinggou applet normally, but the usage scenarios of this part are few in the project, so we can temporarily get rid of the dependence on the Jinggou applet, so that the project can be used independently by the developer. run in the tool.

The adjustment method is very simple. We originally referenced the relative path of the module in the Jinggou applet through the plug-in. In order to get rid of this dependency, we can create a virtual Jinggou applet folder in the project, so that the relative path we packaged can be Points to a virtual folder in the project. In this folder, you only need to create an empty function under the corresponding path, so that the path can point to the corresponding method.

The advantage of this development method is that it does not care about the difference between the operating systems, whether it is Windows or macOS, the project can be run normally, and the independent operation makes it only need to compile once to run, which shortens the compilation path and speeds up development and debugging. . The disadvantage is also obvious, and it is impossible to debug the functions in the Jinggou applet.

However, through this step, we still temporarily solved the development problem and allowed our process to proceed smoothly. And before the interactive development of Zhan Nian Beast, the plug-in has been improved, making the subsequent development more efficient.

At the same time, Taro3 is in the process of upgrading Webpack5. Using Module Federation in Webpack5, we can not rely on the code of the local Jinggou applet at all in subsequent development, but directly reference its functional modules remotely, helping us to further improve development efficiency.

Business component library - reuse code to solve human efficiency problems

what is our next question

We now have an excellent two-terminal development tool and a plug-in suitable for business, which greatly improves our development efficiency and experience. However, the development cycle of T-level interaction is short, and the development of more content is still a problem that we need to face. In fact, living more time and less time, and lack of manpower are not unique characteristics of our interaction. In most businesses, everyone will encounter such problems. But the traffic and influence of T-level interactions magnifies the problem. Then we have to pay attention.

A T-level interaction often requires about 90 to 100 person-days of development time, which means that 3 development at the same time also takes 30 working days. However, it often takes a long time for a large-scale interactive idea to be discussed from the interaction design to the visual landing, and the work time from the final to the development is often less than 30 working days. So what happens next can be imagined, or work overtime to solve problems, or low-quality delivery tasks, or both. But that's not what we want.

So solving the human efficiency problem has become our top priority.

How to solve the human effect problem

There are no more than two direct ways to solve the problem. In the existing time, either increase the manpower or improve the efficiency of personal development. From a direct point of view, adding manpower is the easiest and most effective way. In fact, it is not. With the addition of members who are not familiar with the project, he needs to spend a lot of time learning the development mode, technology stack, original code and workflow of the project. These are actually hidden time costs. Therefore, if we want to solve the problem, we still need to improve the efficiency of personal development and be very friendly to newcomers.

Then we thought of something that most developers have done - componentization.

Componentization to improve efficiency has been a commonplace, but the results are often unsatisfactory, and finally ended without a hitch. And in order to avoid this thankless situation, let's sharpen the hatchet instead of doing it directly.

The problem of componentization often occurs in two places. One is that the reuse rate of components is not high, and some components are developed and no one is used; the other is that it is difficult to combine "general" with "easy to use". doesn't work well.

But business components starting from T-level interactions don't have too many such troubles. The first is the reuse rate. After many T-level interactions, from design to development, we have a general grasp of the interaction mode. Many modules are very fixed from interaction to visual style, so we can find basically every module from it. The "model worker" module that will be used every time is componentized. Secondly, we can not consider the scalability and versatility of a component in the business component. It mainly serves the business, and its basic requirement is to be easy to use.

Then according to the above thinking, we can get our conclusion - based on the experience of multiple T-level interactions, find out the repeated modules, and carry out reuse and transformation while ensuring that the main function and interaction are fixed.

Component library development 123

One is naturally to pick out which components we need to develop, and we won't talk about the specifics. It's just that we divide the components into two categories: those with UI and those without UI, and those without UI are further divided into business logic, non-business logic, and pure functional functions. These components are counted against the number of module occurrences in past interactions.

The second is to choose the technology stack. Needless to say, Taro will definitely take the lead; then in order to improve the quality of the developed components, automated testing must also keep up, followed by Tiga , another two-terminal automated testing product in the team; To be able to package components in a lightweight way, we chose Rollup as a quick packaging tool; finally, we use lerna to manage these components in a unified way, so that they have unified dependencies, and manage versions and releases in a unified way. The specific implementation content and code will not be posted here. It just shows the development process of the component library according to the selection of the technology stack.

The third is the most inconspicuous but the most soulful content of a component library - documentation. Many developers have a headache when they mention documentation, often forgetting the documentation after writing the code, and forgetting to update the documentation after writing. No documentation is fatal for a component library. Components without documentation are equal to components without development. Users don't know if there are any components they want, and they don't know where to look, which eventually leads to low component reuse rate or repeated development. Finally, a component library is really difficult to use. Whoever thought of this bad idea might as well copy the code.

And the three steps of one, two, and three are not just for us to do, but to do all three steps well, so as to avoid a component library from becoming a tasteless rib in the end.

A small test

Of course, we have discussed a lot above, and we will definitely not be convinced if we don't show any results. After two months of piecemeal component development, we accumulated ten components in the first batch, and used seven of them in the New Year's Day interaction, saving more than 10 man-days and ensuring that our personnel have In addition to the Spring Festival Gala project, sufficient time has also supported the Spring Festival Gala cooperation project. It can be seen that our component library has achieved initial results.

Error correction and bottom line

The above two parts have largely alleviated our human efficiency problem. There is still a certain distance to solve it, and continuous optimization and exploration are still needed. So let's turn our attention to another problem - defects.

Basically, it can be said that there is no project without bugs, but it depends on whether the bugs will be discovered or not. We have repeatedly emphasized the complex content and huge traffic of large-scale interactions. Complex content means many places and many possibilities that will be missed by self-testing and testing; huge traffic will give our player groups many opportunities to find bugs . The combination of the two has become our most feared online problems and customer complaints.

The first time I faced a huge problem was in the interaction of the Jingdong Games, and there was a 45-minute white screen in the early morning. The reason is that the upstream data is sent incorrectly, and the front-end does not fully understand the error, resulting in an error on the page. That's right, a mature development has already understood, and we quickly dump the blame on the upstream (not). Instead, we should quickly fix the problem and get the page back to normal as quickly as possible. Then analyze the problem and improve it.

And how to analyze and how to improve it?

Let's take a look at the two steps of online problems: the first is that the upstream data is suddenly wrong, so why is the project that has been running smoothly for many days suddenly data wrong? It turns out that the data will be updated at 0:00 every day, just to update a batch of errors; the second is that the front end did not do a good job of erroneous data, and the code was not robust enough. It was only necessary to hide some modules. The page reports an error.

Let's start with the first step. We can't ask the upstream to have no problems, so what should we do? You can only be optimistic about your own baby. When switching data at 0:00, we as parents need to be on duty online, check all the functions of the page, and then go to sleep in peace. If there is a problem, it can be corrected in time to make the page return to normal.

The second step is a bit mysterious, improving the robustness of the code. Everyone can say this, but things are not necessarily done. We can't be overconfident in our code, so we wrap a layer of bottom components on our floors to catch errors in the floor and hide the floor. Of course, this method is a good way to deal with online problems, but it is not the ultimate strategy as a developer. As a developer, the real solution to the problem should be to improve your code level, consider it thoroughly, and test yourself comprehensively to avoid overdoing it. confidence.

After the two-pronged approach, we have avoided serious online problems and customer complaints in the subsequent Double Eleven, New Year's Day, and Spring Festival Gala projects.

From tricky to glowing

The initial T-level interactive development always stumbles along with a heavy tortoise shell on its back. In the face of various problems, we often work overtime, tear down the east wall to make up for the west wall, and finish a project, not to mention the defects, the developers are already too tired, and finally we just want to take a vacation. With the review of the project and the rise of awareness of development experience, we understand that user experience is our goal, but development experience is also our goal. Only a good development experience can bring us a more efficient workflow and a more relaxed work experience. And this efficiency often means that we end up producing higher-quality code and freeing up more time for optimization.

So the old saying always says that sharpening knives is not the same as chopping wood, and we often complain about not having time to sharpen knives while stumbling and chopping wood. Why don't we stop and see why the task is always chasing behind, and we always seem to be stuck in a quagmire and unable to move forward.

From a difficult problem to an experience worthy of writing in our development career, all we have to do is to think carefully, put in a little effort, find and solve the problem, instead of saying "I understand the truth".