The 12-piece system of architecture refactoring

Original Address:http://m.yuedu.163.com/reader/news/content.do?source_uuid=6a06e2c0-5865-4658-b609-c92ed95fadbd_1& Content_uuid=4a0b1390a22e439ab8c28d5ddff14a87_1&isappinstalled=1&from=timeline

May 11 00:00 Source: Infoq Chinese Station

"Note" Structure of the restructuring of the 12 military (on) after the release, some readers anxious to next, so here I put the upper and lower part of the merger into an article, so that you can read the full version, do not separate to see.

For developers, architecture design is the most important part of software development process, the so-called no drawings, can not build a house. In the internet age of ubiquitous apps, architectural design has some more mature patterns, and developers and architects can often learn from them.

However, as applications evolve, the initial architectures often face problems such as inability to meet customer needs, inability to implement application extensions, inability to implement new features, and more. In this case, how do we avoid some pits and try to achieve a more successful restructuring of the architecture is a problem that many developers and architects need to solve.

Here, I'd like to share with you the 12 rules of Uber's engineering director, Raffi Krikorian, with a few readings that I hope will inspire you.

Determine the purpose and necessity of refactoring

It seems that the rule is a little superfluous, but please don't ignore it. The refactoring of every architecture is "hurt –", and as with surgery, even if it succeeds, the decision makers first have to analyze the rationale for the architectural refactoring and other alternatives, and make clear that the refactoring is designed to meet business needs and is the best solution that has to be done before considering other issues. Sometimes, after analysis, you may find that there are other solutions, such as increasing computational resources, or refactoring is not intended for business needs, and there is no need to do so.

Checklist:

• What is the reason for architecture refactoring, to meet the needs of the business or just to think that the architecture is not good to look at?
• Are there alternatives to schema refactoring? Have you analyzed the pros and cons of these scenarios?

Define the boundaries of "refactoring complete"

If it is determined to be reconstructed, then the goal should be defined, that is, the reconstruction of the boundary conditions, how the "completion" of the reconstruction, the goal of data quantification, or there is a way to test. This is also a demand analysis process, if the requirements are not clear, then the specification can not be written clearly, the team responsible for restructuring has no clear goals, not to reconstruct the time or subjective judgment as the basis for the end. A few days ago and a friend chat, he recently in charge of the performance of the system optimization, but also to do some refactoring things, the beginning of the team's goal is not clear, we do not know how to optimize to what extent, so do not dare to start. If the goal is to increase by 10%, you can start with the details, and if you increase by 50%, it may take a big move to get it done. After the goal was clear, the team found the right solution.

Checklist:

• Can the goal of refactoring be quantified, or can it be tested?
• What are the criteria for refactoring to complete? Have you got the approval of the business unit or the leader?

Progressive refactoring

Now the most popular software development is rapid iteration, continuous delivery, early feedback. This can also be used in the refactoring of the architecture, the refactoring process is as difficult as building a new product, so in the design of refactoring, to introduce the continuous delivery process, each refactoring step or module to quickly deploy and get feedback, in order to assess the effect of refactoring, timely policy adjustment. Some readers will say that our architecture refactoring is drastic type, not progressive, can only be done overnight. If this is the case, consider refactoring in another set of copied systems, and after careful testing, migrate the data and the business past.

Checklist:

• Can the refactoring process be broken down into smaller iterations, with every improvement getting feedback as quickly as possible?
• Can the effects in the refactoring process be presented to the business unit or leader regularly?

Determining the current schema state

Before initiating refactoring, the team has a clear understanding of the current schema state, which is to set benchmarks to evaluate the effects of refactoring. According to my experience, the architect or developer who is responsible for refactoring, often does not understand the existing architecture design, began to refactor, the results often occur: refactoring to a certain stage, found that it does not work, and then a Pat head said, OH, the original structure is this kind of, is to meet the needs of XXX business, this block can not move , you have to think of another way. Similar examples often occur in research and development teams and remind us to be cautious. I remember a philosopher said, it is easy to understand others, it is difficult to understand themselves.

Checklist:

• Do you understand the current architecture design? Does it have the original design and the previous selection plan know?
• Can you set a benchmark state for the architecture?

Do not ignore data

The importance of data is self-evident, the business is based on data flow as the carrier, so the essence of architecture refactoring is the reconstruction of data flow. The importance of data to the reconstruction is mainly embodied in two aspects: in the reconstruction design, need to consider the requirements of business data, after the reconstruction of the system for data storage, processing, analysis and other functions have influence, in the reconstruction process, consider relying on data or even actual data to verify the effect of the refactoring, provide evaluation support.

Checklist:

• Are the requirements of business data reflected in the refactoring design?
• Can the actual data be validated during the refactoring process?

Manage technical debt.

Technical debt is also a prominent issue in the usual software development process, and is now singled out to remind developers that architecture refactoring is often about repaying technical debt, so don't make technical debt in the process of repaying technical debt. Technical debt, like a credit card, has a high interest rate, just as it leaves a lot of accounting overhead on the team. The organization should develop a culture that guarantees design quality. Refactoring should be encouraged, and ongoing design and other practices related to code quality should also be encouraged. Part of the development time should be specifically drawn up to address technical debt. Without proper care, the real-world code will become more complex and difficult to understand.

