Scribd
Upload
10 views3 pages

Re Factoring

Refactoring is the systematic process of improving existing code without altering its functionality, aimed at enhancing maintainability, extensibility, and readability. It is essential in Agile projects to prevent poor code quality and technical debt, despite challenges such as time constraints and fear of introducing bugs. Key indicators of code needing refactoring include duplicated code, long methods, and complex structures, with the ultimate goal of improving code quality and maintaining a robust software architecture.

Uploaded by

arpiarpi1663
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
10 views3 pages

Re Factoring

Refactoring is the systematic process of improving existing code without altering its functionality, aimed at enhancing maintainability, extensibility, and readability. It is essential in Agile projects to prevent poor code quality and technical debt, despite challenges such as time constraints and fear of introducing bugs. Key indicators of code needing refactoring include duplicated code, long methods, and complex structures, with the ultimate goal of improving code quality and maintaining a robust software architecture.

Uploaded by

arpiarpi1663
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Refactoring or Code Refactoring is defined as systematic process of

improving existing computer code, without adding new functionality or changing


external behaviour of the code. It is intended to change the implementation,
definition, structure of code without changing functionality of software.
It improves extensibility, maintainability, and readability of software without
changing what it actually does.
Why should we refactor our code when it works fine? The goal of
refactoring is not to add new functionality or remove an existing one. The main
goal of refactoring is to make code easier to maintain in future and to fight
technical debt. We do refactor because we understand that getting design right
in first time is hard and also you get the following benefits from refactoring:
 Code size is often reduced
 Confusing code is restructured into simpler code
Both of the above benefits greatly improve maintainability which is required
because requirements always keep changing.
When do we refactor?
 Before you add new features, make sure your design and current code is
“good” this will help the new code be easier to write.
 When you need to fix a bug
 When you do a peer review
 During a code review

Refactoring is the practice of continuously improving the design of existing


code, without changing the fundamental behavior. In Agile, teams maintain and
enhance their code on an incremental basis from Sprint to Sprint. If code is not
refactored in an Agile project, it will result in poor code quality, such as
unhealthy dependencies between classes or packages, improper class
responsibility allocation, too many responsibilities per method or class,
duplicate code, and a variety of other types of confusion and clutter. Refactoring
helps to remove this chaos and simplifies the unclear and complex code.
Following are the definitions quoted by various experts in Agile on Refactoring
concepts:
 A refactoring is a “behavior-preserving transformation” –
 Refactoring is “a change made to the internal structure of software to
make it easier to understand and cheaper to modify without changing its
observable behavior” –
Challenges:
Though refactoring brings a lot of benefits to the code quality of the software,
there are multiple challenges that dissuade developers in Agile projects from
continuously refactoring the code. Following are a few challenges that are
mostly seen in Agile projects
 Time Constraint: Time is the biggest challenge for doing refactoring in Agile
projects as the Sprints are time-boxed with a defined set of deliverables.
 Reluctance: If the code is working fine without any refactoring done, there
will be an inclination towards not revisiting the code. This is primarily
because of the mindset that there is no error and hence no need to do
additional activities i.e. refactoring.
 Integration with branches: To integrate the code across different branches
post refactoring is considered a challenge
 Fear factor: Developer often fears that refactoring will introduce bugs and
break the existing functionality which is working fine
 Re-Testing: In case automated test suites are not available, the developer is
discouraged to do refactoring with the additional effort of manual testing to
check the functionality
 Backward Compatibility: Backward compatibility often prevents
developers from starting refactoring efforts.
How to Check Faculty Code?
‘Code Smell’ is the phrase coined by Kent Back and Martin Fowler. Some of the
most important “smells in code” are:

S.No. Smell Description

Identical or very similar code exists in more than one


1. Duplicated code
location

2. Long Method A method/function/procedure that has grown too large

3. Long Class A class that has grown too large

Too Many A long list of parameters is hard to read and makes


4.
Parameters calling and testing the function complicated

5. Feature envy A class that uses methods of another class excessively

6. Lazy Class A class that does too little

Contrived Forced usage of overly complicated design patterns


7.
complexity where the simpler design would suffice.

8. Complex to Code has become complex enough to debug


S.No. Smell Description

debug

What is the Purpose of Refactoring Code?


Code refactoring is done to:
 Improve code quality: implies cleaning up code and improving its structure to
make it less complex and understandable
 Maintain a good software architecture: means to enhance the design of the
source code to accelerate the delivery of the new product features
 Minimize cruft: implies minimizing the difference between the current source
code and how it should actually be
 Reduce technical debt: means to reduce messy and unrefined code, which may
otherwise lead to additional rework later

You might also like