1. Module 1. Introducing Course: Refactoring

2. Overview Definition Principles Building Tests Bad Smells in Code

3. Definition Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

4. Defining Refactoring 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.

5. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation documentation Responding to change over following a plan http://www.agilemanifesto.org/

6. Building on the Foundations Laid by Others Ward Cunningham Kent Beck Ralph Johnson Bill Opdyke John Brant Don Roberts Martin Fowler

7. Demo: IDE Conduct Refactoring with IDE

8. Lesson: Principles in Refactoring Why? When? What? Indirection and Refactoring Problems with Refactoring Refactoring and Design and Performance The Environment for Refactoring Two approaches Thinking in Refactoring

9. Why Should You Refactor? Refactoring Improves the Design of Software Refactoring Makes Software Easier to Understand Refactoring Helps You Find Bugs Refactoring Helps You Program Faster Refactoring Makes coding less annoying

10. When Should You Refactor? Refactor When You Add Function Refactor When You Need to Fix a Bug Refactor As You Do a Code Review The Rule of Three (Don Roberts)

11. What Do I Tell My Manager? Good Manager Bad Manager Design Debt (Ward Cunningham) “Not fix what ain't broken“ Ask: "How many months in a row do you not pay down your debt?" (show your credit card)

12. Indirection and Refactoring To enable sharing of logic To explain intention and implementation separately To isolate change To encode conditional logic

13. Problems with Refactoring Hard to see that greatly improves your productivity Databases Changing Interfaces Design Changes That Are Difficult to Refactor When Shouldn't You Refactor?

14. Refactoring and Design and Performance Upfront design vs Extreme Programming Only refactoring does work, it is not the most efficient A greater movement toward simplicity of design How difficult is it going to be to refactor a simple solution into the flexible solution? Refactoring and Performance “With design I can think very fast, but my thinking is full of little holes” Alistair Cockburn

15. Breakthrough

16. The Environment for Refactoring Team or Partner Tests Testing Framework CRC Cards or UML Sketches Configuration and Version Control Sophisticated IDE

17. Two approaches Code-First Refactoring Test-First Refactoring Combination method

18. Thinking in Refactoring november(20, 2005)java.util.Calendar c = java.util.Calendar.getInstance(); c.set(2005, java.util.Calendar.NOVEMBER, 20); c.getTime(); Many Eyes Human-Readable Code

19. Rules Keeping It Clean Small Steps Design Debt «Any fool can write code that a computer can understand. Good programmers write code that humans can understand» Martin Fowler, Refactoring: Improving the Design of Existing Code

20. Exercise: Inside a Refactoring Create Extract Method Refactoring  Pick a refactoring and identify a place where the approach builds in small steps even though larger steps could work.

21. Exercise Discussion Small Steps Simple Design  passes all tests  communication  no duplication  fewest classes and methods

22. Lesson: Building Tests The Value of Self-testing Code The xUnit Testing Framework Test Location Tips

23. The Value of Self-testing Code The essential precondition is time Greatly speeds your programming Fully automatic A powerful bug detector Prime technique for Refactoring Type: inline, friend, reflection

24. JUnit import junit.framework.TestCase; public class MyTest extends TestCase { public void test () { … public class MyMain { public static void main (String[] args) { new junit.textui.TestRunner().doRun(new MatcherTest());

25. NUnit using NUnit.Framework; [TestFixture] public class DatabaseFixture { [SetUp] public void CreateDatabaseObjects() {... } … [Test] public void ReadOneObject() {... } }

26. The NUnit Testing Framework

27. Test Location Within Classes Another Solution + public interfaces Another Solution + Reflection

28. Tips Run your tests frequently Testing should be risk driven It is better to write and run incomplete tests than not to run complete tests Think of the boundary conditions Use exceptions Testing can't catch all bugs, but most ones

29. Demo: jUnit test Demonstration

30. Lesson: Bad Smells in Code Definition Simple Design Design Principles Smells Catalog Database Smells Architectures Smells

31. Bad Smells in Code Smells (especially code smells) are warning signs about potential problems in code. If it stinks, change it. Grandma Beck, discussing child-rearing philosophy

32. Simple Design Runs all the tests. Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies. States every intention important to the programmers. Has the fewest possible classes and methods. —Beck, Extreme Programming Explained, p. 57

33. Design Principles DRY : Don’t Repeat Yourself SCP : Speaking Code OCP : Open Closed LSP : Liskov Substitution DIP : Dependency Inversion ISP : Interface Segregation REP : Reuse/Release Equivalency CRP : Common Reuse CCP : Common Closure ADP : Acyclic Dependencies SDP : Stable Dependencies SAP : Stable Abstractions TDA : Tell, Don’t Ask SOC : Separation Of Concerns Stefan Rock. Refactoring in Large Software. 2006

34. Some depends Methods <= 30 code lines A Class <= 30 methods A Package <= 30 classes Subsystems <= 30 packages System <= 30 subsystems 3-10 Layers Methods <= 10 code lines A Class <= 10 methods A Package <= 10 classes Subsystems <= 10 packages System <= 10 subsystems 3-10 Layers

35. Smells Catalog

36. Smells Catalog (1/3) 1. Duplicated Code 2. Long Method 3. Large Class 4. Long Parameter List 5. Divergent Change 6. Shotgun Surgery 7. Feature Envy 8. Data Clumps 9. Primitive Obsession 10. Switch Statements 11. Parallel Inheritance Hierarchies

37. Smells Catalog (2/3) 12. Lazy Class 13. Speculative Generality 14. Temporary Field 15. Message Chains 16. Middle Man 17. Inappropriate Intimacy 18. Alternative Classes with Different Interfaces 19. Incomplete Library Class 20. Data Class 21. Refused Bequest 22. Comments

38. Smells Catalog (3/3) 23. Conditional Complexity 24. Indecent Exposure 25. Solution Sprawl 26. Combination Explosion 27. Oddball Solution

39. Test Smells (Code) Obscure test Conditional test logic Hard to test code Test code duplicated Test Logic in Production … Visit “Test-Driven Development Course”

40. Database Smells Multipurpose column. Multipurpose table. Redundant data. Tables with too many columns. Tables with too many rows. "Smart" columns. Fear of change. Visit “Database Refactoring Course”

41. Architectures Smells Dependency graphs Inheritance hierarchies Packages Subsystems Layers

42. SA4J: Dependencies

43. NDepend

44. Software visualization Sotograph JDepend / NDepend Eclipse Metrics Plugin, JDepend4Eclipse Dr. Freud SonarJ ClassCycle SA4J http://en.wikipedia.org/wiki/Software_visualization

45. Management Smells Absentee Manager All you have is a Hammer Golden Child Leader not Manager / Manager not Leader Metric Abuse Road to Nowhere …

46. Smell - its name Symptoms — cues that help you spot it Causes — notes on how it might happen What to do — possible refactorings Payoff — the ways your code will improve Contraindications — when not to fix it

47. Exercise: Real Project Review real project Smells list

48. Review Definition Principles Building Tests Bad Smells in Code