Team in the battle of the project the whole frame structure is set up four years ago, about the company’s business strategy has been a lot of changes have taken place, the “old urchin” project in the face of rapid iteration of new business, some problems left over by history and non-standard design, brought extra burden to development, demanding and arduous, refactoring is imminent

This is the fourth day of my participation in Gwen Challenge

Problems in the project

After analysis, there are probably these problems:

  • The use ofAngularThe framework does not support componentized programming well and is cumbersome
  • Version aging of the framework,AngularIt’s version 12, we’re still using version 5. Accompanying documentation for this version is scarce
  • A large number of non-standard, redundant and incorrect writing methods in the project
  • Due to historical reasons, there is a lot of patch code

The other big problem is that since we release every two weeks, the changes may be small, but the impact is huge: it’s a full release every time.

Due to the large size of the full package (several hundred MEgabytes), users who are not involved in this release will also need to re-download the entire resource pack.

Development process issues

Due to the rapid pace of iteration, people are busy with their own work and rarely do CR (code review). After all, one person’s view is narrow, which may introduce some bad implementation or design into the project.

At the same time, due to the different styles of code development, the code written by each person is very different, which also brings difficulties to code Review.

So the team needed a uniform code style to pave the way for CR

Let’s talk about solving the problem

First of all, the solution to the problem of the project is actually very simple: that is, reconstruction + splitting. I recommend the team to adopt the Module Federation scheme of Webpack. For details, please refer to the micro-front-end practice — WebPack5 module federation.

As you can see from the figure above, the previous project catalog was large, and we split it into at least six sub-projects (depending on the granularity of the split), each of which can be deployed individually or collectively (is it a micro front end?). .

React,react-dom,react-router-dom,axios… Split into a project and expose it, and all other subitems depend on the module exposed by the project.

Thus do the underlying unified agreement strictly, and because these underlying depend on the time varying frequency is lower, so once the stability, the usual iteration release generally do not need to send these underlying module, which means the user only needs to read the module package from the resource cache, without having to request through the network again.

Third, for the problem of the development process, we can use Git hook to run the code check when submitting the code, unified style, for details, refer to the article code beautification “Prettier” for detailed solution.

For code review, we can organize it regularly. Everyone will talk about his/her idea of writing a certain module, and other members will express their opinions, try to come up with some better solutions, and give rewards to those who answer well. After forming a good habit, it will be all right. At the same time, the refactored project will also increase the enthusiasm of code review.

The last

Currently, the team is working on the early stages of the refactoring: introducing TS, addressing the types of remote dependencies, internationalization, etc. I will share some of the results when the refactoring is complete and reaches a mature stage.

Thanks for reading!