Refactoring

1. Refactoring Lecture 5 CIS 6101 Software Processes and Metrics

2. 1. What is Refactoring? • Refactoring is the art of improving the design of existing code. • Provides us with ways to recognize problematic code and gives us recipes for improving it. • Refactoring: technique for practicing programmers who write and maintain code. • Note: need ASSERTIONS!!! JUNIT!!!

3. An aside: JUnit • Junit is a unit testing framework for java. • Important using test-driven development (TDD) and is one of a family of unit testing frameworks collectively called xUnit. • JUnit is linked to JAR at compile time. • JAR file is essentially the linked .class files used to distribute application software or libraries on the Java platform.

4. Assertions (1 of 3)Checked and Unchecked Assertions • In computer programming, as assertion is a predicate (for example a true-false statement) placed in a program to indicate that the developer thinks (or asserts) the predicate is always true there. E.g. The following code contains two assertions x: positive int x = 5; (x>0) // this is an assertion x := x + 1; (x > 1) // this too is an assertion • Programmers can use assertions to help specify programs and to reason about program correctness.

5. Assertions (2 of 3)Checked and Unchecked Assertions • Precondition: A precondition – an assertion placed at the beginning of a section of code – determines the set of states under which the programmer expects the code to execute. • Post-Condition: placed at the end – describes the expected state at the end of execution. • The notation above cannot be used in existing mainstream programming languages. • Unchecked Assertions: However, programmers can include unchecked assertions using the comment feature of their programming language. • Example: • x = 5 • x = x + 1; • // (x > 1); • The braces included in the comment help distinguish this use of a comment from other uses.

6. Assertions (3 of 3)Checked and Unchecked Assertions • Checked Assertions: some modern languages include these. Statements are checked at runtimeor sometimes statically. • What does this mean?? • If an assertion evaluates to false at run time, an assertion failure results, which typically causes execution to abort. • This draws attention to the location where the logical inconsistency is detected and can be preferable to the bahavior that would otherwise result. • In Eiffel, assertions form part of the design process. • In C and Java, assertions can be used only to check assumptions at runtime. • In both cases, assertions can be checked for validity at runtime but can usually also be suppressed.

7. So, What is Refactoring? • Refactoring is a disciplined technique for • restructuring an existing body of code, • altering its internal structure • without changing its external behavior. • Consists of series of small behavior-preserving transformations. • Each transforms (called a 'refactoring') does little • But a sequence can produce a significant restructuring.

8. So, What is Refactoring? • Realize that each refactoring is very small • Because of this, it is less likely to go wrong. • The system is always keptfully working after each small refactoring • This reduces chances a system can get seriously broken during the restructuring.

9. 2. Refactoring – Introduction (1 of 2) • Smells – problems that occur within classes. • Some problems occur between classes. • Sometimes ‘smells’ refer to warning signs of potential problems. • Smells: • havenames; • note cues that help us spot them, • what are some possible refactorings, • What are some of the payoffs • ways in which your code will improve, and • contraindications – when not to fix it.

10. Refactoring – Introduction (2 of 2) • While we will only introduce the concepts – • Hope this great topic is undertaken for • research or • thesis work • Will also overview related topics.

11. Smells within Classes • There is a refactoring cycle • There is a discipline to refactoring • Very structured! • There are ‘measurable’ smells • Consider the problem of unnecessary code. • Possibly the one smell we need to be most wary of is duplication .

12. Smells between Classes • Data in classes can sometimes represent missing objects. • Should the data be instance data or is it robust enough to warrant the abstraction of a class. • Look at the balance of responsibility between super classes and subclasses. • What attributes rise to the parent class: methods to parent? • Overriding classes with derived classes? • Look at balance of responsibility between other classes. • What does the class do? Is it cohesive? How tightly is it coupled??? • Are all the responsibilities that need the data co-located ‘with’ the data? • Some duplication may become obvious when we try to change things. • Challenges present in library classes

13. 3. The Refactoring Cycle • Refactoring: art of safely improving design of existing code • Implications: • 1. Refactoring does not include just any changes in a system. • 2. Refactoring is notrewriting from scratch • 3. Refactoring is not just any restructuring intended to improve code • 4. Refactoring changes the balance point between up-front design and emergent design • 5. Refactorings can be small or large.

14. 3.1. Refactoring does not include just any changes in a system. • Changes not considered for refactoring: • design improvements or • adding new functionality • Refactoring while creating code? Yes • Refactoring for adding new features? No. • Example: In XP, we use test-driven development. This consists of writing a test, then writing new code to introduce new features, and then refactor to improve the design.

15. 3.2. Refactoring is not rewriting from scratch • Sometimes better to rewrite. • This is NOT what refactoring is all about. • Refactoring changes the balance point • Improve code rather take risk of rewriting it. • Refactoring preserves the knowledge embedded in the existing code. • Behavior is preserved.

16. 3.3. Refactoring is not just any restructuring intended to improve code • Refactoring involves safe transformations • Large refactorings divided into smaller, safe refactorings. • (In the best case, refactorings are so well defined that they can be automated) See some IDEs – like NetBeans • We do not regard a change as refactoring if it leaves the code not working (that is, not passing its tests) for longer than a working session.

17. 3.4. Refactoring changes the balance point between up-front design and emergent design • Up front design: done in advance of implementation; • Emergent design: design mixed with implementation. • The trade-off between the two hinges on how well we can anticipate problems or assess them in code, and whether it’s easier to • design and then translate to code or • to code then improve. • (Reasonable people will disagree on where the line is, but all will agree that it shifts)

18. 3.5. Refactorings can be small or large. • Many refactorings are small. • Ideally, small refactorings applied “mercilessly” so large refactorings are rarely needed. • For large-scale refactorings, the approach is • notno new features for six months while we refactor, • Rather, refactor as we go, and keep the system running at all times.

19. 4. Smells Are Problems; Metaphor (1 of 2) • “Smells,” especially code smells, are warning signs about potential problems in code. • Not all smells indicate a problem, but most are worthy of a look and a decision. • Some people: dislike smells; prefer potential problems or flaws. • Smells is a good metaphor.

20. Smells Are Problems and Metaphor (2 of 2) • Think when you open a refrigerator and smells. Obvious. Smells strong. Maybe bad chicken… • Other smells – perhaps not so obvious. Unsure of problem. • Some food bad and won’t smell. • These are the likely code smells; some obvious; others not. • Some smells maskotherproblems; some go away unexpectedly when you do something else. • Smells usually describe localizedproblems. • Local smells work with our tendency to consider only the part we’re looking at right now.