Checklist:

• Does the team have a tracking and memorandum mechanism for technical debt? Or are developers free to generate debt?
• Are there regular training and review mechanisms for technical debt?

Stay away from the vanity (for example, using the "hot" technology stack).

The refactoring process for architecture should be goal-oriented, in other words, "pragmatic". For the technical people, a frequently overlooked problem is that like chasing fresh hot technology, this is actually a good thing, the technical people to innovate, and constantly accept new technology. But for the critical task of refactoring the architecture, whether the new technology is not important, it is important to achieve the goal of refactoring. For the new technology, although the heat is big, but the talent reserve is not enough, we have not stepped on the pit is not much, the accumulation of failure lessons and successful experience is not enough, in this case, it is recommended that you do not have a hot head of the new technology, should be objectively and calmly evaluate the impact of new technology and mature technology on the restructuring Speak with data and experience rather than follow the bandwagon.

Checklist:

• Are there detailed data and expert evaluations of the reconstructed technology selection?
• Does the chosen technology have good talent accumulation and sufficient experience support? Did you experiment with mice?
• Are there at least two options to evaluate when choosing a technology? Are there any mature technical solutions?

Be prepared to face the pressure

This rule is more like a psychological suggestion for architects, and the pressure is everywhere in the software development process. For architectural refactoring, stress comes from multiple aspects: management, team members, peer departments, and so on. To be blunt, architectural refactoring is often a thankless thing for an individual. And to do a new product can be very high praise compared to the restructuring of the results are often not taken seriously by the leadership, and the problem has to bear a lot of responsibility. From a software development perspective, new products are made from 0 to 1, and the architecture refactoring is from 1 to 1, which is often more complex and difficult. Therefore, the reconstruction of the responsible person in advance to prepare psychologically, to relieve the pressure of a skill is to set a good milestone, the reconstruction of the results of quantification, and business changes associated with the regular synchronization of the status of stakeholders, get everyone's understanding and support.

Checklist:

• Is the refactoring of architecture supported by management, especially top management? Do they have a direct understanding of the time and task volume of the refactoring?
• Does your refactoring plan contain quantifiable results? Are these results regularly presented to management?

Understanding the Business

It seems like a piece of crap, but I think Raffi Krikorian deliberately put this to the point that there must be a reason. The ultimate goal of architectural refactoring is to improve the business, so understanding the business will help architects and technicians determine the priorities and critical paths of the refactoring goals. For example, we need to know which business-critical architectures are untouchable, which are interconnected, and which business architectures require priority refactoring .... Wait a minute. In addition to understanding the business itself, we also need to understand "people", ostensibly management is the arbiter of the reconstruction goals, but in fact the business sector is the person. Technology people need to understand their business needs and transform them into a refactoring goal. In this way, the meaning of architectural reconstruction can be concretely embodied.

Checklist:

• Is there enough discussion and confirmation with the business unit about the business objectives that the architecture refactoring can achieve?
• are key business and priority refactoring businesses confirmed?

Prepare to face non-technical factors

Well...... It's a less comforting suggestion. Whether you want to believe that technology is not the most influential factor in architecture refactoring (and other key corporate decisions), we also address business interests, management preferences, big customer impact, office Zhengzhi, queued issues, and so on, for architects and technology people, These factors are often not what they can control. What we can do is to set the refactoring goals with the stakeholders and then, depending on the impact factors, adjust the goals. Remember, do not die carrying this goal, when someone makes a different opinion, be honest with them and tell them how to adopt the opinion, then the refactoring goal will change, then let other stakeholders know the changes. The impact of non-technical factors is objective, and from the commercial level is also reasonable, so for technical people to learn to adapt.

Checklist:

• When non-technical factors influence the refactoring of the architecture, do you make adjustments to the goals and inform the stakeholders?
• Are you prepared to deal with the effects of non-technical factors in an open, rather than a resisted mindset?

Have some control over code quality

This is in the same place as the one mentioned in the previous article, "Managing good technical debt." The refactoring of architecture has a high requirement on code quality, on the one hand, the refactoring process is less tolerant to bugs than the development of new products, on the other hand, it also determines the difficulty of the next reconfiguration. There are a lot of books and articles about code quality here, just to remind you that code review is a very good idea. Code review is a necessary step in the software development process that can help the reviewer to refer to the code quality and allow the reviewer to deepen the understanding of the product. No matter how busy the team, it is important to ensure that the code is submitted before the other members of the review, in the short term will occupy the team's time, in the long run is a good thing.

Checklist:

• Are team members paying enough attention to the quality of the code? Is there a reward and punishment measure?
• Is there a standard document and review process for code quality within the team?

Prepare your team for the job

This is Raffi Krikorian listed the last of the military, is a summary of all the previous proposals, I do not read here, please feel yourself.

End

On the reconstruction of the architecture, Raffi Krikorian gave very good advice, but in the end there is no effect, or to practice the test. The letter is better than no book, the experience from the practice is the most valuable, for the technical people to use only meaningful.

The author's public number, "technical vane", focuses on it trends, carrying forward-looking, in-depth, temperature-focused content. Interested readers can search for Id:jishuqushi, or scan the QR code below to add attention.

The 12-piece system of architecture refactoring