Reconstruction practice of complex C-end project of acquisition technology

1.  background

1.1  restructure

Q： What is refactoring ？

Refactoring is without changing the observable behavior of software , Improve its internal structure .--《 restructure  -  Improve the design of existing code 》

 

Q： Why refactoring ？

Refactoring can improve understanding and reduce modification costs  .--《 restructure  -  Improve the design of existing code 》

 

Q： When to refactor ？

 

（1） When not to refactor ？

There is no value , It is meaningless or the input-output ratio is very low . Team resources are limited , Limited resources should be put into meaningful things as much as possible . Consider the input-output ratio from the perspective of the team , For the maintenance status , If there is no need 、 Unadjusted code , Don't touch it , If for a novice , Not only will it not bring benefits, but it may dig holes , You should know that the existing code may have many holes .

 

（2） When should I refactor ？

• Project maintenance costs are high

• Affect project tuning , Such as performance optimization

• The code is ugly , When not elegant

• When the existing design and implementation are not conducive to expanding new functions

• Repetitive work , When existing code doesn't help you easily add new features

• repair  bug  when , Troubleshooting logic is difficult

• code review  You can have someone review the code to see if it is readable , Comprehensibility

• Too much code is uncommented , Even I can't figure out the code logic quickly

 

1.2  How to reconstruct

（1） Get ready （ Basic skill ）

Recommend classic books worth reading again ,

Reconstruct the Bible 《 restructure  -  Improve the design of existing code 》

 . I started from the first year of graduation , I have been reading for several years  4  All over  +, Benefited greatly , Each review can be fruitful , Let me often toss about the projects I handle without any problems .

 

（2） Refactoring practice points

• Think clearly （ The overall design , It doesn't have to be documented, but it needs to be clear ）.

• Collaborative planning （ Cooperation within the development team and integration of the refactoring branch with other branches 、 Apply for external resources in advance, such as products 、 test 、 Operations etc. ）、 The overall planning .

• Layer by layer and step by step , Grasp the big and let go of the small, from coarse to fine . Make good use of  “
  The batch
  ”.

• Do one thing at a time .

• Don't make wheels over and over again .

• When you find something difficult , Stop and think about the wrong method , What should it be . Keep monitoring and reviewing your way of thinking .

• Good internal and external communication , Especially when the project is not developed and maintained by only one person . Pay attention to communicating with interested parties in advance （ test 、 Operation and maintenance ） Good communication, （ programme 、 Main time nodes 、 Resources to be invested 、 Matters requiring their cooperation ）.

2.  Community  C  The refactoring practice of the end

 

This reconstruction has a certain degree of complexity , In addition to the cost of technology migration and transformation , Several warehouses involved are different technology selection （ frame  &  Upper components, etc ）、 Rapid agile iteration of the project 、 High demand concurrency and multi person collaborative development and maintenance status .

 

2.1  Analysis of current situation

 

Technology stack ：

Project side

Three warehouses  A / B / C  Update active , Each warehouse involves the development of multiple lines of business , Parallel maintenance . According to  2  One week  sprint  The iteration rhythm of ,1  Zhou Kaifa  1  Weekly test , Sometimes it is interspersed with  hotfix.

 

from  V1  Start refactoring after the main version is released , The codes involved in each warehouse are as follows ：

 

• repo A：A1 + A1.
   + A2 + A2.

• repo B：B1 + B1.
   + B2 + B2.

• repo C：C1 + C1.
   + C2 + C2.

.*  Express  hotfix

2.2  Refactoring plan

The overall idea of the front side ：

• repo A  Newer , It is the main warehouse of the community , Most of them  C  End page , As the target  C  Target repository for end code .

• repo B  To  repo A：repo B  And   The technology stack of the target warehouse is very close , involve  5  A page , Migrate through human flesh , Pay attention to the migration of dependencies during the process .

