This document discusses the concept of refactoring, which is the process of changing a program's internal structure without altering its external functionality to improve code quality. It emphasizes the importance of refactoring in managing technical debt, encourages developers to evaluate when and how to refactor, and highlights the benefits of using tooling in the refactoring process. The author, Gary Short, also provides resources for further reading and shares his background as a technical evangelist.

1. Everything you Wanted to Know About Refactoring but were Afraid to Ask!By Gary ShortTechnical EvangelistDeveloper Express

2. AgendaWhat is Refactoring?Why Should I Refactor?How do I know that I have to refactor?How Should I Refactor?How can Tooling Help Me?Advanced Refactoring.

3. Why do I Need to Know this?Refactoring is a professional dev skillTherefore it’s a must have skill for you!Helps to keep technical debt under controlTechnical debt kills projects.

4. IntroductionGary ShortTechnical Evangelist for Developer ExpressCommunity Evangelist for... Well, me really! Microsoft MVP C#Where do I hang out?http://www.garyshort.org (blog)http://www.twitter.com/garyshorthttp://www.sodthis.com (podcast).

5. How About you Guys?

6. What is Refactoring?Knowledge says refactoring is...the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal non-functional properties of the software, for example to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, or to improve extensibility.

7. Ooo, Hold on, How’d you do That?the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, Unit Testingis a software design and development method where the programmer gains confidence that individual units of source code are fit for usemodern applications include the use of a test framework such as nUniteach test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation.

8. Quick ExampleBiggest Refactoring Eva!!October 17, 1989, the 7.1 magnitude Loma Prieta earthquake causes 68 deaths

9. The earthquake reminded the world that the San Francisco Bay region remains vulnerable

10. If a Richter magnitude 8.0 or greater earthquake centered near the Bridge, there would be a substantial risk of impending collapse

11. Retrofit starts 1997

12. Still ongoing today

13. Cost ~ half a billion dollars.Why Should I Refactor?Refactoring is our way of paying off our “Technical Debt”Technical what?!is a metaphor developed by Ward Cunninghamdoing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debtincurs interest payments, which come in the form of the extra effort that we have to do in future development.

14. Financial Debt Isn’t All Bad

15. Technical Debt Isn’t all Bad Either

16. Refactoring Pays Back this Debt

17. Refactoring Pays Back this Debt

18. How Do I Know When To Refactor?

19. How Do I Know When To Refactor?

20. How Do I Know When To Refactor?

21. How Do I Know When To Refactor?

22. How Do I Know When To Refactor?

23. How Do I Know When To Refactor?

24. How Should I Refactor?Ask yourself the following questionsIs my code readable? Is my code abstract? Anything more is rearranging the deck chairs on the TitanicIt gives you a sense of doing somethingBut ultimately it’s pointless. 

25. Refactoring for Readability #1

26. Refactoring for Readability #1

27. Refactoring for Readability #2

28. Refactoring for Readability #3

29. Refactoring for Readability #4

30. Refactoring for Readability #5

31. Refactoring to Make Abstract #1

32. Refactoring to Make Abstract #2

33. Refactoring to Make Abstract #2

34. Refactoring to Make Abstract #3

35. Can Tooling Help me?Yes, in the following waysRefactoring can be repetitiveRepetitive tasks bore humansResulting in mistakesSolutions can contain many projectsMany classes with many projects can contain the same method callsThis makes them hard to find and easy to missTools can suggest refactors that you might not know exist.

36. Tooling Demo

37. Refactoring to Patterns #1

38. Refactoring to Patterns #1

39. Refactoring to Patterns #2

40. Refactoring to Patterns #3

41. SummaryRefactoring is changing the structure, but not the functionality of your applicationRefactoring is done to pay back the “Technical Debt”Refactor by asking is your codeReadableAbstractInvest in some tooling.

42. Further ReadingFowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2. Wake, William C. (2003). Refactoring Workbook. Addison-Wesley. ISBN 0-321-10929-5. Feathers, Michael C (2004). Working Effectively with Legacy Code. Prentice Hall. ISBN 0-13-117705-2. Kerievsky, Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN 0-321-21335-1. Arsenovski, Danijel (2008). Professional Refactoring in Visual Basic. Wrox. ISBN 0-47-017979-1.

43. Questionshttp://www.garyshort.orghttp://www.twitter.com/garyshorthttp://www.sodthis.comgary@garyshort.org