The fuse

I need to add filter condition caching function to all query pages. I looked at the existing code, and found that each page has a lot of redundant code about local and remote storage, and the storage logic of each page is slightly different. I thought for a long time, but I didn’t write down a line of code. As I got out of my seat, I kept wondering what was holding me back, and it all came down to one thing — the lack of a common process.

Think about why

Lack of communication

In the product stage, the project was positioned as an implementation query platform, with multiple query pages and different query function points on each page. My partner and I were in charge of the development of a query page. Due to the tight time and heavy task, we did not do the overall planning of the project, did not formulate norms, directly open the line code, at the beginning to dig a big hole for themselves.

Lack of experience

At that time, I was still working as an intern, and I had only done some small projects. Both my understanding of the framework and my project experience were hard hurt, which was reflected in the following aspects:

  1. Over components, there can be a crazy “there shouldn’t be native HTML at all, and wherever there is, it needs to be wrapped into components.” Wrapping for the sake of wrapping results in pages that end up rotting and you have to find components for a long time.
  2. There is no overall view, the idea of writing code is limited to the current page, not taking into account some of the global common flow.
  3. The understanding of the framework is not deep enough, and many uses are copied by open source projects without thinking of their own inside.

Refactor what needs to be covered

Especially important for large projects, refactoring should be a safe and efficient way to rewrite code that is specific to local content. This was where I stumbled. The refactoring project was so complicated that I rewrote 80% of the code, refactoring multiple feature points at once, and the number of change points after the refactoring exploded to the point where I felt I was out of control. At the same time, too many functional changes also bring great trouble to the test, need to spend a lot of time to do an overall regression test. This is why the first week of the refactoring project was full of bugs.

Therefore, function points must be determined before reconstruction. It is better to reconstruct a single function point rather than multiple function points at a time.

Refactoring approach

The core of this refactoring is to extract redundant logic into the global generic process and make full use of:

  1. Vue – the router hooks
  2. The Vue mixin
  3. The interceptors Axios
  4. Seamless integration of Vuex and localStorage

This, like a system, provides a common process flow for the entire project

In hindsight

I regret not reading Refactoring — Improving the Design of Existing Code first if I had known:

  1. Refactor rather than rewrite, and resist the urge to start all over again
  2. Do one thing at a time when refactoring to avoid involving multiple function points

I wouldn’t have rewritten 80% of the code on impulse, or multiple complex feature points at once