• repo C  To  repo A：repo C  It is quite different from the target warehouse , And the language is heterogeneous , Upper frame 、 Component libraries are quite different , There are many pages involved .
• First, identify the valid pages , Put... On the offline page  dead code  Excluded from migration ; The details will be discussed later , Take out the front-end routing configuration in the warehouse to be migrated , Know the total range of pages , Check out Alibaba cloud  sls  Recent in the log  PV（ Two query methods for proofreading ）, Exclude pages without traffic .
• Hierarchical reconstruction , In the early stage, we should focus on the big and let go of the small , The time-consuming, labor-intensive and problem prone framework syntax conversion （vue to react） It should be implemented by scripting , Realize the transformation of maintaining the overall structure and reference relationship in file level and various classes .
• The detail syntax is batched through a custom script （ such as  vue  In Chinese  class  Of  key  And string form  value  convert to  react  Medium  className  And variable form  value）.
• To ensure efficient self-test after migration, the corresponding  *.vue  File retention , Think of it as  doc  file , Delete after the entire migration , To improve the efficiency of migration and testing . Pay attention to transformation  lint  Rules ignore the detection of such files .
• In the process, the files are migrated together , Yes  “ Namespace isolation ”, Pay attention to maintaining the relative relationship of the overall directory structure , Do overall migration , And do not pollute the existing documents in the target warehouse , Prevent files with the same name from being overwritten .

• Through the above three steps, each warehouse code is migrated to  repo A  after , Sync   The latest updates in the three warehouses .repo C  To  repo A  In the process of （ from  V1  Cut out branches ）,repo C  The code is still being updated ,repo A  Also need to  repo C  Medium  V1.
  、V2、V2.
    Code in （repo B  also ）. Because the code is in different repositories , Manual consolidation is required .
  Tips
  ： Can be in  repo C  Lieutenant general  V1.
  、V2、V2.
    The multiple  commits  Synthesis of a  commit, Summarize all change items to one place for batch update .

• repo A  in  SSR  The scheme research and application are also in parallel . The newly migrated pages in the refactoring should be consistent with  SSR  Do integration .

2.3  Refactoring and integration practices

2.3.1  Warehouse  B  Page sorting and migration

This part of the transfer is carried out in isomorphic languages , And the number of pages involved is small , Mainly through human migration .

 

2.3.2  Warehouse  C  Page sorting and migration

• Online traffic query , Exclude useless pages
• Routing statements in the three code repositories determine the total scope
• Determine the past based on Alibaba cloud logs  3  Months 、2  Months 、1  Months of  PV, Will not  PV  Pages of are removed from the page pool to be migrated .
• Be careful  1:  Alibaba cloud  SLS  Logs are based on reported data , Data may be lost in the reporting and statistics process , Therefore, two query entries are integrated to determine and troubleshoot .
• Be careful  2:  For having  1-2  individual  PV  The page of , It may be caused by the research conducted in the early stage of the team's internal development , After confirming the visitor, discharge  “ test ”  produce  PV  The page of .

 

• Determine the final reconstruction scope （27  Filters  13  individual ）. Will step  1  The total range obtained in step  2  No users in  PV  Page culling .

• Heterogeneous language transformation and processing
• Warehouse  C  in  Vue2  Convert to warehouse  A  Medium  react
• Tool conversion

This is mostly used here  vue-to-react, However, the tool has many constraints and limitations , About half of the code has been converted successfully , If the conversion fails, you need to write your own script . The original intention was to encapsulate and transform the source code of the library , After looking at its implementation, I found that the cost of customization was higher than the cost of writing scripts, so I gave it up （ I am  vue  Less than a month's experience ）, Time is too tight to study carefully .

Tips

： Avoid making wheels repeatedly , When performing tedious and repetitive actions , Consider embracing the wheel within the team 、 Community and open source , If you don't have one, you can do it yourself .

 

• Script conversion

• transformation
• Project directory structure design and file mapping process

// step1： Keep the relativity of the overall directory structure unchanged

.

├── apis

│ ├── community.ts

│ ├── h5community

│ ├── ...

├── components

├── pages

│ ├── h5community

│ │ ├── App

│ │ ├── api

│ │ ├── asset

│ │ ├── components

│ │ ├── config

│ │ ├── filter

│ │ ├── live.js

│ │ ├── main.js

│ │ ├── mixins.js

│ │ ├── router

│ │ ├── style

│ │ ├── utils

│ │ └── views

│ ├── community

├── utils

└── ...




// step2: foo.vue The file to  foo/  Catalog , The templates are mapped to jsx And less file

.

├── apis

│ ├── community.ts

│ ├── h5community

