Bad code smell and refactoring

: Notebook: This article is filed under “blog”

• Disease and medicine
  • Thoughts on the bad smell of code
  • Principles of refactoring
• Bad code smell
  • Code bloat with bad code smell
  • Bad taste of code abuse of object orientation
  • Barriers to code bad taste change
  • Code that doesn’t necessarily smell bad
  • Coupling of bad code smells
• Further reading
• The resources

When I first read Refactoring: Improving the Design of Existing Code, I put together a simple note. Recently, I reviewed refactoring: Improving the Design of Existing Code while working on a refactoring project. In the process, the germination of a serious summary, reorganization of the method of impulse, so have this series of text.

There are still several unfinished articles on bad code smell, which I will fill in later…

Disease and medicine

Thoughts on the bad smell of code

“Early treatment of illness, do not give up treatment”. What a simple truth everyone understands.

Sick, not healthy.

The person is sick, can undertake treatment through inject, take medicine, do an operation.

If bad code smell (code quality issues) is a disease, then refactoring is the cure for bad code smell.

In my opinion, the principle of healing can also be applied to reconstruction:

• Better prevention than cure. Bian Que, a famous doctor of the Spring and Autumn period and the Warring States Period, once had a very famous medical proposition: prevent disease before it is done. I think the same applies to refactoring software code. There should be reasonable design before programming and good programming style when programming to minimize problems. In this sense, understanding bad code smells is not just about finding problems and solving them. The more important role is to guide us to consciously avoid these problems in the programming process.

• A little ailment cures nothing but a great one. — Liu Bei said: “Good is not small but do not do, evil is small and do.” Find problems on timely modification, code quality naturally easy to enter a virtuous cycle; And vice versa. Pay attention to the accumulated power, don’t always think that the code has a little problem, that is not a problem.

• Take the right medicine. – The program has problems, to analyze the root of the problem, targeted to formulate a reasonable reconstruction program. We all know what happens when you take the wrong medicine.

• Avoid fierce medicine – medicine with fierce medicine easy to produce side effects. In other words: a big step is easy to pull the egg. If you do it aggressively, you should be prepared to throw yourself at any time. Starting from scratch is not refactoring, it’s rewriting. Refactoring should be a gradual, step-by-step process. When you find it easier to rewrite code than refactor it, it’s often a sign that you should have refactored it a long time ago.

Principles of refactoring

I compared code quality problems to symptoms and refactoring to medicine. Let’s take a closer look at the principles of refactoring.

What is Refactoring

Refactoring is commonly defined as improving the internal structure of a software system without changing its external behavior.

Personally, I find this definition a bit awkward. Refactoring is the act of healing code. Code sickness refers to the quality (reliability, security, reusability, maintainability) and performance of the code.

The purpose of refactoring is to improve the quality and performance of your code.

Note: Incomplete or incorrect, that is a disabled code. Just as a cure does not cure a disability, reconstruction does not solve a functional problem.

Why refactoring

Do a book search, and the reasons for refactoring are pretty much the same:

• Refactoring improves software design
• Refactoring makes software easier to understand
• Refactoring helps find bugs
• Refactoring improves programming speed

In short, refactoring improves code quality.

When to refactor

As for when to refactor, LET me first quote the idea that refactoring is not how to do it, but when to start.

For a fast growing company, stopping business development and focusing on reengineering projects is never an acceptable option. “Change engines while flying” is what the company wants.

Let’s measure the costs and benefits of refactoring.

• Cost of refactoring

  Refactoring is costly, time-consuming (time, labor), and can cause errors in otherwise normal programs. So, a lot of people are holding “do not seek merit, but seek no fault” psychological muddle along.

  There is also a cost: refactoring uses newer and more complex technology, the learning curve is not smooth, the technology switch is difficult for team members, and development efficiency may decrease rather than increase in the short term.

  However, if the code is allowed to rot, the technical debt becomes heavier and heavier. When the code finally runs out of time, architects are often forced to take radical measures to cure the code. But the process is often painful and carries a high risk of failure.

• Refactoring benefits

  The benefits of refactoring are improved code quality and performance, and improved development efficiency in the future. However, it should be noted that refactoring often doesn’t bring real benefits in the short term, or that benefits are hard to visualize. And for an enterprise, nothing is more important than efficiency. In other words, what has no real benefit is usually of no value. Many leaders, especially non-technical ones, don’t care what new technology you’re applying, how elegant your code is, etc.

