Preocupações de um Desenvolvedor Ágil

Paulo Igor

Não é apenas CÓDIGO

impacta a vida de milhares de pessoas

transforma a vida das pessoas

“Grandes poderes trazem grandes responsabilidades”

(Ben Parker)

ComodidadeQualidade de Vida

Tempo…

#FAIL

Programar é uma arte!

Qualidade

Programar é uma arte!

“Programar é um processo criativo e

que exige aperfeiçoamento”

…é necessário praticar!

DNA do programador

Preguiçoso e criativo!!!

“Simplicidade: a arte de maximizar a quantidade de trabalho que não

precisou ser feito”

...mas funciona!!!

Passa a encarar os problemas com naturalidade…

Pragmatic Programmer

The Pragmatic Programmer

1. Care about your craft2. Think! About your work3. Provide options, don’t make lame excuses4. Don’t live with broken windows5. Be a catalyst for change6. Remember the Big Picture7. Make a quality a requirements issue8. Invest regularly in your knowledge portfolio9. Critically Analyze What You Read and Hear 10. It's Both What You Say and the Way You Say It 11. DRY—Don't Repeat Yourself 12. Make It Easy to Reuse 13. Eliminate Effects Between Unrelated Things 14. There Are No Final Decisions 15. Use Tracer Bullets to Find the Target 16. Prototype to Learn 17. Program Close to the Problem domain18. Estimate to Avoid Surprises 19. Iterate the Schedule with the Code 20. Keep Knowledge in Plain Text21. Use the Power of Command Shells 22. Use a Single Editor Well 23. Always Use Source Code Control 24. Fix the Problem, Not the Blame 25. Don't Panic 26. "select" Isn't Broken 27. Don't Assume It—Prove It 28. Learn a Text Manipulation Language 29. Write Code That Writes Code 30. You Can't Write Perfect Software 31. Design with Contracts 32. Crash Early 33. If It Can't Happen, Use Assertions to Ensure That It Won't 34. Use Exceptions for Exceptional Problems 35. Finish What You Start

36. Minimize Coupling Between Modules 37. Configure, Don't Integrate 38. Put Abstractions in Code Details in Metadata 39. Analyze Workflow to Improve Concurrency 40. Design Using Services 41. Always Design for Concurrency 42. Separate Views from Models 43. Use Blackboards to Coordinate Workflow 44. Don't Program by Coincidence 45. Estimate the Order of Your Algorithms 46. Test Your Estimates 47. Refactor Early, Refactor Often 48. Design to Test 49. Test Your Software, or Your Users Will 50. Don't Use Wizard Code You Don't Understand 51. Don't Gather Requirements—Dig for Them 52. Work with a User to Think Like a User 53. Abstractions Live Longer than Details 54. Use a Project Glossary 55. Don't Think Outside the Box—Find the Box 56. Listen to Nagging Doubts—Start When You're Ready 57. Some Things Are Better Done than Described 58. Don't Be a Slave to Formal Methods 59. Expensive Too Do Not Produce Better Designs 60. Organize Around Functionality, Not Job Functions 61. Don't Use Manual Procedures 62. Test Early. Test Often. Test Automatically. 63. Coding Ain't Done 'Til All the Tests Run 64. Use Saboteurs to Test Your Testing 65. Test State Coverage, Not Code Coverage 66. Find Bugs Once 67. Treat English as Just Another Programming Language 68. Build Documentation In, Don't Bolt It On 69. Gently Exceed Your Users' Expectations 70. Sign Your Work

70 Tips

