1. Reconstruction Background

In the past year, we have done two major projects (about 70 pages) :

  • First, due to the rapid development of the business line, the existing project gradually evolved from the incubation at the beginning to the basic business. In addition to running in the small program, it also needs to run in the APP end, which requires an H5 version. Therefore, we reformed a VUE project according to the original MPVue project (MPVue said it could be converted into H5, But if the page is complex, there is no way to convert.

  • Another is that as the business grows bigger and bigger, there will be more business integration with the main program and other lines of business, as well as reuse and update of common libraries. Our small program projects are written in MPvue, while the main program and other lines of business use Wepy. Every time we cooperate with other business lines, we always re-develop. This year, due to the general direction of the company to streamline, the cooperation with other business lines will be closer and closer. In order to prevent the technology stack from becoming a barrier to the cooperation of business lines, we finally decided to transform the MPVUE project into WEPY

2 Transformation experience

After these two big transformation, I also came to some experience, here to share with you:

2.1 In the process of migration and transformation, the project must be fully divided, the finer the better

This part is the core of the whole project and also tests the project leader’s familiarity with the whole project

If you are not familiar with any part, be sure to ask the corresponding person in charge, and then look at the code yourself

Because all subsequent development, project follow-up, and testing are based on the “blueprint” produced by this step, we should be particularly patient when doing this part, because there will be fewer holes behind this part.

I split projects into chunks:

  • Original project pain point thinking

    There must be some unreasonable design in the previous project, and this is a good opportunity to correct it, such as:

    1) Ajax return result: we used to return data directly in order to make it convenient not to handle the interface error on every page, but there are often cases that need to be judged according to the code code returned by the interface, so this time the return is {code: XXX, data: {… }} form

    2) New projects include typescript and webpack4

    3) Added gotopage.js: the original small program directly jump through path, but after the page is too many, especially the path carried parameters is very difficult to manage, often PM asked me for a link to the active page, path is easy, mainly parameters do not know what, but also have to check the code. So we created a gotopage.js that gives each page a name and comments that indicate the meaning of all the parameters, making it easier to call and easier to query

// navigateTo({url: url.setparam ('/packageA/pages/activity/publish4RedpackageSuccess/main', {
    channel: 'xxx',
    shareUid: 'xxx',
    fromActiontype: 'xxx'})})'activityPublish4RedpackageSuccess', {
    channel: 'xxx',
    shareUid: 'xxx',
    fromActiontype: 'xxx'
})
Copy the code

4) Other renovation points

  • Project structures,

    The project leader must complete the construction of the project, all kinds of NPM packages, Webpack configuration, this is the most basic work, migration must be completed

  • The public library

    There are many files can be directly copied from the public library, the most important is the transformation of basic capabilities, especially in new and old projects, some basic capabilities are not common, should be transformed, at the same time, the old project base library which needs to be introduced into the introduction of public packages should also be listed, such as:

    1) Login: Login before and login after

    2) Ajax encapsulation: does this need to be handled by a change library (such as AXIos), does the interface request need to be forcibly logged in, various status code processing, and the returned data structure

    3) Cookie: The cookie processing of small program is different from the cookie processing of H5 project, and the cookie name is changed

    4) payment

    5) Upload pictures

    6) Statistical reporting

    7) H5-specific files

    8) Processing of general business logic

  • Common component

    All common components should be listed one by one

  • page

    The page part is mainly to sort out which pages have been offline (usually active pages, if they have been offline, they are not within the scope of this transformation and migration, so workload can be directly reduced. Offline pages need to be prompted).

    Then list the pages that need to be migrated and the pages that need to be taken offline

Okay, so with all that done, we can make a big Excel spreadsheet

List each item in the table, and estimate a time for each item based on the original project code

Note: In the estimation of time, the project leader will make an estimate based on the actual average daily effective time within the group.

For example, according to the calculation of 10 in the morning and 7 in the evening, some people will be late in the morning, have a lunch break at noon, and take a walk after dinner in the evening. The actual effective time of a day may only be 6 hours

