Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Everything you Wanted to Know About Refactoring but were Afraid to Ask!<br />By Gary Short<br />Technical Evangelist<br />...
Agenda<br />What is Refactoring?<br />Why Should I Refactor?<br />How do I know that I have to refactor?<br />How Should I...
Why do I Need to Know this?<br />Refactoring is a professional dev skill<br />Therefore it’s a must have skill for you!<br...
Introduction<br />Gary Short<br />Technical Evangelist for Developer Express<br />Community Evangelist for... Well, me rea...
How About you Guys?<br />
What is Refactoring?<br />Knowledge says refactoring is...<br />the process of changing a computer program's internal stru...
Ooo, Hold on, How’d you do That?<br />the process of changing a computer program's internal structure <br />without modify...
Quick Example<br />Biggest Refactoring Eva!!<br /><ul><li>October 17, 1989, the 7.1 magnitude Loma Prieta earthquake cause...
The earthquake reminded the world that the San Francisco Bay region remains vulnerable
If a Richter magnitude 8.0 or greater earthquake centered near the Bridge, there would be a substantial risk of impending ...
Retrofit starts 1997
Still ongoing today
Cost ~ half a billion dollars.</li></li></ul><li>Why Should I Refactor?<br />Refactoring is our way of paying off our “Tec...
Financial Debt Isn’t All Bad<br />
Technical Debt Isn’t all Bad Either<br />
Refactoring Pays Back this Debt<br />
Refactoring Pays Back this Debt<br />
How Do I Know When To Refactor?<br />
How Do I Know When To Refactor?<br />
How Do I Know When To Refactor?	<br />
How Do I Know When To Refactor?	<br />
How Do I Know When To Refactor?	<br />
How Do I Know When To Refactor?	<br />
How Should I Refactor?<br />Ask yourself the following questions<br />Is my code readable? <br />Is my code abstract? <br ...
Refactoring for Readability #1<br />
Refactoring for Readability #1<br />
Refactoring for Readability #2<br />
Refactoring for Readability #3<br />
Refactoring for Readability #4<br />
Refactoring for Readability #5<br />
Refactoring to Make Abstract #1<br />
Refactoring to Make Abstract #2<br />
Refactoring to Make Abstract #2<br />
Refactoring to Make Abstract #3<br />
Can Tooling Help me?<br />Yes, in the following ways<br />Refactoring can be repetitive<br />Repetitive tasks bore humans<...
Tooling Demo<br />
Refactoring to Patterns #1<br />
Refactoring to Patterns #1<br />
Refactoring to Patterns #2<br />
Próxima SlideShare
Cargando en…5
×

Everything you Wanted to Know About Refactoring

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

  • Sé el primero en comentar

