Le pratiche ingegneristiche di eXtreme Programming
3 likes473 views
Il documento presenta un'introduzione alle pratiche ingegneristiche del Extreme Programming (XP) di Andrea Francia, discutendo l'importanza delle pratiche come il pair programming, il testing automatico e il refactoring. Viene evidenziato come XP integri pratiche tecniche con metodi agili come Scrum per migliorare la qualità del software e la produttività del team. Inoltre, l'autore condivide esperienze personali e suggerimenti pratici per implementare con successo queste pratiche nel lavoro di squadra.
Le pratiche ingegneristiche di eXtreme Programming
- 1. @andreafrancia Introduzione alle pratiche ingegneristiche di eXtreme Programming Andrea Francia Agile Day(s) 2018 a Brescia 10 novembre 2018
- 3. Sono un programmatore da tanto tempo
- 5. Trovo comodo usare i test automatici per lavorare
- 6. Occasionalmente faccio il coach (di TDD)
- 7. Conduco il TDD Milano
- 8. Ho un progetto open source
- 9. Ho cambiato un sacco di aziende
- 10. @andreafrancia Mi ero fatto un idea di cosa fosse l’ingegneria del software
- 14. @andreafrancia
- 16. @andreafrancia
- 17. @andreafrancia Quanti ce ne restano? Survived ? Survived !
- 19. @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
- 20. @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
- 24. @andreafrancia
- 25. @andreafrancia Come vanno le cose in un progetto XP?
- 26. @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
- 27. @andreafrancia Per ottenere questi risultati i programmatori impiegano le pratiche di XP
- 28. @andreafrancia Quali sono le pratiche ingegneristiche?
- 34. @andreafrancia Quante sono le 12 pratiche XP? 12! 1999 13! 2002 13! 24! 2004
- 35. @andreafrancia ~50 Quante sono le 12 pratiche XP?
- 36. @andreafrancia Le pratiche ingegneristiche (*) (*) solo le classiche
- 37. @andreafrancia Pair Programming – tutto il codice di produzione è scritto da due programmatori che lavorano sullo stesso computer.
- 38. @andreafrancia Simple Design – il sistema viene mantenuto il più semplice possibile rimuovendo ogni complessità non appena scoperta.
- 39. @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.
- 40. @andreafrancia Refactoring – i programmatori ristrutturano il sistema senza cambiarne il comportamento per: rimuovere duplicazione, migliorarne l’espressività, per semplificarlo, or per aggiungergli flessibilità.
- 41. @andreafrancia Collective Ownership – Chiunque, in ogni momento, e dovunque nel sistema può modificare il codice.
- 42. @andreafrancia Continuous integration – il sistema viene integrato e ricostruito più volte al giorno, ogni volta che si finisce un task.
- 43. @andreafrancia Coding standards – i programmatori scrivono tutto il codice in accordo a delle regole che supportino la comunicazione attraverso il codice.
- 44. @andreafrancia La mia esperienza con le pratiche
- 46. @andreafrancia L’antenato del pair programming è la revisione tecnica formale.
- 47. @andreafrancia 8 ore di pair programming sono troppe (*)
- 48. @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.
- 49. @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à
- 50. @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
- 51. @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)
- 52. @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.
- 54. @andreafrancia La pratica più fastidiosa, o forse no?
- 55. @andreafrancia Non è solo una questione di graffa su o graffa giù.
- 56. @andreafrancia
- 57. @andreafrancia Coding Standards • I programmatori si accordano su uno standard di sviluppo condiviso e accettato volontariamente.
- 58. @andreafrancia Non è necessario scrivere un documento!
- 59. @andreafrancia Tradizione orale + “buon” esempio
- 60. @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
- 61. @andreafrancia
- 64. @andreafrancia È l’alternativa al debugging disperato
- 65. @andreafrancia È indispensabile per il refactor
- 66. @andreafrancia “non puoi sempre metterci un taccone”
- 67. @andreafrancia “hai cambiato un codice che funzionava!”
- 68. @andreafrancia “se non è rotto non aggiustarlo!”
- 69. @andreafrancia I framework xUnit ci sono per qualsiasi linguaggio
- 70. @andreafrancia
- 71. Se non ci sono si creano
- 72. 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
- 74. @andreafrancia Fate 20 minuti di pratica ogni mattina con jUnit, fate un kata
- 75. @andreafrancia Andate a (o fondate) un meetup sul TDD
- 76. @andreafrancia Non chiedete al management di poter testare
- 77. @andreafrancia Al posto di fare il debug a mano fate dei main() alternativi
- 78. @andreafrancia Quando vi chiedono di aggiustare un baco scrivete prima un test che lo verifica
- 80. @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.
- 81. @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
- 82. @andreafrancia Usare il simple design per valutare un refactor
- 83. @andreafrancia Se un refactor non migliora il design si butta
- 85. @andreafrancia È l’unico modo che abbiamo per iniettare design nel codice
- 86. @andreafrancia Se non hai test te lo sogni, non hai idea di dove puoi arrivare
- 87. @andreafrancia Una volta facevo refactor senza test…
- 88. @andreafrancia Refactor e test lenti
- 90. @andreafrancia Anche i test chiedono il refactor
- 92. @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.”
- 94. @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)
- 95. @andreafrancia Refactor per semplificare (1) • Si può aumentare l’espressività del codice, esempi: • aggiungere nomi • migliorare nomi • promuovere simmetria
- 96. @andreafrancia Refactor per semplificare (2) • Si può rimuovere codice superfluo: • rimuovendo la duplicazione • rimuovendo codice non usato • rimuovendo sovrastrutture che ora non servono più
- 97. @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
- 100. 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.
- 103. @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)
- 104. @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
- 105. @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
- 107. @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.
- 108. @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 …
- 109. @andreafrancia Il refactor in TDD all tests passing one failing test Aggiungi velocemente un test Fai una piccola modifica al codice di produzione Refactor
- 111. When refactor?
- 112. Test lenti e test veloci
- 114. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall
- 115. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall
- 116. 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
- 117. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall
- 118. • fast • reliable • slow • fragile
- 124. @andreafrancia Continuous Integration ≠ merge da master
- 125. @andreafrancia Cosa vuol dire integrare due linee di sviluppo?
- 126. @andreafrancia I problemi di integrazione crescono in modo super lineare con il tempo
- 127. @andreafrancia I problemi di integrazione crescono con la dimensione della codebase
- 128. @andreafrancia Integrazione continua applicata alle dipendenze
- 129. @andreafrancia Daily deployment (una specie di integrazione continua)
- 130. Il rosso giusto
- 135. @andreafrancia Grazie Vorresti che lavorassi per te? Chiamami +39 3209437233