There are three broad categories of programming efficiency: Tasking To Action, using efficient development tools/frameworks, and focusing on efficient engineering practices.
Among them, the task disassembly, we introduced in [Practical TDD(2): Tasking To Action] (video version).
Tools/frameworks for development efficiency have emerged, such as Spring Boot, Spring Cloud, Elasticsearch, Intellij IDEA, etc. to provide efficient tools for different areas of development.
Engineering practice also involves a lot, such as: TDD, refactoring, Clean Code, etc.
in the past work experience, i have found that many developers only focus on the improvement of tools to development efficiency, and when it comes to how to write good code, they are not able to talk like tools/frameworks, and the reason is that they do not pay attention to this content.
this article will talk about one of the great tools for improving programming efficiency: refactoring.
why can refactoring improve development efficiency?
there are five main reasons:
- refactoring can continuously guard the structure of the code, avoiding design corruption.
- refactoring makes the code easier to understand
- refactoring speeds up programming
- Refactoring reduces bug fix time.
- refactoring provides a faster ability to respond to change.
01 refactoring can continuously guard the code structure and avoid design corruption.
the loss of code structure is caused by accumulation, the more difficult it is to understand the intention of the code to express, the more difficult it is to protect the design in the code, the faster the original design will be lost, the faster the design will be corrupted.
small-step refactoring can continuously improve the key problems of the code, and the code of the “big mud ball” can be maintained through a small refactoring action, or the refactoring structure set is clear, so that the code that originally has no design can more clearly express short-term intentions.
ONE REASON WHY DAY-TO-DAY WORK MAKES REFACTORING UNSUSTAINABLE IS FOR SHORT-TERM PURPOSES. SHORT-TERM PURPOSE IS IMPORTANT, LET’S ALWAYS FOCUS ON IMPORTANT AND URGENT TASKS, BUT THE PROBLEM IS “ONLY FOCUS ON SHORT-TERM PURPOSES AND IGNORE LONG-TERM PURPOSES”. WE CAN MAKE ROI HIGHER THROUGH TECHNICAL DEBT, BUT WE ALSO NEED TO FOCUS ON LONG-TERM ROI. THEREFORE, IN OUR DAILY WORK, WE CAN USE VISUALIZATION AND OTHER MEANS TO MAINTAIN THE HABIT OF REFACTORING, SO AS TO AVOID MAKING THE CODE THAT WAS ORIGINALLY SPENT ON BECOME THE CODE THAT IS CORRUPT IN OTHER PEOPLE’S MOUTHS.
02 refactoring helps code be more easily understood
it is like the definition of refactoring: improving its internal structure without changing its behavior, thereby increasing comprehensibility and reducing maintenance costs.
we all know that the result of refactoring produces code that is readable and echoes the business context.
in fact, the process of refactoring can also make the code easier to understand, and it is easier to understand the intention of the original mudball code. while reading the code, while talking about the bad smell of the code found, the bad smell of the code is eliminated, and after reading the code, there is a clearer code result.
there is a sentence in the book “reconstruction”:
Ralph Johnson describes “early refactoring” as “wiping dirt from glass windows so you can see farther.”
03 refactoring can increase the speed of programming
a person/team doesn’t just write a method, a class, an interface and it’s over. it’s about going through weeks, months, or even years in a project. continuous refactoring over the course of a project continuously improves the design of the code and makes it clean. teams don’t dare or be reluctant to change a piece of code because it’s obscure (because it takes a lot of time to do something with a low output, but it’s hard to do).
i believe that many teams encounter legacy code, and those codes that are scattered everywhere with bad smells are precisely because such code makes development inefficient or even stagnant.
refactoring speeds up programming and is not hard to prove. through the results of several iterations of the output can be easily proved, compared with the team without refactoring, the team with partial refactoring, the continuous refactoring of the team after several iterations of the output results, it will be found that the continuous refactoring of the team output of each iteration of the results are relatively stable, and the output structure without refactoring will be less and less, and even can not respond to the needs of the business.
some of the developers i met were even opposed to refactoring, even more extreme. the problem is often that it is not clear how to refactor, how to refactor, how to use refactoring tools, and what the refactoring is actual. knowing this knowledge can make refactoring more effective.
refactoring also does not advocate the extreme “pure refactoring, refactoring for the sake of refactoring”, in the face of the priorities of tasks in real work, refactoring also has its own principles, such as “three things, three refactorings”.
04 Refactoring reduces bug fix time
imagine the ease of finding a bug in a large lump of code and fixing it, or the cost of locating a bug in clearly structured, well-intentioned code and fixing it.
i believe that most of the cases are the latter. the result of refactoring may be to generate some small methods, classes with a single responsibility, code with the same hierarchy, in such a code, do not have to worry about not understanding and dare not change, read the code can be modified. each bug has a small context and a small scope of impact from the modified code. the total repair time is certainly small.
05 refactoring can provide a faster ability to respond to change
one of the phrases often heard in work now is “embrace change.” how can developers embrace change? working overtime? it can only be said that the spirit is commendable, but the method is not right.
refactoring produces a code design that continues to evolve and eliminate bad smells from everyday code, so when new requirements arrive, or crude oil requirements need to be updated and adjusted, the original refactored structure can help the team improve the responsiveness of changes in requirements.
it is also a complex business, and the more reproducible and responsive the ability to reuse and respond to a clear code design.