Everything you Wanted to Know About Refactoring

  1. 1. Everything you Wanted to Know About Refactoring but were Afraid to Ask!<br />By Gary Short<br />Technical Evangelist<br />Developer Express<br />
  2. 2. Agenda<br />What is Refactoring?<br />Why Should I Refactor?<br />How do I know that I have to refactor?<br />How Should I Refactor?<br />How can Tooling Help Me?<br />Advanced Refactoring.<br />
  3. 3. Why do I Need to Know this?<br />Refactoring is a professional dev skill<br />Therefore it’s a must have skill for you!<br />Helps to keep technical debt under control<br />Technical debt kills projects.<br />
  4. 4. Introduction<br />Gary Short<br />Technical Evangelist for Developer Express<br />Community Evangelist for... Well, me really! <br />Microsoft MVP C#<br />Where do I hang out?<br />http://www.garyshort.org (blog)<br />http://www.twitter.com/garyshort<br />http://www.sodthis.com (podcast).<br />
  5. 5. How About you Guys?<br />
  6. 6. What is Refactoring?<br />Knowledge says refactoring is...<br />the process of changing a computer program's internal structure <br />without modifying its external functional behavior <br />or existing functionality, <br />in order to improve <br />internal non-functional properties of the software, <br />for example to improve code readability, <br />to simplify code structure, <br />to change code to adhere to a given programming paradigm,<br /> to improve maintainability, <br />or to improve extensibility.<br />
  7. 7. Ooo, Hold on, How’d you do That?<br />the process of changing a computer program's internal structure <br />without modifying its external functional behavior <br />or existing functionality, <br />Unit Testing<br />is a software design and development method where the programmer gains confidence that individual units of source code are fit for use<br />modern applications include the use of a test framework such as nUnit<br />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.<br />
  8. 8. Quick Example<br />Biggest Refactoring Eva!!<br /><ul><li>October 17, 1989, the 7.1 magnitude Loma Prieta earthquake causes 68 deaths
  9. 9. The earthquake reminded the world that the San Francisco Bay region remains vulnerable
  10. 10. If a Richter magnitude 8.0 or greater earthquake centered near the Bridge, there would be a substantial risk of impending collapse
  11. 11. Retrofit starts 1997
  12. 12. Still ongoing today
  13. 13. Cost ~ half a billion dollars.</li></li></ul><li>Why Should I Refactor?<br />Refactoring is our way of paying off our “Technical Debt”<br />Technical what?!<br />is a metaphor developed by Ward Cunningham<br />doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt<br />incurs interest payments, which come in the form of the extra effort that we have to do in future development.<br />
  14. 14. Financial Debt Isn’t All Bad<br />
  15. 15. Technical Debt Isn’t all Bad Either<br />
  16. 16. Refactoring Pays Back this Debt<br />
  17. 17. Refactoring Pays Back this Debt<br />
  18. 18. How Do I Know When To Refactor?<br />
  19. 19. How Do I Know When To Refactor?<br />
  20. 20. How Do I Know When To Refactor? <br />
  21. 21. How Do I Know When To Refactor? <br />
  22. 22. How Do I Know When To Refactor? <br />
  23. 23. How Do I Know When To Refactor? <br />
  24. 24. How Should I Refactor?<br />Ask yourself the following questions<br />Is my code readable? <br />Is my code abstract? <br />Anything more is rearranging the deck chairs on the Titanic<br />It gives you a sense of doing something<br />But ultimately it’s pointless. <br />
  25. 25. Refactoring for Readability #1<br />
  26. 26. Refactoring for Readability #1<br />
  27. 27. Refactoring for Readability #2<br />
  28. 28. Refactoring for Readability #3<br />
  29. 29. Refactoring for Readability #4<br />
  30. 30. Refactoring for Readability #5<br />
  31. 31. Refactoring to Make Abstract #1<br />
  32. 32. Refactoring to Make Abstract #2<br />
  33. 33. Refactoring to Make Abstract #2<br />
  34. 34. Refactoring to Make Abstract #3<br />
  35. 35. Can Tooling Help me?<br />Yes, in the following ways<br />Refactoring can be repetitive<br />Repetitive tasks bore humans<br />Resulting in mistakes<br />Solutions can contain many projects<br />Many classes with many projects can contain the same method calls<br />This makes them hard to find and easy to miss<br />Tools can suggest refactors that you might not know exist.<br />
  36. 36. Tooling Demo<br />
  37. 37. Refactoring to Patterns #1<br />
  38. 38. Refactoring to Patterns #1<br />
  39. 39. Refactoring to Patterns #2<br />
  40. 40. Refactoring to Patterns #3<br />
  41. 41. Summary<br />Refactoring is changing the structure, but not the functionality of your application<br />Refactoring is done to pay back the “Technical Debt”<br />Refactor by asking is your code<br />Readable<br />Abstract<br />Invest in some tooling.<br />
  42. 42. Further Reading<br />Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.  <br />Wake, William C. (2003). Refactoring Workbook. Addison-Wesley. ISBN 0-321-10929-5.  <br />Feathers, Michael C (2004). Working Effectively with Legacy Code. Prentice Hall. ISBN 0-13-117705-2.  <br />Kerievsky, Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN 0-321-21335-1.  <br />Arsenovski, Danijel (2008). Professional Refactoring in Visual Basic. Wrox. ISBN 0-47-017979-1. <br />
  43. 43. Questions<br />http://www.garyshort.org<br />http://www.twitter.com/garyshort<br />http://www.sodthis.com<br />gary@garyshort.org<br />

×