54
Preocupações de um Desenvolvedor Ágil Paulo Igor

Preocupações Desenvolvedor Ágil

Embed Size (px)

DESCRIPTION

Algumas dicas que todo o desenvolvedor deveria saber, praticar e aperfeiçoar! :)

Citation preview

Page 1: Preocupações Desenvolvedor Ágil

Preocupações de um Desenvolvedor Ágil

Paulo Igor

Page 2: Preocupações Desenvolvedor Ágil
Page 3: Preocupações Desenvolvedor Ágil

Não é apenas CÓDIGO

Page 4: Preocupações Desenvolvedor Ágil

impacta a vida de milhares de pessoas

Page 5: Preocupações Desenvolvedor Ágil

transforma a vida das pessoas

Page 6: Preocupações Desenvolvedor Ágil
Page 7: Preocupações Desenvolvedor Ágil

“Grandes poderes trazem grandes responsabilidades”

(Ben Parker)

Page 8: Preocupações Desenvolvedor Ágil
Page 9: Preocupações Desenvolvedor Ágil

ComodidadeQualidade de Vida

Tempo…

Page 10: Preocupações Desenvolvedor Ágil
Page 11: Preocupações Desenvolvedor Ágil

#FAIL

Page 12: Preocupações Desenvolvedor Ágil
Page 13: Preocupações Desenvolvedor Ágil

Programar é uma arte!

Page 14: Preocupações Desenvolvedor Ágil

Qualidade

Page 15: Preocupações Desenvolvedor Ágil

Programar é uma arte!

“Programar é um processo criativo e

que exige aperfeiçoamento”

Page 16: Preocupações Desenvolvedor Ágil

…é necessário praticar!

Page 17: Preocupações Desenvolvedor Ágil

DNA do programador

Page 18: Preocupações Desenvolvedor Ágil

Preguiçoso e criativo!!!

Page 19: Preocupações Desenvolvedor Ágil

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

precisou ser feito”

Page 20: Preocupações Desenvolvedor Ágil

...mas funciona!!!

Page 21: Preocupações Desenvolvedor Ágil

Passa a encarar os problemas com naturalidade…

Page 22: Preocupações Desenvolvedor Ágil

Pragmatic Programmer

Page 23: Preocupações Desenvolvedor Ágil

The Pragmatic Programmer

Page 24: Preocupações Desenvolvedor Ágil

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

Page 25: Preocupações Desenvolvedor Ágil

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

Page 26: Preocupações Desenvolvedor Ágil

Técnicas e Práticas

Page 27: Preocupações Desenvolvedor Ágil

Pair Programming

Page 28: Preocupações Desenvolvedor Ágil

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

Page 29: Preocupações Desenvolvedor Ágil

Ta uma bagunça, mas funciona!

Page 30: Preocupações Desenvolvedor Ágil

Agora sim!

Page 31: Preocupações Desenvolvedor Ágil

Refatoração“Refactoring: Improving the Design of

Existing Code” (Martin Fowler)

Page 32: Preocupações Desenvolvedor Ágil

Testes

Page 33: Preocupações Desenvolvedor Ágil

Testes Manuais

Page 34: Preocupações Desenvolvedor Ágil

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

Page 35: Preocupações Desenvolvedor Ágil

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

Page 36: Preocupações Desenvolvedor Ágil

Automatização

Page 37: Preocupações Desenvolvedor Ágil

Especificação TestávelConcordion / FitNesse

Page 38: Preocupações Desenvolvedor Ágil
Page 39: Preocupações Desenvolvedor Ágil
Page 40: Preocupações Desenvolvedor Ágil

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

Page 41: Preocupações Desenvolvedor Ágil

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

Page 42: Preocupações Desenvolvedor Ágil

Blindagem do Código

Page 43: Preocupações Desenvolvedor Ágil

Design Evolutivo

“TDD - Kent Beck / BDD - Dan North”

Page 44: Preocupações Desenvolvedor Ágil

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

Continuous

Integration(Martin Fowler)

Page 45: Preocupações Desenvolvedor Ágil

Continuous Delivery(Jez Humble e David Farley)

Page 46: Preocupações Desenvolvedor Ágil

Continuous Delivery(Jez Humble e David Farley)

Page 47: Preocupações Desenvolvedor Ágil

da qualidade não se abre mão

Page 48: Preocupações Desenvolvedor Ágil

“Arte de Programar”

Page 49: Preocupações Desenvolvedor Ágil

“controle a força”

Page 50: Preocupações Desenvolvedor Ágil

“Treinar pra quê?”

Page 51: Preocupações Desenvolvedor Ágil

BOM SENSO!!!

Page 52: Preocupações Desenvolvedor Ágil

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

Page 53: Preocupações Desenvolvedor Ágil

Deixe seu legado!!!

Page 54: Preocupações Desenvolvedor Ágil

Obrigado!

Paulo Igor