1. Refactoring
By Rabeya Bashri

2. Refactoring
What is Refactoring
Why should we use Refactoring
When should we use Refactoring
When should not we use Refactoring
Why Refactoring works
Problem with Refactoring
Some Scenario
Conclusion

3. What is Refactoring
 a disciplined technique, used for restructuring an existing body of code
 altering its internal structure without changing its external behavior
 Its heart is a series of small behavior preserving transformations. Each
transformation does little, but a sequence of transformations can produce a
significant restructuring.
 Refactoring (noun): a change made to the internal structure of software to
make it easier to understand and cheaper to modify without changing its
observable behavior.
 Refactor (verb): to restructure software by applying a series of refactorings
without changing its observable behavior.
 it provides a technique for cleaning up code in a more efficient and
controlled manner.

4. Why should we use Refactoring
 Refactoring Improves the Design of Software
 It becomes harder to see the design by reading the code.
 Regular refactoring helps code retain its shape.
 Poorly designed code usually takes more code to do the same things, often
because the code quite literally does the same thing in several places. Thus an
important aspect of improving design is to eliminate duplicate code.
 By eliminating the duplicates, you ensure that the code says everything once
and only once, which is the essence of good design.
 Refactoring Makes Software Easier to Understand
 It does matter if it takes a programmer a week to make a change that would
have taken only an hour if programmer had understood your code.
 Refactoring Helps You Find Bugs
 Refactoring helps programmer be much more effective at writing robust code.
 Refactoring Helps You Program Faster
 a good design is essential for rapid software development.
 Without a good design, you can progress quickly for a while, but soon the poor
design starts to slow you down. You spend time finding and fixing bugs instead
of adding new function. Changes take longer as you try to understand the
system and find the duplicate code.

5. When should we use Refactoring
 refactoring is not an activity you set aside time to do. Refactoring is
something you do all the time in little bursts. You don’t decide to
refactor, you refactor because you want to do something else, and
refactoring helps you do that other thing.
 The Rule of Three
 Refactor When You Add Function
 Refactor When You Need to Fix a Bug
 Refactor As You Do a Code Review

6. When should not we use Refactoring
 A clear sign of the need to rewrite is when the current code
just does not work. You may discover this only by trying to
test it and discovering that the code is so full of bugs that you
cannot stablilize it. Remember, code has to work mostly
correctly before you refactor.
 The other time you should avoid refactoring is when you are
close to a deadline. At that point the productivity gain from
refactoring would appear after the deadline and thus be too
late.

7. Why Refactoring works
 What is it that makes programs hard to work with? Four
things I can think of as I am typing this are as follows:
Programs that are hard to read are hard to modify.
Programs that have duplicated logic are hard
to modify.
Programs that require additional behavior that
requires you to change running code are hard
to modify.
Programs with complex conditional logic are hard
to modify.
 So, we want programs that are easy to read, that have
all logic specified in one and only one place, that do not
allow changes to endanger existing behavior, and that
allow conditional logic to be expressed as simply
as possible.

8. Problem with Refactoring
 Databases
 One problem area for refactoring is databases. Most business
applications are tightly coupled to the database schema that supports
them.That’s one reason that the database is difficult to change.
 Another reason is data migration. Even if you have carefully layered
your system to minimize the dependencies between the database
schema and the object model, changing the database schema forces
you to migrate the data, which can be a long and fraught task.
 Changing Interfaces
 Something that is disturbing about refactoring is that many of the
refactorings do change an interface.
 Design Changes That Are Difficult to Refactor

9. Considerable scenario for refactoring
 Duplicate Code
 Long Method
 Larger Class
 Long Parameter List

10. Conclusion
Refactoring is the process of taking a running program and
adding to its value, not by changing its behavior but by giving
it more of these qualities that enable us to continue
developing at speed.