01 — Take the road to refactoring

Writing in the front

As you know, as the code is piled on top of each other, the project gets bigger and heavier, and the quality of the code gets worse. The deadly result of piling up code is that it becomes illogical, difficult to maintain, and less readable, which increases the cost of understanding and communication, and refactoring is like planting trees on Mount Everest.

The main reasons for the difficulty of reconstruction are as follows:

• Programming, but not programming
• Without code quality oversight, the project degenerated from rigorous engineering into haphazard behavior
• For cost reasons, continuous development is carried out on the basis of original code
• Lack of code review habit, can not always review the refactoring code

There is an ancient saying, “Always wipe frequently, do not cause dust”, which tells you that I should always clean the dust, do not let it catch dust. The same is true of all the code we’ve written; good code is pleasant to watch, and bad code is hard to swallow. Refactoring: Improving the Design of Existing Code by Martin Fowler is a great book to read. Now follow me on the road to refactoring.

What is a refactoring

In refactoring, the author defines refactoring as:

Refactoring, n: An adjustment to the internal structure of software to improve its comprehensibility and reduce its modification costs without changing its observable behavior. Refactoring (verb) : The use of a series of refactoring techniques to adjust the structure of software without changing its observable behavior.

In my understanding, refactoring is the effective design of existing code.

“Restructuring” and refactoring: Restructuring generally refers to various forms of reorganization or cleanup of existing code, while refactoring specifically refers to adjustments to a specific class structure.

Refactoring and performance optimization:

• Similarities: Both need to modify the code, and do not change the overall function of the program.
• The difference: Refactoring makes existing code “easy to understand, easy to modify,” regardless of performance. Performance optimizations focus on making programs run faster, but the code can be difficult to understand and maintain.

As the saying goes, “you can’t have your cake and eat it,” this is sometimes true of reading comprehension and performance.

Why does refactoring

In the project development, will there be such a split behavior, allocating their time to adding new functions and refactoring, when adding new functions, they find their code is not organized and difficult to understand, and when refactoring, they find their code does not add new functions and cannot exceed KPI?

• Refactoring improves software design: Refactoring is a macro adjustment of project code, not a short-term action. Frequent refactoring helps keep the code in its proper shape.

• Refactoring makes software easier to understand: unrefactored code may be machine-readable but not human-readable, and refactored to make it easier for both machines and humans to understand.

• Refactoring helps find bugs: When refactoring code, you need a deeper understanding of the structure of the code to write more robust code.

• Refactoring improves programming speed: Refactoring allows code to add new features later and saves time reading code.

When refactoring

• Pre-refactoring: Make it easier to add new functionality: The best time to refactor is to separate the logic for updating data from the query logic before adding new functionality. It is easier to avoid logic entanglements that cause errors.

• Refactoring for understanding: Makes code easier to understand: Refactoring leads to a higher level of understanding as we read code, and a deeper understanding of the code’s underlying logic. Just like standing in the window to see the distant scenery, dust can make us see farther and clearer.

• Garbage refactoring: When you understand what the code is doing, but it’s not doing it well enough and the logic is confusing and complex, you need to decide whether you want to remove the code junk or keep the business developing. In fact, you can prioritize the things that are easy to refactor, and deal with the things that are hard to get back to later.

Preparatory refactorings, understanding refactorings, and garbage refactorings are all improvisational, with no specific time planned for specific refactorings, but refactorings as problems are found during development. However, if the team has neglected to refactor code in the past, a dedicated period of time may be required to refactor the project code, which can be a huge and time-consuming task.

Be careful not to interpret a refactoring error as an attempt to fix a past error or clean up dirty code, when refactoring is necessary. However, beautiful code also needs to be refactored, because there are many trade-offs in programming, such as how much to parameterize, what code to use to decouple, and improve robustness. In addition, writing code is not a simple code accumulation process, but after refactoring existing code to add new features, can be twice as effective.

• Long-term refactoring: Code refactoring is a long-term macro process, so don’t break code logic for short-term goals.

• Refactor when reviewing code: Code review improves development, helps spread programming knowledge, and helps less experienced developers learn lessons that benefit the team. Refactoring helps review other people’s code, leading to better results.

• When not to refactor Code: This means that not all code needs to be refactored, and this needs to be done with good judgment and experience.

Bad code smell

Literally, the bad smell of code is that code with redundant logic stinks and is long and stinky, so discard and refactor.

Common bad taste codes abound, such as strange naming practices. Beginners in programming learning, often code files, variables, functions and so on the name of all kinds, no rules, desultorily, can not play to see the effect of the name. So a good name is very key, can let people know the meaning of the name, easy to understand.

Here’s a summary of common bad taste codes:

• Strange naming method: can not do by name know meaning
• Code duplication: When the implementation logic and execution flow of the code are similar or the same, it can be extracted
• Overlong function:
  • Statements in function methods do not share the same level of abstraction
  • The logic is messy and requires a lot of comments to understand
  • Object oriented programming is not implemented
• Too long argument list:
• Global data and mutable data
  • Global data: any corner can be modified, can not be detected, easy to error
  • Mutable data: Data modification often results in unexpected results and hard-to-find bugs
• Too much class
  • The more you do, the more likely you are to make mistakes
  • Too many fields, instance variables, and methods can lead to repetitive, confusing code
  • The naming of the class is not enough to describe what is being done
• The logical confusion
  • Divergent variation: a module often changes in different directions for different reasons
  • Grape-shot change: For every change encountered, it must be modified in multiple classes
• Attachment: Over-reliance on modularity of code, resulting in higher logical complexity than inter-module communication
• Pure data classes
  • Contains only fields and methods to access (read and write) those fields
  • This class is called a data container and should be kept to a minimum of variability
• Data mud-blobs and basic types of paranoia
  • Data blob: Two classes or method signatures that contain the same field or parameter
  • Base type paranoia: You should use classes but use base types, such as the Money class for values and currencies, and the Range class for starting and ending values
• Duplicate switches: When adding a selection branch, all switches must be found and updated one by one
• An irrational succession system
  • Inheritance breaks encapsulation and subclasses depend on the implementation details of a particular function in their parent class
  • Subclasses must evolve as their parent class is updated, unless the parent class is specifically designed for extension and is well documented
• Too much conditional judgment
• Too long parameter column
• Too many temporary variables
• Confusing temporary field
  • An instance variable is set only for a particular case
  • Extract the instance variables and corresponding methods into the new class
• Pure data classes
  • Contains only fields and methods to access (read and write) those fields
  • This class is called a data container and should be kept to a minimum of variability
• Too many comments: When too many comments are needed, it means that the code needs to be refactored

The common problems with bad code are that it is difficult to reuse, not robust, difficult to understand, and difficult to test.

So what’s good code?

Code is evaluated in terms of code quality, the most important metrics being: maintainability, readability, and extensibility. To write high-quality code, we need to master some more detailed, more practical programming methodology, which includes object-oriented design ideas, design principles, design patterns, coding specifications, refactoring skills, etc.

Refer to the article

Common Code Refactoring Tips

Refactoring — Improving the Design of Existing Code (2nd edition)

Write in the last

Thank you for reading, I will continue to share with you more excellent articles, this article reference a large number of books and articles, if there are mistakes and mistakes, hope to correct.

More latest articles please pay attention to the author digging gold account and public number front gravitation.