│ └── ...

├── components

│ ├── h5community

│ └── ...

├── config

│ ├── h5community.js

│ └── ...

├── pages

│ ├── community

│ └── h5community

│ ├── column //  primary  column.vue  Convert to directory , Split into index.tsx And index.scss

│ │ ├── index.local_js // index.local_js Reserved as a comment , Reference for testing regression

│ │ ├── index.scss

│ │ └── index.tsx //  The first line is automatically inserted into the pair  index.scss  References to

│ └── ...

└── utils

 ├── h5community

 └── ...

• Step by step conversion  1:  File level

about  vue-to-react  Processing failed pages , Generate page template file through script .

//  The file before conversion is  foo.vue


//  After the transformation ：
.
└── foo
 ├── index.jsx
 ├── index.local_js
 └── index.scss

The content structure of the file generated by custom script conversion is as follows ：

 

• Step by step conversion  2:  Grammar level  - html lang

Vue  There are many in the process of file conversion  lang="pug"  Class template , Through the tool  

https://pughtml.com/

  convert to  “ class  jsx”  Template （ All the things about chicken ribs and human flesh , First think of tools , If you can't find it , Might as well  Google  Try different keywords in , Instead of doing it manually ）.

//  Before conversion  foor.vue  in

<template lang=&quot;pug&quot;>

 article.modal-wrap(@touchmove.stop.prevent @click.stop='close')

 section.modal

 p.more  More highlights ,  Just get something App

 p.slogan  Poisonous movement  x  Trend  x  Good thing

 .enter-btn(@click.stop='enter')  Enter the object App

 aside.close(@click.stop='close')

</template>







//  After the transformation  foo/index.jsx  in

<article class=&quot;modal-wrap&quot; @touchmove.stop.prevent=&quot;@touchmove.stop.prevent&quot; @click.stop=&quot;close&quot;>

 <section class=&quot;modal&quot;>

 <p class=&quot;more&quot;> More highlights ,  Just get something App</p>

 <p class=&quot;slogan&quot;> Poisonous movement  x  Trend  x  Good thing </p>

 <div class=&quot;enter-btn&quot; @click.stop=&quot;enter&quot;> Enter the object App</div>

 <aside class=&quot;close&quot; @click.stop=&quot;close&quot;></aside>

 </section>

</article>

• Step by step conversion  3:  Grammar level  - className  etc.

The file generated by the above script lies in file level conversion , Syntax differences need to be resolved by scripts . such as  class  Replacement and parsing of . here  html  The regular parsing of attributes is tedious , When implementing, I will think about where there will be , It's natural to think of  vue  There must be this regular in the source code of （ The framework is to parse and do native mapping ）, After checking, I was sure , A little modification will do , Then do some customization （ Template code in business code , Such as  import style  These are automatically generated with scripts for on-demand inserts ）.

// foo.vue  Writing method in documents  

<div class=&quot;var1&quot;>demo1</div>

<div class=&quot;var1 var2&quot;>demo1</div>







// foo/index.jsx （react in ） Writing

import style from './index.scss'

import classNames from 'classnames'

...

<div className={style[&quot;var1&quot;]}>demo1</div>

<div className={classNames(style[&quot;var1&quot;], style[&quot;var2&quot;])}>demo1</div>

• Page by page debugging and proofreading

• Differences in warehouse technology selection
• umi  Routing rules and customization

• Third party component library

• Such as  Swiper、postcss-px-to-viewport  etc. ,vue  Edition and  react  There are some differences in the edition , Incomplete documentation , Embrace source code and community . among  postcss-px-to-viewport  Use different... In different warehouses  viewportWidth  Set up , In the conversion process, different path ranges are processed for different plug-in instances

• Basic skill ： Sensitivity （ This has something to do with experience ）. What is the library location ？ How about maturity ？ What should be supported and what should not be supported ？ How would you design it if you designed it yourself （ Sometimes even if the documents are incomplete , You can push out a lot of content without looking at the source code ）？ Where to find solutions ？ How to find ？

• transfer  home  Page configuration
• Zoom out in the process  home  Path range of the page , hide  repo A  Access path in , Only the path to be migrated , Improve search efficiency

• Migration process record （ Test data and path, etc , Facilitate cross testing and  QA  Return to ）

