Upload
paulo-igor-alves-godinho
View
192
Download
1
Embed Size (px)
DESCRIPTION
Algumas dicas que todo o desenvolvedor deveria saber, praticar e aperfeiçoar! :)
Citation preview
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