Study with me for Code Refactoring ( Story1 — Introduction)

Refactoring the design ( crd image to Al Power™)

Refactoring is the process of restructuring code, not changing its original functionality. The primary purpose is

• To improve Software design, structure, and code readability
• To become clean code and simple design

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler (1999)

I am a fool but now I try to be a good developer. We already know this about already but we miss and forget to apply it to refactor the codes when facing business pressure, strict project timelines, etc...

Refactoring is not adding a new feature.

Refactoring is not fixing a bug.

Refactoring is not optimization.

Refactoring is making a series of small structural changes to improve the readability and maintainability of software without modifying existing behavior.

Let’s study with me from Refactoring Guru about Refactoring code

Clean Code

Every developer was talking about clean code. So, what is Clean Code? Clean-Code can be understood easily — by everyone on the team and then

With understandability comes readability, changeability, extensibility, and maintainability. Some of its features are —

1. Clean code is easy to see other Developers
2. Clean code contains no duplication
3. Clean code is cheaper and easier to maintain
4. Clean code passes all tests (have to test coverage 0%)

Technical Debt

Cause of technical debt are

1. Business pressure
2. Strict Project Timeline
3. Lack of Tests
4. Lack of Documentation to write
5. Lack of interaction between team members
6. Incompetence code

When to refactor

He said it is time to refactor when getting the rule of three

1. First time — get it done don’t think about it
2. Second time — something similar bug fixing for the second time, make short to have but repeating the same thing
3. Third time — start refactoring

and then

1. When adding features — Please refactor when you just finished the checkpoint. This is my bad habit and I am doing right now refactoring when I finish my implementation code like after implementing end to end UI screen
2. When fixing a bug — when you are fixing the bug, it was too complex and difficult to understand please refactor. If you have to deal with someone else’s dirty code, try to refactor it. When you are refactoring codes which was developed by another developer, you should carefully ask what is their purposes and should use pair programming ( You are the navigator and the author must be the driver)
3. During the code review — It’s best to perform such reviews in a pair with an author. In Local companies, don’t give a code review time. Code reviewing sometimes seems like discussing opinions and thoughts with the author. ( note — please respect your coworkers when you are in code reviewing, they can’t perfect all the time and you too)

Checklist of refactoring right away

• Ensure the code should become cleaner, and more readable when after refactoring
• New Functionalities shouldn’t be created during refactoring.
• All old test cases must pass after refactoring — If you are not the one who developed these features and codes are very outdated, you must request test cases from QA and ensure that all test cases pass for Every screen in which you are currently refactoring

This is the end of the study with me for refactoring the introduction. Next time we will study for code smell. Please give feedback or opinions and tell me when I was wrong.

See you next time bye bye👋