• Coverage self test . Multiple business logic in one page , Sufficient self-test shall be carried out for each path in the future

• Design and change path of directory and file structure during migration （ important ）

2.3.3  Integrate  repo A、repo B、repo C  Refactoring branch code

• repo B  Pages in migrate to  repo A  in , If used  chore-repoB  Branch

• repo C  Pages in migrate to  repo A  in , If used  chore-repoC  Branch

• take  repo A master  Branch   and  chore-repoB、chore-repoC  Merge and resolve conflicts , The merged branch is recorded as  chore-repoA-repoB-repoC, At this time, the branch has only  V1  Code for , The iteration function of the current version of each warehouse and that of the previous version  hotfix  Has not been merged into this branch .

 

2.3.4  Integrate  repo A、repo B、repo C  Iterative branch code in

The iteration function in each warehouse is basically stable in the afternoon of the day before the main version date ,bug  Has converged . At this point, the development branches of each warehouse can be divided into local branches  feat-foo、feat-bar  And so on  pre-release-temp  Branch （ Already contains  master  Upper  hotfix）, namely  pre-release-temp  Branch   yes  V1.

、V2  A summary of , Set the... Of this branch   The incremental  commits  Synthesis of a  commit  obtain  V1.

、V2  Affected document changes . Manually synchronize these changes to  repo A chore-repoA-repoB-repoC  On the branch .

 

2.3.5  Integrate three warehouse business codes with  SSR  Code

Community  C  End  SSR  After the transformation scheme is determined , A new  A-SSR  Warehouse . Use  SSR POC  The content of the framework is correct  A-SSR  The warehouse is initialized , then  repo A  in  chore-repoA-repoB-repoC  The code in is migrated to the repository . Problems encountered ：POC  The original has been corrected  repo A  Some of the modules in  SSR  transformation , Migrate the new code to the warehouse. Note that the file coverage code is missing , use  cp  then  git diff  And artificial  check  Change the source of documents before submitting .

 

Wait until the middle of the version day  1  God  +  Generated by each warehouse  bugfix  Synchronize to  A-SSR  Warehouse , Make sure the code is not lost

.

 

3.  External coordination of project promotion

 

3.1  test

Extensive refactoring requires adequate testing , Considering the occupied test resources , Test as early as possible  leader  Communicate resource needs . in addition , The front-end interior shall be fully self tested before moving .

3.2  Operation and maintenance

 

Plan ahead   Page redirection scheme （ Will eventually cross warehouse  /  Apply migrated page redirection ）, Pay attention to the impact of changes on the operation and maintenance side , Once a change is made , The relevant is not available in the corresponding test environment （QA  It takes time to return , During this process, if redirection is enabled, it will affect the use of corresponding pages in the environment ）.

 

3.3  Problems encountered

When planning and starting refactoring , No one on the team is interested in all three involved  C  The end warehouse is familiar enough . When moving to the second page , It is found that there is no online traffic on any page  dead code  when , Re communicate with clients, O & M and other students , Finally, you can query Alibaba cloud  sls  Logs narrow the scope of migration , Nearly half of the workload has been reduced . Various technical problems encountered in the process , We still need to accumulate more at ordinary times .

4.  summary

 

The reconstruction of complex projects is the foundation of R & D 、 Experience 、 There are certain requirements for the specification and coordination of all parties . You can read it several times at the beginning 《 restructure 》 The foundation has been laid , Step into the code module 、 Simple projects 、 Complex projects 、 Reconstruction of cross team complex projects , Accumulated experience . Plan ahead （ Overall scheme on the technical side 、 Technical problems are predicted in advance 、 Overall promotion plan 、 Participation of interested parties, etc ）, Think comprehensively and carefully during the process, and continue to repeat the adjustment , Summarize and precipitate after the process .

 

Design well in advance 、 regular  Code Review、 Continuous refactoring during and after the process can make the project code more maintainable , The team keeps the habit of refactoring while accumulating refactoring experience , It can improve the health and maintainability of the project as a whole . Refactoring visible improvements is key , Grow in restructuring , Benefit from refactoring , Benefit from refactoring .

Related links ：

• https://pughtml.com/

 

*  writing  / SHI FEI

Focus on Technology , Be the most trendy technical person ！