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 runtime or 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.Eiffel In C and Java, assertions can be used only to check assumptions at runtime.CJava 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 kept fully 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: have names; 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 not rewriting 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 – not no 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 mask other problems; some go away unexpectedly when you do something else. Smells usually describe localized problems. Local smells work with our tendency to consider only the part we’re looking at right now.