1. Care about your craft2. Think! About your work3. Provide options, don’t make lame excuses4. Don’t live with broken windows5. Be a catalyst for change6. Remember the Big Picture7. Make a quality a requirements issue8. Invest regularly in your knowledge portfolio9. Critically Analyze What You Read and Hear 10. It's Both What You Say and the Way You Say It 11. DRY—Don't Repeat Yourself 12. Make It Easy to Reuse 13. Eliminate Effects Between Unrelated Things 14. There Are No Final Decisions 15. Use Tracer Bullets to Find the Target 16. Prototype to Learn 17. Program Close to the Problem domain18. Estimate to Avoid Surprises 19. Iterate the Schedule with the Code 20. Keep Knowledge in Plain Text21. Use the Power of Command Shells 22. Use a Single Editor Well 23. Always Use Source Code Control 24. Fix the Problem, Not the Blame 25. Don't Panic 26. "select" Isn't Broken 27. Don't Assume It—Prove It 28. Learn a Text Manipulation Language 29. Write Code That Writes Code 30. You Can't Write Perfect Software 31. Design with Contracts 32. Crash Early 33. If It Can't Happen, Use Assertions to Ensure That It Won't 34. Use Exceptions for Exceptional Problems 35. Finish What You Start

36. Minimize Coupling Between Modules 37. Configure, Don't Integrate 38. Put Abstractions in Code Details in Metadata 39. Analyze Workflow to Improve Concurrency 40. Design Using Services 41. Always Design for Concurrency 42. Separate Views from Models 43. Use Blackboards to Coordinate Workflow 44. Don't Program by Coincidence 45. Estimate the Order of Your Algorithms 46. Test Your Estimates 47. Refactor Early, Refactor Often 48. Design to Test 49. Test Your Software, or Your Users Will 50. Don't Use Wizard Code You Don't Understand 51. Don't Gather Requirements—Dig for Them 52. Work with a User to Think Like a User 53. Abstractions Live Longer than Details 54. Use a Project Glossary 55. Don't Think Outside the Box—Find the Box 56. Listen to Nagging Doubts—Start When You're Ready 57. Some Things Are Better Done than Described 58. Don't Be a Slave to Formal Methods 59. Expensive Too Do Not Produce Better Designs 60. Organize Around Functionality, Not Job Functions 61. Don't Use Manual Procedures 62. Test Early. Test Often. Test Automatically. 63. Coding Ain't Done 'Til All the Tests Run 64. Use Saboteurs to Test Your Testing 65. Test State Coverage, Not Code Coverage 66. Find Bugs Once 67. Treat English as Just Another Programming Language 68. Build Documentation In, Don't Bolt It On 69. Gently Exceed Your Users' Expectations 70. Sign Your Work

1 – Care about your craft

Técnicas e Práticas

Pair Programming

Qualidade do Código “Clean Code” (Uncle Bob)

Ta uma bagunça, mas funciona!

Agora sim!

Refatoração“Refactoring: Improving the Design of

Existing Code” (Martin Fowler)

Testes

Testes Manuais

Testes AutomáticosJUnit, JBehave, TestNG, Rspec, Cumcuber, Test::Unit, …

1. Care about your craft2. Think! About your work3. Provide options, don’t make lame excuses4. Don’t live with broken windows5. Be a catalyst for change6. Remember the Big Picture7. Make a quality a requirements issue8. Invest regularly in your knowledge portfolio9. Critically Analyze What You Read and Hear 10. It's Both What You Say and the Way You Say It 11. DRY—Don't Repeat Yourself 12. Make It Easy to Reuse 13. Eliminate Effects Between Unrelated Things 14. There Are No Final Decisions 15. Use Tracer Bullets to Find the Target 16. Prototype to Learn 17. Program Close to the Problem domain18. Estimate to Avoid Surprises 19. Iterate the Schedule with the Code 20. Keep Knowledge in Plain Text21. Use the Power of Command Shells 22. Use a Single Editor Well 23. Always Use Source Code Control 24. Fix the Problem, Not the Blame 25. Don't Panic 26. "select" Isn't Broken 27. Don't Assume It—Prove It 28. Learn a Text Manipulation Language 29. Write Code That Writes Code 30. You Can't Write Perfect Software 31. Design with Contracts 32. Crash Early 33. If It Can't Happen, Use Assertions to Ensure That It Won't 34. Use Exceptions for Exceptional Problems 35. Finish What You Start

