Refactoring

1. What Is Refactoring?

Modify code without changing its external behavior in order to improve the program’s internal structure. In essence, refactoring means improving the design after the code has been written.

2. When Is Refactoring Needed?

When a maintained system has many pain points or things worth complaining about, refactoring is needed.

3. How to Refactor an Old System

3.1. Understand the Business Flow

Experience the business / historical requirement documents / prototypes. Read tag by tag. Top-down: capture traffic to inspect APIs, then trace downward from the APIs. Bottom-up: organize the relationships among data tables. Translate code into plain language. Add debug logs and test the logic step by step. When training newcomers, tell them exactly what to change and organize the documentation. After sorting it out, write FAQs and hold meetings to align clearly.

3.2. Understand the Architecture

The call relationships among services. Three layers: foundational services, business services, and external services.

3.3. Identify Problems

• Too many comments.
• A function or class has too many responsibilities.
• Duplicate code.

3.4. Solve the Problems

4. Patterns

4.1. Strangler Pattern

4.2. Anti-Corruption Layer Pattern

5. References

• Refactoring (1): Understanding Refactoring
• When Should Code Be Refactored?
• How to Quickly Become Familiar with Business and Code
• Thoughts on Writing Business Code - V2EX