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)
Comodidade
Qualidade de Vida
Tempo
…
#FAIL
Programar é uma arte!
Qualidade
“Programar é um
processo criativo e
que exige
aperfeiçoamento”

Programar é uma arte!
…é 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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33....
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33....
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áticos
JUnit, JBehave, TestNG, Rspec, Cumcuber, Test::Unit, …
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33....
Automatização
Especificação Testável
Concordion / FitNesse
TDD / BDD
“TDD - Kent Beck / BDD - Dan North”
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33....
Blindagem do Código
Design Evolutivo
“TDD - Kent Beck / BDD - Dan North”
Continuous
TDD / BDD
Integration

“TDD - Kent Beck / BDD - Dan North”
(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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33....
Deixe seu legado!!!
Obrigado!
Paulo Igor
Preocupações Desenvolvedor Ágil
Preocupações Desenvolvedor Ágil
Preocupações Desenvolvedor Ágil
Preocupações Desenvolvedor Ágil
Preocupações Desenvolvedor Ágil
Preocupações Desenvolvedor Ágil
Preocupações Desenvolvedor Ágil
Upcoming SlideShare
Loading in …5
×

Preocupações Desenvolvedor Ágil

472 views

Published on

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
472
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
5
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • SOLID, DRY, Reuse, …
  • Para nãoirpara o lado negro da força
  • Missão dada émissãocumprida – BOM SENSO!!!
  • Preocupações Desenvolvedor Ágil

    1. 1. Preocupações de um Desenvolvedor Ágil Paulo Igor
    2. 2. Não é apenas CÓDIGO
    3. 3. impacta a vida de milhares de pessoas
    4. 4. transforma a vida das pessoas
    5. 5. “Grandes poderes trazem grandes responsabilidades” (Ben Parker)
    6. 6. Comodidade Qualidade de Vida Tempo …
    7. 7. #FAIL
    8. 8. Programar é uma arte!
    9. 9. Qualidade
    10. 10. “Programar é um processo criativo e que exige aperfeiçoamento” Programar é uma arte!
    11. 11. …é necessário praticar!
    12. 12. DNA do programador
    13. 13. Preguiçoso e criativo!!!
    14. 14. “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito”
    15. 15. ...mas funciona!!!
    16. 16. Passa a encarar os problemas com naturalidade…
    17. 17. Pragmatic Programmer
    18. 18. The Pragmatic Programmer
    19. 19. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Care about your craft Think! About your work Provide options, don’t make lame excuses Don’t live with broken windows Be a catalyst for change Remember the Big Picture Make a quality a requirements issue Invest regularly in your knowledge portfolio Critically Analyze What You Read and Hear It's Both What You Say and the Way You Say It DRY—Don't Repeat Yourself Make It Easy to Reuse Eliminate Effects Between Unrelated Things There Are No Final Decisions Use Tracer Bullets to Find the Target Prototype to Learn Program Close to the Problem domain Estimate to Avoid Surprises Iterate the Schedule with the Code Keep Knowledge in Plain Text Use the Power of Command Shells Use a Single Editor Well Always Use Source Code Control Fix the Problem, Not the Blame Don't Panic "select" Isn't Broken Don't Assume It—Prove It Learn a Text Manipulation Language Write Code That Writes Code You Can't Write Perfect Software Design with Contracts Crash Early If It Can't Happen, Use Assertions to Ensure That It Won't Use Exceptions for Exceptional Problems Finish What You Start 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. Minimize Coupling Between Modules Configure, Don't Integrate Put Abstractions in Code Details in Metadata Analyze Workflow to Improve Concurrency Design Using Services Always Design for Concurrency Separate Views from Models Use Blackboards to Coordinate Workflow Don't Program by Coincidence Estimate the Order of Your Algorithms Test Your Estimates Refactor Early, Refactor Often Design to Test Test Your Software, or Your Users Will Don't Use Wizard Code You Don't Understand Don't Gather Requirements—Dig for Them Work with a User to Think Like a User Abstractions Live Longer than Details Use a Project Glossary Don't Think Outside the Box—Find the Box Listen to Nagging Doubts—Start When You're Ready Some Things Are Better Done than Described Don't Be a Slave to Formal Methods Expensive Too Do Not Produce Better Designs Organize Around Functionality, Not Job Functions Don't Use Manual Procedures Test Early. Test Often. Test Automatically. Coding Ain't Done 'Til All the Tests Run Use Saboteurs to Test Your Testing Test State Coverage, Not Code Coverage Find Bugs Once Treat English as Just Another Programming Language Build Documentation In, Don't Bolt It On Gently Exceed Your Users' Expectations Sign Your Work 70 Tips
    20. 20. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Care about your craft Think! About your work Provide options, don’t make lame excuses Don’t live with broken windows Be a catalyst for change Remember the Big Picture Make a quality a requirements issue Invest regularly in your knowledge portfolio Critically Analyze What You Read and Hear It's Both What You Say and the Way You Say It DRY—Don't Repeat Yourself Make It Easy to Reuse Eliminate Effects Between Unrelated Things There Are No Final Decisions Use Tracer Bullets to Find the Target Prototype to Learn Program Close to the Problem domain Estimate to Avoid Surprises Iterate the Schedule with the Code Keep Knowledge in Plain Text Use the Power of Command Shells Use a Single Editor Well Always Use Source Code Control Fix the Problem, Not the Blame Don't Panic "select" Isn't Broken Don't Assume It—Prove It Learn a Text Manipulation Language Write Code That Writes Code You Can't Write Perfect Software Design with Contracts Crash Early If It Can't Happen, Use Assertions to Ensure That It Won't Use Exceptions for Exceptional Problems Finish What You Start 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. Minimize Coupling Between Modules Configure, Don't Integrate Put Abstractions in Code Details in Metadata Analyze Workflow to Improve Concurrency Design Using Services Always Design for Concurrency Separate Views from Models Use Blackboards to Coordinate Workflow Don't Program by Coincidence Estimate the Order of Your Algorithms Test Your Estimates Refactor Early, Refactor Often Design to Test Test Your Software, or Your Users Will Don't Use Wizard Code You Don't Understand Don't Gather Requirements—Dig for Them Work with a User to Think Like a User Abstractions Live Longer than Details Use a Project Glossary Don't Think Outside the Box—Find the Box Listen to Nagging Doubts—Start When You're Ready Some Things Are Better Done than Described Don't Be a Slave to Formal Methods Expensive Too Do Not Produce Better Designs Organize Around Functionality, Not Job Functions Don't Use Manual Procedures Test Early. Test Often. Test Automatically. Coding Ain't Done 'Til All the Tests Run Use Saboteurs to Test Your Testing Test State Coverage, Not Code Coverage Find Bugs Once Treat English as Just Another Programming Language Build Documentation In, Don't Bolt It On Gently Exceed Your Users' Expectations Sign Your Work 1 – Care about your craft
    21. 21. Técnicas e Práticas
    22. 22. Pair Programming
    23. 23. Qualidade do Código “Clean Code” (Uncle Bob)
    24. 24. Ta uma bagunça, mas funciona!
    25. 25. Agora sim! 
    26. 26. Refatoração “Refactoring: Improving the Design of Existing Code” (Martin Fowler)
    27. 27. Testes
    28. 28. Testes Manuais
    29. 29. Testes Automáticos JUnit, JBehave, TestNG, Rspec, Cumcuber, Test::Unit, …
    30. 30. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Care about your craft Think! About your work Provide options, don’t make lame excuses Don’t live with broken windows Be a catalyst for change Remember the Big Picture Make a quality a requirements issue Invest regularly in your knowledge portfolio Critically Analyze What You Read and Hear It's Both What You Say and the Way You Say It DRY—Don't Repeat Yourself Make It Easy to Reuse Eliminate Effects Between Unrelated Things There Are No Final Decisions Use Tracer Bullets to Find the Target Prototype to Learn Program Close to the Problem domain Estimate to Avoid Surprises Iterate the Schedule with the Code Keep Knowledge in Plain Text Use the Power of Command Shells Use a Single Editor Well Always Use Source Code Control Fix the Problem, Not the Blame Don't Panic "select" Isn't Broken Don't Assume It—Prove It Learn a Text Manipulation Language Write Code That Writes Code You Can't Write Perfect Software Design with Contracts Crash Early If It Can't Happen, Use Assertions to Ensure That It Won't Use Exceptions for Exceptional Problems Finish What You Start 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. Minimize Coupling Between Modules Configure, Don't Integrate Put Abstractions in Code Details in Metadata Analyze Workflow to Improve Concurrency Design Using Services Always Design for Concurrency Separate Views from Models Use Blackboards to Coordinate Workflow Don't Program by Coincidence Estimate the Order of Your Algorithms Test Your Estimates Refactor Early, Refactor Often Design to Test Test Your Software, or Your Users Will Don't Use Wizard Code You Don't Understand Don't Gather Requirements—Dig for Them Work with a User to Think Like a User Abstractions Live Longer than Details Use a Project Glossary Don't Think Outside the Box—Find the Box Listen to Nagging Doubts—Start When You're Ready Some Things Are Better Done than Described Don't Be a Slave to Formal Methods Expensive Too Do Not Produce Better Designs Organize Around Functionality, Not Job Functions Don't Use Manual Procedures Test Early. Test Often. Test Automatically. Coding Ain't Done 'Til All the Tests Run Use Saboteurs to Test Your Testing Test State Coverage, Not Code Coverage Find Bugs Once Treat English as Just Another Programming Language Build Documentation In, Don't Bolt It On Gently Exceed Your Users' Expectations Sign Your Work 61 – Don’t use Manual Procedures
    31. 31. Automatização
    32. 32. Especificação Testável Concordion / FitNesse
    33. 33. TDD / BDD “TDD - Kent Beck / BDD - Dan North”
    34. 34. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Care about your craft Think! About your work Provide options, don’t make lame excuses Don’t live with broken windows Be a catalyst for change Remember the Big Picture Make a quality a requirements issue Invest regularly in your knowledge portfolio Critically Analyze What You Read and Hear It's Both What You Say and the Way You Say It DRY—Don't Repeat Yourself Make It Easy to Reuse Eliminate Effects Between Unrelated Things There Are No Final Decisions Use Tracer Bullets to Find the Target Prototype to Learn Program Close to the Problem domain Estimate to Avoid Surprises Iterate the Schedule with the Code Keep Knowledge in Plain Text Use the Power of Command Shells Use a Single Editor Well Always Use Source Code Control Fix the Problem, Not the Blame Don't Panic "select" Isn't Broken Don't Assume It—Prove It Learn a Text Manipulation Language Write Code That Writes Code You Can't Write Perfect Software Design with Contracts Crash Early If It Can't Happen, Use Assertions to Ensure That It Won't Use Exceptions for Exceptional Problems Finish What You Start 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. Minimize Coupling Between Modules Configure, Don't Integrate Put Abstractions in Code Details in Metadata Analyze Workflow to Improve Concurrency Design Using Services Always Design for Concurrency Separate Views from Models Use Blackboards to Coordinate Workflow Don't Program by Coincidence Estimate the Order of Your Algorithms Test Your Estimates Refactor Early, Refactor Often Design to Test Test Your Software, or Your Users Will Don't Use Wizard Code You Don't Understand Don't Gather Requirements—Dig for Them Work with a User to Think Like a User Abstractions Live Longer than Details Use a Project Glossary Don't Think Outside the Box—Find the Box Listen to Nagging Doubts—Start When You're Ready Some Things Are Better Done than Described Don't Be a Slave to Formal Methods Expensive Too Do Not Produce Better Designs Organize Around Functionality, Not Job Functions Don't Use Manual Procedures Test Early. Test Often. Test Automatically. Coding Ain't Done 'Til All the Tests Run Use Saboteurs to Test Your Testing Test State Coverage, Not Code Coverage Find Bugs Once Treat English as Just Another Programming Language Build Documentation In, Don't Bolt It On Gently Exceed Your Users' Expectations Sign Your Work 47 – Refactor Early, Refactor Often
    35. 35. Blindagem do Código
    36. 36. Design Evolutivo “TDD - Kent Beck / BDD - Dan North”
    37. 37. Continuous TDD / BDD Integration “TDD - Kent Beck / BDD - Dan North” (Martin Fowler)
    38. 38. Continuous Delivery (Jez Humble e David Farley)
    39. 39. Continuous Delivery (Jez Humble e David Farley)
    40. 40. da qualidade não se abre mão
    41. 41. “Arte de Programar”
    42. 42. “controle a força”
    43. 43. “Treinar pra quê?”
    44. 44. BOM SENSO!!!
    45. 45. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Care about your craft Think! About your work Provide options, don’t make lame excuses Don’t live with broken windows Be a catalyst for change Remember the Big Picture Make a quality a requirements issue Invest regularly in your knowledge portfolio Critically Analyze What You Read and Hear It's Both What You Say and the Way You Say It DRY—Don't Repeat Yourself Make It Easy to Reuse Eliminate Effects Between Unrelated Things There Are No Final Decisions Use Tracer Bullets to Find the Target Prototype to Learn Program Close to the Problem domain Estimate to Avoid Surprises Iterate the Schedule with the Code Keep Knowledge in Plain Text Use the Power of Command Shells Use a Single Editor Well Always Use Source Code Control Fix the Problem, Not the Blame Don't Panic "select" Isn't Broken Don't Assume It—Prove It Learn a Text Manipulation Language Write Code That Writes Code You Can't Write Perfect Software Design with Contracts Crash Early If It Can't Happen, Use Assertions to Ensure That It Won't Use Exceptions for Exceptional Problems Finish What You Start 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. Minimize Coupling Between Modules Configure, Don't Integrate Put Abstractions in Code Details in Metadata Analyze Workflow to Improve Concurrency Design Using Services Always Design for Concurrency Separate Views from Models Use Blackboards to Coordinate Workflow Don't Program by Coincidence Estimate the Order of Your Algorithms Test Your Estimates Refactor Early, Refactor Often Design to Test Test Your Software, or Your Users Will Don't Use Wizard Code You Don't Understand Don't Gather Requirements—Dig for Them Work with a User to Think Like a User Abstractions Live Longer than Details Use a Project Glossary Don't Think Outside the Box—Find the Box Listen to Nagging Doubts—Start When You're Ready Some Things Are Better Done than Described Don't Be a Slave to Formal Methods Expensive Too Do Not Produce Better Designs Organize Around Functionality, Not Job Functions Don't Use Manual Procedures Test Early. Test Often. Test Automatically. Coding Ain't Done 'Til All the Tests Run Use Saboteurs to Test Your Testing Test State Coverage, Not Code Coverage Find Bugs Once Treat English as Just Another Programming Language Build Documentation In, Don't Bolt It On Gently Exceed Your Users' Expectations Sign Your Work 30 – You Can’t Write Perfect Software
    46. 46. Deixe seu legado!!!
    47. 47. Obrigado! Paulo Igor

    ×