36. Minimize Coupling Between Modules 37. Configure, Don't Integrate 38. Put Abstractions in Code Details in Metadata 39. Analyze Workflow to Improve Concurrency 40. Design Using Services 41. Always Design for Concurrency 42. Separate Views from Models 43. Use Blackboards to Coordinate Workflow 44. Don't Program by Coincidence 45. Estimate the Order of Your Algorithms 46. Test Your Estimates 47. Refactor Early, Refactor Often 48. Design to Test 49. Test Your Software, or Your Users Will 50. Don't Use Wizard Code You Don't Understand 51. Don't Gather Requirements—Dig for Them 52. Work with a User to Think Like a User 53. Abstractions Live Longer than Details 54. Use a Project Glossary 55. Don't Think Outside the Box—Find the Box 56. Listen to Nagging Doubts—Start When You're Ready 57. Some Things Are Better Done than Described 58. Don't Be a Slave to Formal Methods 59. Expensive Too Do Not Produce Better Designs 60. Organize Around Functionality, Not Job Functions 61. Don't Use Manual Procedures 62. Test Early. Test Often. Test Automatically. 63. Coding Ain't Done 'Til All the Tests Run 64. Use Saboteurs to Test Your Testing 65. Test State Coverage, Not Code Coverage 66. Find Bugs Once 67. Treat English as Just Another Programming Language 68. Build Documentation In, Don't Bolt It On 69. Gently Exceed Your Users' Expectations 70. Sign Your Work

61 – Don’t use Manual Procedures

Automatização

Especificação TestávelConcordion / FitNesse

TDD / BDD“TDD - Kent Beck / BDD - Dan North”

1. Care about your craft2. Think! About your work3. Provide options, don’t make lame excuses4. Don’t live with broken windows5. Be a catalyst for change6. Remember the Big Picture7. Make a quality a requirements issue8. Invest regularly in your knowledge portfolio9. Critically Analyze What You Read and Hear 10. It's Both What You Say and the Way You Say It 11. DRY—Don't Repeat Yourself 12. Make It Easy to Reuse 13. Eliminate Effects Between Unrelated Things 14. There Are No Final Decisions 15. Use Tracer Bullets to Find the Target 16. Prototype to Learn 17. Program Close to the Problem domain18. Estimate to Avoid Surprises 19. Iterate the Schedule with the Code 20. Keep Knowledge in Plain Text21. Use the Power of Command Shells 22. Use a Single Editor Well 23. Always Use Source Code Control 24. Fix the Problem, Not the Blame 25. Don't Panic 26. "select" Isn't Broken 27. Don't Assume It—Prove It 28. Learn a Text Manipulation Language 29. Write Code That Writes Code 30. You Can't Write Perfect Software 31. Design with Contracts 32. Crash Early 33. If It Can't Happen, Use Assertions to Ensure That It Won't 34. Use Exceptions for Exceptional Problems 35. Finish What You Start

36. Minimize Coupling Between Modules 37. Configure, Don't Integrate 38. Put Abstractions in Code Details in Metadata 39. Analyze Workflow to Improve Concurrency 40. Design Using Services 41. Always Design for Concurrency 42. Separate Views from Models 43. Use Blackboards to Coordinate Workflow 44. Don't Program by Coincidence 45. Estimate the Order of Your Algorithms 46. Test Your Estimates 47. Refactor Early, Refactor Often 48. Design to Test 49. Test Your Software, or Your Users Will 50. Don't Use Wizard Code You Don't Understand 51. Don't Gather Requirements—Dig for Them 52. Work with a User to Think Like a User 53. Abstractions Live Longer than Details 54. Use a Project Glossary 55. Don't Think Outside the Box—Find the Box 56. Listen to Nagging Doubts—Start When You're Ready 57. Some Things Are Better Done than Described 58. Don't Be a Slave to Formal Methods 59. Expensive Too Do Not Produce Better Designs 60. Organize Around Functionality, Not Job Functions 61. Don't Use Manual Procedures 62. Test Early. Test Often. Test Automatically. 63. Coding Ain't Done 'Til All the Tests Run 64. Use Saboteurs to Test Your Testing 65. Test State Coverage, Not Code Coverage 66. Find Bugs Once 67. Treat English as Just Another Programming Language 68. Build Documentation In, Don't Bolt It On 69. Gently Exceed Your Users' Expectations 70. Sign Your Work

