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.

Trust me, I'm a developer

272 views

Published on

Talk Agile O'Day Napoli - 2017
Cosa contraddistingue uno sviluppatore affidabile? In questa presentazione si parla di:

- Semplicità
- Debito tecnico e valore
- Test prima!
- Tutto automatico
- Utenti al centro

Published in: Technology

Trust me, I'm a developer

  1. 1. Quali sono le caratteristiche principali che contraddistinguono uno sviluppatore affidabile? Giulio Roggero … in 5 punti
  2. 2. 1 - Punta alla semplicità
  3. 3. Spaghetti code
  4. 4. Lasagna code
  5. 5. Da dove derivano i bug? •Complessità del codice che aumenta con il passare del tempo •Non conoscenza della tecnologia •Incomprensioni
  6. 6. Quindi, cosa fare per limitare il problema?
  7. 7. Aumentiamo la documentazione! https://www.flickr.com/photos/theeerin/145287882
  8. 8. Una regola empirica • Lo fai una volta, lo fai cablato • Lo fai 2 volte inizi a generalizzarlo • Lo fai 3 o più volte è un Pattern Factory
  9. 9. Architettura emergente • Architettura ”hello world” • Partire risolvendo problemi puntuali • Validarli • Man mano che le responsabilità emergono identificare i Patterns Nota: non partire subito con un framework solo perché lo usano tutti!
  10. 10. Stili architetturali • Microservices • Client-Server • Blackboard • Pipe and filters • Plugins • Layered • Monolithic … tutta la lista su https://en.wikipedia.org/wiki/Software_architecture#Architectural_styles_and_patterns
  11. 11. Consiglio Posticipare il più possibile le decisioni irreversibili evitando l’over- engineering della soluzione.
  12. 12. 2 - Bilancia debito tecnico e valore di business
  13. 13. Tempo Costo per aggiungere nuova funzionalità Debito tecnico Debito Tecnico
  14. 14. Tempo Valore di business generato Ritardo del rilascio Costo del ritardo
  15. 15. Tempo Valore di business generato Rilascio o non rilascio con debito? Debito accumulato rappresentazione semplificata
  16. 16. Costo del ritardo Debito accumulato
  17. 17. Costo del ritardo Debito accumulato Rilascia ora con debito e ripaga Costo del ritardo Debito accumulato Rilascia in ritardo
  18. 18. Tempo Debito tecnico totale In ogni caso tenere sotto controllo il debito tecnico Fuori controllo Sotto controllo Attenzione!
  19. 19. Product Backlog Le azioni per ripagare il debito tecnico vanno nel product backlog insieme alle store di business!
  20. 20. Consiglio Rendere sempre visibile il debito tecnico e ordinare nel backlog azioni per tenerlo sotto controllo
  21. 21. 3 - Sviluppa guidato dai test
  22. 22. Scrivo il test Scrivo il codice per passare quel test. Solo quello! Faccio refactoring del codice Ogni 10 minuti A piccoli passi TDD
  23. 23. Esempio di test Test Codice dopo refactoring Check if it fits Prepare vehicle Create new order … e dopo refactoring anche del test!
  24. 24. Quanti test? Test Manuali Unit API UI
  25. 25. Il Test Driven Development (TDD) non è solo una buona pratica di test ma è soprattutto una pratica per creare codice migliore! Chiaro da leggere 01 Mantenibile 02 Documentato 03 Semplice 04
  26. 26. Consiglio Inizia a scrivere i test, anche semplici, ma inizia. Esercitati. Ci vogliono mesi, anche anni, per prenderci la mano. Non mollare subito!
  27. 27. 4 - Rende tutto automatico, fin dal primo giorno
  28. 28. Esempio di automatismo Developer PC Git Push Jenkins Pipeline Pull Integration test server Deploy and Test Pre Prod server Deploy and Test Prod Server Deploy and Test
  29. 29. Quando farlo? Automatizzate la “hello world application” implementata sulla vostra architetturaDallo Sprint Zero!
  30. 30. Automatizzare il prima possibile 1. Build automatica con aggiornamento di tutte le librerie da repository dei sorgenti (npm, maven o altro). No copie di librerie a mano. 2. Tutta la catena dei test up and running e non solo gli Unit ma fino ai test in produzione. 3. Verifica statica del codice con linters. 4. Adottare un'adeguata politica di branch. Più semplice è meglio è. 5. Implementare la catena di continuous: integration, delivery e deploy. 6. Definire un'adeguata politica di versionamento del codice. 7. Agganciare in modo corretto al codice loggers e analytics.
  31. 31. Consiglio Automatizzare subito costa anche 100 volte meno di farlo dopo. Parti semplice e non aspettare!
  32. 32. 5 - Non si innamora della tecnologia ma degli utenti!
  33. 33. Mangiare sano Mangiare cibo buono Non mangiare sempre la stessa cosa Sfruttare al massimo la pausa pranzo per rilassarsi Non spendere troppe energie nella scelta di cosa mangiare Scegliere i piatti da mobile e web Pagare senza dover inserire ogni volta la carta di credito Consegna in 20’ Piatti buoni, sani e caldi grazie ad un menu equilibrato Prenotare la consegna per un orario desiderato Creare un nuovo segmento di mercato differenziandosi dai food delivery classici Chi vuole mangiare nel Week-end o è fuori Milano Persone che lavorano o studiano nel centro di Milano Foorban.com. Selezioniamo gli ingredienti più freschi e cuciniamo un menù diverso ogni giorno. Ordina i tuoi piatti preferiti e saranno consegnati in 20’ Vision BOARD Target Group Needs Product Business Value Who is out?
  34. 34. Marketing manager di una multinazionale 30 anni, laureata. Sportiva e dinamica. Le piace tenersi in forma ed è attenta a cosa mangia. Ama sperimentare nuovi ingredienti a tavola. Sfruttare al meglio la pausa pranzo andando in palestra. Mangiare sano e buono. Non spendere troppo tempo nella scelta. Anna
  35. 35. Sceglie piatto Chissà cosa c’è di buono oggi? Ho fame! Se la foto mi attira lo prendo Prendo il cellulare Scorro i piatti Guardo la foto Aggiungo il piatto al carrello Descrizione … Attenzione: le foto devono essere molto ben fatte!
  36. 36. Sceglie piatto Invia ordine Verifica la consegna Sfoglia piatti Dettagli piatto Aggiungi piatto Sceglie orario Conferma Paga Guarda dov’è il piatto sulla mappa Leggi quanto manca alla consegna Assistenza Conferma ordine
  37. 37. Consiglio Quando scrivi il codice pensa sempre come impatterà sul comportamento dell’utente finale (vale anche per le parti senza interfaccia utente!)
  38. 38. Riassumendo
  39. 39. 1. Semplicità 2. Debito tecnico e valore 3. Test prima! 4. Tutto automatico 5. Utenti al centro
  40. 40. Il software è un asset! Non pensiamo ”basta che funzioni”, altrimenti alla lunga avremo costruito un asset pericolante.
  41. 41. Giulio Roggero www.agilereloaded.it www.intre.it www.mia-platform.eu @giulioroggero

×