Agile Software Design


Published on

Published in: Technology
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Software Design

  1. 1. SoftwareDesign onAgile Methods Eduardo Guerra
  2. 2. GUERRA ITA @emguerraMundoJ Architect + Researcher Frameworks SwingBean, Esfinge Experience Research JavaSE, JavaEE, JavaMEPatterns + Frameworks+ Agile + Tests + Design
  3. 3. some months latterborrow some money pay what you borrowed plus interest
  4. 4. some years latterborrow some money pay with your life!
  5. 5. some days latter
  6. 6. bad code was duplicatedmaintenancein this code is time-consuming people avoid reusing this code other classes became coupled with the bad design
  7. 7. some months latter
  8. 8. sometimesthere is noturn back
  9. 9. “Shipping first time code is like going intodebt. A little debt speeds development so longas it is paid back promptly with a rewrite...The danger occurs when the debt is notrepaid. Every minute spent on not-quite-rightcode counts as interest on that debt. Entireengineering organizations can be brought to astand-still under the debt load of anunconsolidated implementation, object-oriented or otherwise.” Ward Cunningham
  10. 10. Technical DebtAs soon as you payit, less work youneed to fix it!
  11. 11. Sometimes clients doesntFACTS know exactly what requirements they need in their software Design solutions based on one requirement can be different if others are consideredThese facts create a risk to deliverwrong software to the client!
  12. 12. Traditional software engineeruses he same approach of other types of engineering projects!
  13. 13. Identify all Create a Construct basedrequirements complete project on the project Deliver the Test to verify the software requirements
  14. 14. Cost of Change Curve Using traditional style, it is cheaper to change in theCOST beginning TIME
  15. 15. Traditional software engineer put a lot of effort on requirements and project to avoid changes!
  16. 16. But, didnt theysee the signs?
  17. 17. Expected!Unexpected... Due to bad communicationBecause market needs.
  18. 18. Agile softwaredevelopmenthas a distinct approach...
  19. 19. Instead of fightagainst changes ...
  20. 20. Agileembraceschanges !
  21. 21. Agile software engineer focus onimplementation and tests to enable software to be changed easily!
  22. 22. Automated TestingMakes safe to changeDecouplingChanges are isolatedClean CodeChanges are more easy to make
  23. 23. Test-Driven RefactoringDevelopment
  24. 24. TestDrivenDevelopment
  25. 25. Imagine if you could test-driven your life...
  26. 26. Why somepeople dont do that with their code?
  27. 27. Test DrivenDevelopmentis a development and design technique in which the tests are created before the production code.
  28. 28. TDD is a crazyidea that works! Kent BeckSoftware Engineering Radio Podcast
  29. 29. TDDCycle by Google
  30. 30. Add a Test design class interface + define expected behavior Make Test Passcreate actual behavior + most simple solution Refactor clean implemented code + adjust class design
  31. 31. BabySteps
  32. 32. All code is Guilty untl provenInnocent
  33. 33. Refactoring
  34. 34. How often people wash thedishes in a restaurant kitchen?
  35. 35. The next meal will take longerand be more expensive because we are cleaning the kitchen. What???
  36. 36. This feature that you areasking is expensive becausethe code is not clean and we will need to change it. Humm... OK...
  37. 37. Are your source code like this?
  38. 38. Is it better to Or to let dirtclean little by and mess little? accumulate?
  39. 39. Some dirt are hard to clean in the course of time! RememberTechnical Debt?
  40. 40. How to clean the source code?Refactoring
  41. 41. “Refactoring is a disciplinedtechnique for restructuring anexisting body of code, alteringits internal structure withoutchanging its external behavior.” Martin Fowler
  42. 42. Code Bad Smells Have you ever look to a piece of code which doesnt smell very nice?Code smell is anysymptom in thesource code that canindicate a problem!
  43. 43. In every step, the tests should be executed to verify if everything still working! Refactoring is performed in small steps to remove badsmells and reach the desired design
  44. 44. Using refactoring,the application design emerge according to its needs!
  45. 45. Is it not dangerous to change a wining team? No when you haveautomated unit tests!
  46. 46. Conclusions
  47. 47. Cost of Change Curve Agile practices keep l na the cost of change io constant in later dit tra phases of the projectCOST agile TIME
  48. 48. shortiterations
  49. 49. Shortiterations only works if your code is ready to change!
  50. 50. Dont try to predict future design requirements Work hard in your current needs and let design emerge
  51. 51. See you on