47 – Refactor Early, Refactor Often

Blindagem do Código

Design Evolutivo

“TDD - Kent Beck / BDD - Dan North”

TDD / BDD“TDD - Kent Beck / BDD - Dan North”

Continuous

Integration(Martin Fowler)

Continuous Delivery(Jez Humble e David Farley)

Continuous Delivery(Jez Humble e David Farley)

da qualidade não se abre mão

“Arte de Programar”

“controle a força”

“Treinar pra quê?”

BOM SENSO!!!

1. Care about your craft2. Think! About your work3. Provide options, don’t make lame excuses4. Don’t live with broken windows5. Be a catalyst for change6. Remember the Big Picture7. Make a quality a requirements issue8. Invest regularly in your knowledge portfolio9. Critically Analyze What You Read and Hear 10. It's Both What You Say and the Way You Say It 11. DRY—Don't Repeat Yourself 12. Make It Easy to Reuse 13. Eliminate Effects Between Unrelated Things 14. There Are No Final Decisions 15. Use Tracer Bullets to Find the Target 16. Prototype to Learn 17. Program Close to the Problem domain18. Estimate to Avoid Surprises 19. Iterate the Schedule with the Code 20. Keep Knowledge in Plain Text21. Use the Power of Command Shells 22. Use a Single Editor Well 23. Always Use Source Code Control 24. Fix the Problem, Not the Blame 25. Don't Panic 26. "select" Isn't Broken 27. Don't Assume It—Prove It 28. Learn a Text Manipulation Language 29. Write Code That Writes Code 30. You Can't Write Perfect Software 31. Design with Contracts 32. Crash Early 33. If It Can't Happen, Use Assertions to Ensure That It Won't 34. Use Exceptions for Exceptional Problems 35. Finish What You Start

36. Minimize Coupling Between Modules 37. Configure, Don't Integrate 38. Put Abstractions in Code Details in Metadata 39. Analyze Workflow to Improve Concurrency 40. Design Using Services 41. Always Design for Concurrency 42. Separate Views from Models 43. Use Blackboards to Coordinate Workflow 44. Don't Program by Coincidence 45. Estimate the Order of Your Algorithms 46. Test Your Estimates 47. Refactor Early, Refactor Often 48. Design to Test 49. Test Your Software, or Your Users Will 50. Don't Use Wizard Code You Don't Understand 51. Don't Gather Requirements—Dig for Them 52. Work with a User to Think Like a User 53. Abstractions Live Longer than Details 54. Use a Project Glossary 55. Don't Think Outside the Box—Find the Box 56. Listen to Nagging Doubts—Start When You're Ready 57. Some Things Are Better Done than Described 58. Don't Be a Slave to Formal Methods 59. Expensive Too Do Not Produce Better Designs 60. Organize Around Functionality, Not Job Functions 61. Don't Use Manual Procedures 62. Test Early. Test Often. Test Automatically. 63. Coding Ain't Done 'Til All the Tests Run 64. Use Saboteurs to Test Your Testing 65. Test State Coverage, Not Code Coverage 66. Find Bugs Once 67. Treat English as Just Another Programming Language 68. Build Documentation In, Don't Bolt It On 69. Gently Exceed Your Users' Expectations 70. Sign Your Work

30 – You Can’t Write Perfect Software

Deixe seu legado!!!

Obrigado!

Paulo Igor