Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Le pratiche ingegneristiche di eXtreme Programming

35 views

Published on

Le pratiche ingegneristiche sono il sottoinsieme delle pratiche descritte nei libri di eXtreme Programming che hanno direttamente a che fare con le modalità con cui si scrive/progetta/verifica il software.
Esse sono:
- il Simple Design
- il Test-Driven Development
- la Continuous Integration
- il Refactoring, e
- il Pair Programming.

Sono famose di nome, ma non sempre è possibile venire a contatto con una loro definizione corretta, ed è facile farsi un'idea sbagliata di cosa siano e trovare problemi ad applicarle in modo efficace alla propria situazione.

Spiegherò come ognuna di queste pratiche possono aiutarci nello sviluppo software portando esempi presi dal mio lavoro quotidiano o dal lavoro di altre persone con cui sono venuto in contatto.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Le pratiche ingegneristiche di eXtreme Programming

  1. 1. @andreafrancia Introduzione alle pratiche ingegneristiche di eXtreme Programming Andrea Francia Agile Day(s) 2018 a Brescia 10 novembre 2018
  2. 2. @andreafrancia Chi sono
  3. 3. Sono un programmatore da tanto tempo
  4. 4. @andreafrancia Faccio cose
  5. 5. Trovo comodo usare i test automatici per lavorare
  6. 6. Occasionalmente faccio il coach (di TDD)
  7. 7. Conduco il TDD Milano
  8. 8. Ho un progetto open source
  9. 9. Ho cambiato un sacco di aziende
  10. 10. @andreafrancia Mi ero fatto un idea di cosa fosse l’ingegneria del software
  11. 11. @andreafrancia Ma poi …
  12. 12. @andreafrancia Test > Documentazione
  13. 13. @andreafrancia
  14. 14. @andreafrancia Cos’è XP?
  15. 15. @andreafrancia
  16. 16. @andreafrancia Quanti ce ne restano? Survived ? Survived !
  17. 17. @andreafrancia Scrum
  18. 18. @andreafrancia Scrum in breve (secondo me) • Team crossfunzionali • Team che si auto organizzano • Rilasci incrementali • Timeboxing (1 settimana o più) • Pianificazione continua • Plan-Do-Check-Act
  19. 19. @andreafrancia XP Scrum (about programming) (anything) Iterations Sprints Planning Game Sprint Planning Meeting Stories/Cards Product Backlog Items Not so fixed Fixed Sprint Backlog Engineering Practices See XP Engineering Practices: TDD, Pair Prorgramming, Simple Design, Refactoring
  20. 20. @andreafrancia  XP ❤ Scrum https://medium.com/agile-outside-the-box/better-together-xp-and-scrum-c69bf9bffcff
  21. 21. @andreafrancia Scrum + Technical practices ≈ XP
  22. 22. @andreafrancia Scrum - Technical practices = ?
  23. 23. @andreafrancia
  24. 24. @andreafrancia Come vanno le cose in un progetto XP?
  25. 25. @andreafrancia In un progetto XP … • In ogni momento c’è un sistema funzionante (*) && • Periodicamente al sistema vengono aggiunte nuove feature (*) && • Non ci sono regressioni (*) && • Il sistema risolve un problema del cliente <— (oggi non ne parliamo però) (*) in produzione
  26. 26. @andreafrancia Per ottenere questi risultati i programmatori impiegano le pratiche di XP
  27. 27. @andreafrancia Quali sono le pratiche ingegneristiche?
  28. 28. @andreafrancia Quante sono le 12 pratiche XP? 12! 1999 13! 2002 13! 24! 2004
  29. 29. @andreafrancia ~50 Quante sono le 12 pratiche XP?
  30. 30. @andreafrancia Le pratiche ingegneristiche (*) (*) solo le classiche
  31. 31. @andreafrancia Pair Programming – tutto il codice di produzione è scritto da due programmatori che lavorano sullo stesso computer.
  32. 32. @andreafrancia Simple Design – il sistema viene mantenuto il più semplice possibile rimuovendo ogni complessità non appena scoperta.
  33. 33. @andreafrancia Testing – i programmatori scrivono continuamente nuovi unit test che devono sempre passare tutti perché lo sviluppo possa continuare. Anche i clienti scrivono test. I test dei clienti devono dimostrare che una feature è conclusa.
  34. 34. @andreafrancia Refactoring – i programmatori ristrutturano il sistema senza cambiarne il comportamento per: rimuovere duplicazione, migliorarne l’espressività, per semplificarlo, or per aggiungergli flessibilità.
  35. 35. @andreafrancia Collective Ownership – Chiunque, in ogni momento, e dovunque nel sistema può modificare il codice.
  36. 36. @andreafrancia Continuous integration – il sistema viene integrato e ricostruito più volte al giorno, ogni volta che si finisce un task.
  37. 37. @andreafrancia Coding standards – i programmatori scrivono tutto il codice in accordo a delle regole che supportino la comunicazione attraverso il codice.
  38. 38. @andreafrancia La mia esperienza con le pratiche
  39. 39. @andreafrancia Pair Programming
  40. 40. @andreafrancia L’antenato del pair programming è la revisione tecnica formale.
  41. 41. @andreafrancia 8 ore di pair programming sono troppe (*)
  42. 42. @andreafrancia Come lo posso introdurre nel mio team? • Non chiedete il permesso di fare Pair Programming. • Quando c’è qualcosa di difficile da fare chiedete aiuto. • Quando c’è qualcuno in difficoltà offrigli il tuo aiuto.
  43. 43. @andreafrancia Pair Programming e produttività • Uno per minare la produttività di un team è dare obiettivi diversi ad ogni membro del team. • Gli obiettivi di team dovrebbero essere ordinati per priorità e non assegnati alle singole persone. • Tutti i membri del team dovrebbero auto-organizzarsi per chiudere prima i task a più alta priorità
  44. 44. @andreafrancia Pre-requisiti e aiuto • Codice Condiviso (tra tutto il team) • Priorità sui task condivisa • Credere che far rivedere il codice ad un altra persona abbia un valore
  45. 45. @andreafrancia Dove venire a sperimentarlo • Global Day of Code Retreat (17 novembre 2018) • https://www.coderetreat.org/ • Incontri del vostro XPUG (o del TDD Milano)
  46. 46. @andreafrancia Collective Code Ownership • Tutto il codice codice appartiene al progetto, non al singolo programmatore. • Se una coppia incontra un pezzo di codice che può essere migliorato lo migliora. • Se una coppia ha bisogno di modificare un pezzo di codice per implementare una feature lo modifica.
  47. 47. @andreafrancia Coding Standards
  48. 48. @andreafrancia La pratica più fastidiosa, o forse no?
  49. 49. @andreafrancia Non è solo una questione di graffa su o graffa giù.
  50. 50. @andreafrancia
  51. 51. @andreafrancia Coding Standards • I programmatori si accordano su uno standard di sviluppo condiviso e accettato volontariamente.
  52. 52. @andreafrancia Non è necessario scrivere un documento!
  53. 53. @andreafrancia Tradizione orale + “buon” esempio
  54. 54. @andreafrancia Esempi di regole che abbiamo usato • Dividere i commit di Refactor da quelli di cambio del comportamento • Committare solo in verde • Committare spesso in verde • Mai cambiare la formattazione di un file che alla fine non andava modificato • End-of-line alla fine del file • Tastiera US -vs- International o italiana
  55. 55. @andreafrancia
  56. 56. @andreafrancia Testing automatico
  57. 57. @andreafrancia Pratica utile indipendentemente da XP
  58. 58. @andreafrancia È l’alternativa al debugging disperato
  59. 59. @andreafrancia È indispensabile per il refactor
  60. 60. @andreafrancia “non puoi sempre metterci un taccone”
  61. 61. @andreafrancia “hai cambiato un codice che funzionava!”
  62. 62. @andreafrancia “se non è rotto non aggiustarlo!”
  63. 63. @andreafrancia I framework xUnit ci sono per qualsiasi linguaggio
  64. 64. @andreafrancia
  65. 65. Se non ci sono si creano
  66. 66. Two kind of tests • unit test written by the programmers to convince themselves that their programs work the way they think the program work. • functional tests written by (or at least specified by) the customers to convince themselves that the system as a whole works the way they think the system as a whole should work. eXtreme Programming explained 1st ed - Kent Beck - p. 47
  67. 67. @andreafrancia Da dove iniziare?
  68. 68. @andreafrancia Fate 20 minuti di pratica ogni mattina con jUnit, fate un kata
  69. 69. @andreafrancia Andate a (o fondate) un meetup sul TDD
  70. 70. @andreafrancia Non chiedete al management di poter testare
  71. 71. @andreafrancia Al posto di fare il debug a mano fate dei main() alternativi
  72. 72. @andreafrancia Quando vi chiedono di aggiustare un baco scrivete prima un test che lo verifica
  73. 73. @andreafrancia Design incrementale
  74. 74. @andreafrancia Design incrementale • Si evita il Big Design Up Front • Nel codice è presente solo quanto design basta per soddisfare i requisiti correnti. • Il design del sistema è il più semplice possibile, si toglie il superfluo. (semplice non vuol dire facile) • Quando il design a disposizione non è più sufficiente ne iniettiamo dell’altro.
  75. 75. @andreafrancia Simple Design Ad un dato momento il giusto design per un software è quello che: 1.Fa passare tutti i test. 2.Non contiene logica duplicata 3.Rende chiaro il motivo per è stato scritto 4.Contiene il numero minimo di elementi
  76. 76. @andreafrancia Usare il simple design per valutare un refactor
  77. 77. @andreafrancia Se un refactor non migliora il design si butta
  78. 78. @andreafrancia Refactor
  79. 79. @andreafrancia È l’unico modo che abbiamo per iniettare design nel codice
  80. 80. @andreafrancia Se non hai test te lo sogni, non hai idea di dove puoi arrivare
  81. 81. @andreafrancia Una volta facevo refactor senza test…
  82. 82. @andreafrancia Refactor e test lenti
  83. 83. @andreafrancia Architettura esagonale
  84. 84. @andreafrancia Anche i test chiedono il refactor
  85. 85. @andreafrancia Quando fare refactor?
  86. 86. @andreafrancia Refactor prima • “When implementing a program feature, the programmers always ask if there is a way of changing the existing program to make adding the feature simple.”
  87. 87. @andreafrancia Mikado Method http://www.methodsandtools.com/archive/mikado.php
  88. 88. @andreafrancia Refactor dopo • Dopo aver aggiunto una feature i programmatori si chiedono se riescono a vedere dei modi per rendere il programma più semplice (i test intanto devono continuare a funzionare)
  89. 89. @andreafrancia Refactor per semplificare (1) • Si può aumentare l’espressività del codice, esempi: • aggiungere nomi • migliorare nomi • promuovere simmetria
  90. 90. @andreafrancia Refactor per semplificare (2) • Si può rimuovere codice superfluo: • rimuovendo la duplicazione • rimuovendo codice non usato • rimuovendo sovrastrutture che ora non servono più
  91. 91. @andreafrancia Quando il sistema chiede Refactor? • Quando c’è della duplicazione • Quando è difficile mettere sotto test una classe o un metodo • Quando modifichi un comportamento e poi si rompono N test • Quando provando a raccontare cosa fa il codice ad un altro programmatore ti accorgi di usare parole diverse da quelle nel codice
  92. 92. @andreafrancia Test-First
  93. 93. @andreafrancia Test-First ≠ TDD
  94. 94. Why Test First? • The test gives me a chance to think about what I want independent of how it will be implemented. • Then the test tell me if I implement what I thought I implemented.
  95. 95. @andreafrancia Test-Driven Development
  96. 96. @andreafrancia Gli ingredienti di TDD • Lo sviluppo è incrementale • I test scritti prima del codice (Test First) • Il design applicato in maniera incrementale e continua (Incremental Design)
  97. 97. @andreafrancia Pseudo-TDD • Penso ad una soluzione • Mi immagino un insieme di classi e funzioni che so che avrò bisogno di creare • Scrivo qualche test che ne verifica l’esistenza • Lancio tutti i test e li vedo fallire • Implemento un po’ di roba • Lancio tutti i test e li vedo fallire • Vado di debug duro • Lancio tutti i test e passano • (Opzionale) Da qualche parte mi metto un TODO dicendo di ritornare a pulire più avanti
  98. 98. @andreafrancia Il ritmo del TDD 1. aggiungi velocemente un test 2. lancia tutti i test, vedi quello nuovo fallire 3. fai una piccola modifica 4. lancia tutti i test, vedi che tutti passano 5. fai refactor per rimuovere la duplicazione Test Driven Development: By Example by Beck, Kent
  99. 99. @andreafrancia La TODO list http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/ KentBeck_TDD_byexample.pdf
  100. 100. @andreafrancia Le tre leggi del TDD 1. Non ti è permesso scrivere codice di produzione a meno che non sia per fare passare un test che sta fallendo. 2. Non ti è permesso aggiungere codice ad un test più di quello che sia sufficiente a farlo fallire; e gli errori di compilazione contano come fallimenti. 3. Non ti è permesso aggiungere più codice di produzione di quello che sia sufficiente per far passare un test che fallisce.
  101. 101. @andreafrancia I colori del TDD 1. Parti pulito 2. Aggiungi velocemente un test, lancia tutti i test e vedi fallire quello nuovo 3. Fai una piccola modifica (al codice di produzione), lancia tutti i test e vedi che ora passano tutti 4. Un passo alla volta rimuovi tutta la duplicazione, ad ogni passo lancia i test e vedili passare tutti. (Refactor) FAIL PASS PASS PASS PASS PASS …
  102. 102. @andreafrancia Il refactor in TDD all tests passing one failing test Aggiungi velocemente un test Fai una piccola modifica 
 al codice di produzione Refactor
  103. 103. When refactor?
  104. 104. Test lenti e test veloci
  105. 105. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall
  106. 106. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall
  107. 107. What is not unit test? A test is not a unit test if: 1.It talks to a database. 2.It communicates across a network. 3.It touches the file system. 4.Requires some manual set-up Working Effectively with Legacy Code - Michael Feathers
  108. 108. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall
  109. 109. • fast • reliable • slow • fragile
  110. 110. http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
  111. 111. @andreafrancia Continuous Integration
  112. 112. @andreafrancia Continuous Integration ≠ Jenkins
  113. 113. @andreafrancia Continuous Integration ≠ Git Flow
  114. 114. @andreafrancia Continuous Integration ≠ merge da master
  115. 115. @andreafrancia Cosa vuol dire integrare due linee di sviluppo?
  116. 116. @andreafrancia I problemi di integrazione crescono in modo super lineare con il tempo
  117. 117. @andreafrancia I problemi di integrazione crescono con la dimensione della codebase
  118. 118. @andreafrancia Integrazione continua applicata alle dipendenze
  119. 119. @andreafrancia Daily deployment (una specie di integrazione continua)
  120. 120. Il rosso giusto
  121. 121. @andreafrancia Grazie Vorresti che lavorassi per te? Chiamami +39 3209437233

×