Of course, the effective time of our group is higher than this time, and the person in charge should evaluate according to the actual situation of his group. (It takes a lot of scrutiny to confirm this.)

After the time of each item is finalized, a total time is calculated, and a certain additional buffer time is needed according to actual needs (I marked 10% here, from 67.4 days to 74 days).

2.2 The division of labor must be clear

According to the above Excel, make clear the content of each person’s responsibility (the original person in charge of the branch is still the same).

But there is a point, is the division of labor of public part, must be clear!!

For example, if A, B and C all use the same common capability or common component, it must be clear who does it. Don’t look down upon this. I suffered from this in the first reform.

After the division of labor is completed, it is not the final version, but should be revised twice according to the time invested by each person

2.3 Staff investment time should be clear

Make it clear when people are engaged, when are they going to be engaged, when are they going to take time off, etc.

For example, the project team consists of A, B, C, D and E:

  • A Immediately available for intervention, 2 days off at the end of the month
  • B can intervene immediately without asking for leave
  • C can not be involved until the day after tomorrow. Please take 3 days off at the beginning of next month
  • D5 days before intervention, at the end of the month, 1 day leave
  • E To intervene after a week, without leave

The above table “person in charge” is then amended according to each person’s actual time.

Rule: Try to make sure everyone finishes the project at the same time.

2.4 Review the first draft of transformation

Just because other leaders aren’t familiar with their projects doesn’t mean this step is unnecessary.

After the review, leaders will give many constructive suggestions:

Public library and the component library this especially, what kind of ability, what ability need to be modified, will communicate very clearly, because the company’s business is huge, so there are a lot of public libraries), there is no ability for project before, if public library support, will be very save time, at the same time also know is who is in charge of this part, When you encounter problems, you can directly contact the person in charge.

In this process, you can also communicate with others about your own ideas. Some of the improvement suggestions in your project may also be needed by other groups.

If there are conditions must pull everyone to review.

2.5 Communication on online time

This section is particularly important, as after completing the above steps, it is possible to estimate the time (usually large projects can estimate the testing time at half of the development time).

Take us for example:

74 people/day of development, 37 people/day of testing, 5 people in FE, 3 people in QA (this time is front-end framework migration, not involving the server side). It is estimated that development needs 18 working days, and QA needs 15 working days, which is about one and a half months.

Communicate with leaders and business side on this time to see if this time is feasible. If OK, there is nothing to say. If not, we need to consider working overtime.

When overtime is not enough to solve the problem, you have to turn to the leader for help and need the support of other groups.

Take us as an example, we only had 5 weeks at most, and we could not work overtime (because we had to work six days a week at the end of the year, so it was obviously inappropriate to ask everyone to work one extra day), so we asked the leader to coordinate a member to support us for a week.

So what can the new member do if he doesn’t know the business?

We can only make pages with relatively simple business logic for him, such as search recommendation, search result page, personal homepage, etc., and then adjust the division of labor of the whole project

2.6 Progress Follow-up

For the transformation of large projects, it is common to ask the progress of the members every day, and it is not careful to delay for a few days

Update the “development progress” in the form in time, and let yourself know

  • White: it has not been started

  • Blue: Under development

  • Green: Completed

The same is true for tests

2.7 Test intervention method

For large projects, batch testing can be used.

This maximizes the use of QA resources.

During the test, QA should be informed of the test progress every day, the speed of bug modification, and whether there is any problem in the process.

That’s how we ended up with a project that took 1 month and 3 days, 2 days ahead of schedule.

2.8 Why Excel is used for two reasons:

  • On top of that: because framework migration is technology-driven, writing requirements documentation is a lot of work, especially when listing test points.

    This table is very detailed, which pages and functions need to be tested at a glance, and can be directly sent to QA. They can work directly in the test progress column, and can also track progress by color-coding each day.

  • Excel is available on all computers, so there is no need to install software

Anyway, this chart will save you a lot of work

OK, the above is some recent thinking, share with you, welcome to exchange