• The right time to refactor

  From this point of view, refactoring is a thankless task.

  As a result, many people succumb to evil KPIs and deadly deadlines, teasing that their old code is garbage while creating garbage themselves.

  However, ** refactoring should be a gradual process, not only the breaking of the transformation is called refactoring. ** If you wait until your code is rotten to death before aggressively refactoring it, it will be difficult and risky.

  The refactoring book mentions refactoring as a time to add features, fix features, and review code, and does not recommend taking time off for refactoring projects.

  The idea, I think, is that refactoring should be a real-time, evolutionary process during development.

• Bad timing for refactoring

  However, I want to emphasize here that not all software development processes need to be refactored.

  Scenarios that highlight the value of refactoring are those where the code is larger, has a longer life cycle, takes on more responsibility, and has a large (and less stable, and highly mobile) team working on it.

  On the other hand, there are some scenarios where the value of refactoring is minimal:

  • The codebase is nearing the end of its life cycle, and development is winding down in favor of maintenance.
  • When the current version of the code base is about to be released, refactoring is a recipe for trouble.
  • The cost of reconstruction is too heavy: the correctness and stability of functions after reconstruction are difficult to be guaranteed; The technology is too advanced, and the technology migration of team members is too difficult.

How to Refactor (How)

Refactoring, in my opinion, can also be hierarchical. From high to low, the higher the level, the more difficult:

• Modern software often has complex and huge business. Using microservices and data migration to split business and reduce business complexity has become the mainstream. However, the testing and deployment of these technologies are complex and technically difficult.

• Component, module, framework component, module, framework refactoring is primarily a design problem for code. It addresses the overall structure of the code. A good understanding of frameworks, design patterns, distribution, concurrency, and so on is required.

• Classes, Interfaces, functions, fields Refactoring mentions ** the “bad smell of code” ** and related refactoring methods. These are methods of refactoring code at the class, interface, function, and field levels. Because the reconstruction method at this level is relatively simple, it is highly operable. Read the bad Taste of Code chapter for details.

The first two levels of reconstruction have been involved in the architecture level, with great influence and high difficulty. If you are not skilled enough, do not change easily. Since these two levels cover a wide range of fields, they are not discussed here.

Here is the dividing line. Here’s a list of code bad smells…

Bad code smell

Refactoring: Improving the Design of Existing Code covers 22 bad code smells and refactoring techniques. These bad smells can be further categorized. I’ve always found that categorizing things helps to understand and remember. So this series breaks down bad smells by their characteristics and goes through them one by one.

Code bloat with bad code smell

Code BloatedThis set of bad smells means that classes, functions, and fields in your code are not properly organized, but simply stacked. This type of problem is usually not obvious in the early days of the code, but accumulates as the code grows in size (especially if no one is trying to root them out).

• Too long to function
• Too much class
• Basic type paranoia
• Too long parameter column
• Data mud pie

Bad taste of code abuse of object orientation

Object Orientation AbusersThis set of bad smells means that the code partially or completely violates object-oriented programming principles.

• The switch statement
• Temporary field
• A rejected gift
• Classes of the same kind

Barriers to code bad taste change

Preventers of ChangeThis set of bad smells means that when you need to change one piece of code, you find yourself having to change something else. This makes program development complex and expensive.

• Divergent variation
• Shotgun modification
• Parallel inheritance system

Code that doesn’t necessarily smell bad

DispensablesThis set of bad smells means that such code is unnecessary, and that its presence affects the overall cleanliness and readability of the code.

• Too many comments
• Duplicate code
• Redundant class
• A purely childish data class
• Talk about the future

Coupling of bad code smells

Coupling (Couplers)This set of bad smells means there is too much coupling between different species.

• Attachment bond
• Inappropriate intimacy
• Over-coupled message chains
• A middleman
• Imperfect library classes

Further reading

• Bad code smell and refactoring
• Code bloat with bad code smell
• Bad taste of code abuse of object orientation
• Barriers to code bad taste change
• Code that doesn’t necessarily smell bad
• Coupling of bad code smells

The resources

• Refactoring – Improving the design of existing code – by Martin Fowler
• https://sourcemaking.com/refactoring