I finished the first half of How to Do System Refactoring two days ago, and today’s content continues along the previous part. The top half has 4 points, so the bottom half has 4 points.

 

5. Use “iterative” refactoring

Those of you who have done refactoring know that the complexity of refactoring is no less than that of building a brand new product. After communicating with your friends privately, you are willing to do it all over again, rather than changing the old code. What I mean by this is that refactoring is not an overnight thing, and since that is the case, we need to consider breaking up a refactoring into multiple “iterations”, where each refactoring step can be quickly deployed and given feedback so that the refactoring can be evaluated and adjusted. From a project risk perspective, iteration risk can be effectively controlled by breaking the refactoring into multiple iterations so that the refactoring team (development and test) can focus on a little bit of each step and fully test it. If you directly reconstruct the version after 1 or 2 months, throw it to the test students to verify, the effect is obvious.

On the other hand, the refactoring process is less bug-tolerant than new product development, and the outcome of the last refactoring iteration determines the execution of the next iteration. No matter how busy your team is, make sure your code is reviewed by other members before it is submitted, which can take up time in the short term and be more productive in the long term.

There is no standard for how to split refactoring, but my personal opinion is that each refactoring should take no more than one normal iteration (2 weeks).


6. Refactor technologies familiar to the preferred team

In our reconstruction plan formulation process, the choice of the third party technical framework is important, it relates to reconstruct the final success or failure, after all, the final judgment of success for refactoring is online run normally, so popular is that the choice of the latest technology and mature technology development actually is not important, important is whether our team can handle this door technology, whether there is a corresponding talent pool, Are we aware of the “pitfalls” in the technology, and can we find the corresponding technical community to help us deal with the problems in the implementation process? Here is a painful lesson THAT I myself experienced. Two years ago, We chose the cache solution with the Redis Cluster, which we’re not particularly familiar with, as opposed to the regular Redis 2.x version, or The KVStore from Alicloud, where we have all kinds of craps, and each time we have to fix them afterwards, and it’s completely exposed that if you don’t know enough about the technology, you put it on the production line, There is a lot of potential risk, of course, if I go to Redis Cluster now, I am very confident because I have mastered it :). As for the selection of technology, we need to repeatedly confirm the influence and effect of various technical solutions on system reconstruction. We must have pre-technical research and get the corresponding research data, and make decisions according to the data and experience.


7. Communicate with the business side before reconstruction

Many technical team thought that refactoring is within the team, but I used to worked with multiple teams of the look, the idea is too naive, refactoring’s ultimate purpose is to improve business and undertake business better, so if not business do good communication, don’t even know the business began to do the refactoring, the result is probably not caught on, For example, we need to know which key business architectures cannot be easily touched and which businesses are interconnected. Therefore, my own technical team will fully communicate with the product team and operations team before implementing refactoring.

The purpose of communication with the business side is as follows:

  1. Understand the requirements of the business side, and put these points into the refactoring process, sort out the code, the operation of various businesses, understand the importance of each business.

  2. Seek support and help from the service side. During the reconstruction, actively communicate with the service to ensure that the reconstruction will not affect the service. On the other hand, only through communication can we get support and understanding from the business team to the technical team for refactoring, so that non-technical obstacles will not be encountered in the process of refactoring.



8. Focus on non-technical aspects of refactoring

Here are some of the things that I’ve figured out over the last year, and I want to take this opportunity to share with you:

Relieve the pressure of the team and give more encouragement to the team. To put it bluntly, refactoring is often a thankless task for individuals or teams. Compared with making a new product or new function, which can win applause from the boss or other business parties, the achievements of reconstruction are often not valued by the boss, and the boss will take great responsibility for any problems. Therefore, before the reconstruction, I will prepare the team psychologically in advance and help everyone relieve the pressure. Besides, I will associate the quantified results of the reconstruction with the changes of the business and synchronize the status to all parties regularly to get everyone’s understanding and support.

Communicate non-technical aspects of the refactoring process. Any major technical refactoring will encounter non-technical factors that are often beyond our control. What we can do is to communicate effectively with relevant stakeholders and communicate honestly with them. The influence of non-technical factors exists objectively and is reasonable from the company level. For technical personnel, they should learn to adapt to it.


Let me know if you have any thoughts or suggestions for refactoring.


The cover is another of my favorite refactoring books. It’s easy to read, introduces common patterns in refactoring, and provides valuable advice for those interested.


Scan for this subscription number: ForestNotes