This presentations will tell you everything you every wanted to know about refactoring... probably :-)

1. Everything you Wanted to Know About Refactoring but were Afraid to Ask! By Gary Short Technical Evangelist Developer Express

2. Agenda What 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 skill Therefore it’s a must have skill for you! Helps to keep technical debt under control Technical debt kills projects.

4. Introduction Gary Short Technical Evangelist for Developer Express Community Evangelist for... Well, me really!  Microsoft MVP C# Where do I hang out? http://www.garyshort.org (blog) http://www.twitter.com/garyshort http://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 Testing is a software design and development method where the programmer gains confidence that individual units of source code are fit for use modern applications include the use of a test framework such as nUnit each 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.

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

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 questions Is my code readable? Is my code abstract? Anything more is rearranging the deck chairs on the Titanic It gives you a sense of doing something But 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 ways Refactoring can be repetitive Repetitive tasks bore humans Resulting in mistakes Solutions can contain many projects Many classes with many projects can contain the same method calls This makes them hard to find and easy to miss Tools 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. Summary Refactoring is changing the structure, but not the functionality of your application Refactoring is done to pay back the “Technical Debt” Refactor by asking is your code Readable Abstract Invest in some tooling.

42. Further Reading Fowler, 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. Questions http://www.garyshort.org http://www.twitter.com/garyshort http://www.sodthis.com gary@garyshort.org