Trust me, I'm a developer
Download as PPTX, PDF4 likes566 views
Il documento descrive cinque caratteristiche principali di uno sviluppatore affidabile: 1) puntare alla semplicità per evitare la complessità del codice, 2) bilanciare debito tecnico e valore di business, 3) sviluppare guidato dai test, 4) automatizzare i processi sin dal primo giorno, e 5) porre gli utenti al centro del processo di sviluppo. Questi principi mirano a creare codice mantenibile, ben documentato e a ridurre il debito tecnico. È fondamentale vedere il software come un asset strategico piuttosto che un semplice prodotto funzionante.
Trust me, I'm a developer
- 1. Quali sono le caratteristiche principali che contraddistinguono uno sviluppatore affidabile? Giulio Roggero … in 5 punti
- 2. 1 - Punta alla semplicità
- 4. Lasagna code
- 5. Da dove derivano i bug? •Complessità del codice che aumenta con il passare del tempo •Non conoscenza della tecnologia •Incomprensioni
- 6. Quindi, cosa fare per limitare il problema?
- 9. 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
- 10. 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!
- 11. 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
- 12. Consiglio Posticipare il più possibile le decisioni irreversibili evitando l’over- engineering della soluzione.
- 13. 2 - Bilancia debito tecnico e valore di business
- 15. Tempo Valore di business generato Ritardo del rilascio Costo del ritardo
- 16. Tempo Valore di business generato Rilascio o non rilascio con debito? Debito accumulato rappresentazione semplificata
- 18. Costo del ritardo Debito accumulato Rilascia ora con debito e ripaga Costo del ritardo Debito accumulato Rilascia in ritardo
- 19. Tempo Debito tecnico totale In ogni caso tenere sotto controllo il debito tecnico Fuori controllo Sotto controllo Attenzione!
- 20. Product Backlog Le azioni per ripagare il debito tecnico vanno nel product backlog insieme alle store di business!
- 21. Consiglio Rendere sempre visibile il debito tecnico e ordinare nel backlog azioni per tenerlo sotto controllo
- 22. 3 - Sviluppa guidato dai test
- 23. Scrivo il test Scrivo il codice per passare quel test. Solo quello! Faccio refactoring del codice Ogni 10 minuti A piccoli passi TDD
- 24. Esempio di test Test Codice dopo refactoring Check if it fits Prepare vehicle Create new order … e dopo refactoring anche del test!
- 25. Quanti test? Test Manuali Unit API UI
- 26. 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
- 27. Consiglio Inizia a scrivere i test, anche semplici, ma inizia. Esercitati. Ci vogliono mesi, anche anni, per prenderci la mano. Non mollare subito!
- 28. 4 - Rende tutto automatico, fin dal primo giorno
- 30. 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
- 31. Quando farlo? Automatizzate la “hello world application” implementata sulla vostra architetturaDallo Sprint Zero!
- 32. 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.
- 33. Consiglio Automatizzare subito costa anche 100 volte meno di farlo dopo. Parti semplice e non aspettare!
- 34. 5 - Non si innamora della tecnologia ma degli utenti!
- 37. 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?
- 38. 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
- 39. 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!
- 40. 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
- 41. Consiglio Quando scrivi il codice pensa sempre come impatterà sul comportamento dell’utente finale (vale anche per le parti senza interfaccia utente!)
- 42. Riassumendo
- 43. 1. Semplicità 2. Debito tecnico e valore 3. Test prima! 4. Tutto automatico 5. Utenti al centro
- 44. Il software è un asset! Non pensiamo ”basta che funzioni”, altrimenti alla lunga avremo costruito un asset pericolante.