Download as PDF, PPTX
Uploaded byAlberto Brandolini
L'illusione dell'ortogonalità
Il documento discute l'importanza del test-driven development (TDD) e dei contesti delimitati ('bounded context') nella programmazione, evidenziando come un'implementazione adeguata possa migliorare l'affidabilità del codice e la pianificazione. Tuttavia, il TDD e altre pratiche possono fallire in contesti senza confini definiti, portando a maggiori ansie e problemi di architettura. Viene anche sottolineato che le architetture centrate sui dati possono aumentare le dipendenze e il coordinamento necessario fra i team, influenzando negativamente l'evoluzione del business.
L'illusione dell'ortogonalità
- 1.
- 2. About me • Codingsince 1982 • … but that’s not what I get paid for • #DDDesign #Agile #Lean #Complexity • I invented • I smell • I run
- 3. Test-Driven Development Cose chefunzionano, ma a volte no
- 4. Come funziona? TDD Codice affidabile Apertiad opportunita’ Stime piu’ precise Disponibile alle evoluzioni Design Migliore #Pratiche #Architettura #Business #Processo #Persone Se fatto bene… Piano piano… Che ci vuole?
- 5. TDD non e’una pratica strettamente ingegneristica #Pratiche #Architettura #Business #Processo #Persone Impatti a livello di ansia, pianificazione, e reattivita’ business Ansia Pianificazione Reattivita’
- 6.
- 8. Pero’ non sempre funziona… Cisono situazioni in cui queste promesse non vengono mantenute
- 9. “I miei colleghinon fanno TDD” TDD Commit distruttivi #Pratiche #Architettura #Business #Processo #Persone No TDD WTF! Copertura a macchia di leopardo
- 11. Rendiamo Evidente il contesto Contesto Quelloche troppo spesso dimentichiamo, o e’ sottinteso, ma che fa la differenza. 🙂
- 12. Dove funziona? TDD Codice affidabile Apertiad opportunita’ Stime piu’ precise Disponibile alle evoluzioni Design Migliore #Pratiche #Architettura #Business #Processo #Persone Se fatto bene… Piano piano… Confini ben precisi Mancava un ingrediente! Pet Project - POC Un solo sviluppatore, su un progetto ben definito 🙂 Team Agreement Un team con un approccio simile su una porzione ben definita del sistema. 🙂
- 13. Non puo’ funzionarese… Applico TDD Commit distruttivi #Pratiche #Architettura #Business #Processo #Persone Non applico TDD WTF! Copertura a macchia di leopardo Big Ball of Mud Piu’ sviluppatori, senza confini precisi. 😳 Big Ball of Mud Continuo turnover su una codebase senza padroni 😳 Confini non definiti
- 14. Qualche nota Il contestomi serve a capire dove una cosa puo’ funzionare Guardiamo a quello che in Blog Posts, Articoli, Libri e’ sottinteso Per capire il sottinteso devo provare in contesti diversi (o confrontarmi con colleghi)
- 17. I confini contano Confini Ricordatevidi Romolo!
- 18. Bounded Context • Unita’di consistenza del linguaggio • Un modello costruito attorno ad uno scopo ben preciso Bounded Context (Questo l’ho imparato da Domain-Driven Design)
- 19. Un singolo scopo Piu’Facile ottimizzare per un solo obiettivo
- 21. Qui no! In unBC ben definito il codice DEVE essere semplice
- 22. Ma non sitratta solo di modelli e linguaggi…
- 23. Motivation • Autonomy • Mastery •Purpose https://vimeo.com/15488784
- 24. Bounded Context • Unita’di consistenza del linguaggio • Un modello costruito attorno ad uno scopo ben preciso • UN confine che permette l’implementazione di pratiche ed accordi “speciali” tra colleghi • Un “luogo” dove possiamo fare la cosa giusta senza compromessi Bounded Context
- 25. primo progetto enterprise(2001) In una banca Stack Tecnologico ‘aggressivo’ Persistenza privata Domain Model sofisticato Modello dei dati non convenzionale Continuous integration Test Engine
- 26. Circolo Virtuoso Se nonfunziona, puo’ essere solo colpa nostra QUINDI deve funzionare QUINDI Lo testiamo
- 27. Confini ben definiti Limitanoil rischio Liberta’ di sperimentare Focus sull’obiettivo Empowerment Condizioni per aumentare la qualita’ del risultato
- 28.
- 29.
- 30. Le ho vistefunzionare… Sprint Planning Stime precise Team consolidato #Pratiche #Architettura #Business #Processo #Persone A casa presto Pianificazione rispettata Buona codebase Team Nuovo Troppe incognite 😳 Legacy Codebase Come stimare la ruota della fortuna! 😳 Escludiamo qualche contesto…
- 31. Una settimana dopo… SprintPlanning Stime Sballate del 100% Team consolidato #Pratiche #Architettura #Business #Processo #Persone Oh Shit! Buona codebase Lo stesso team
- 32. Dove sta ladifferenza?
- 33. Dipendenze! Sprint Planning Stime precise Teamconsolidato #Pratiche #Architettura #Business #Processo #Persone A casa presto Pianificazione rispettata Buona codebase Settimana 1 Attivita’ senza dipendenze esterne 🙂 Settimana 2 Necessita’ di aiuto dall’esterno 😳 No dipendenze
- 34. I confini contano Masono difficili da difendere
- 35. Field notes E’ difficile- ma non impossibile - stimare il nostro lavoro Stimare zone ad alta incertezza (Legacy pericoloso o attivita’ altrui) ha margini di errore decisamente piu’ alti. …Ne vale ancora la pena…?
- 36. Le dipendenze contano dipendenze Processo Anchequando vorremmo che fosse solo un problema di Abbiamo problemi a scalare agile… “Forse” avete un problema di architettura
- 37.
- 38. Idealmente… Team A Team B TeamC Team D Progetto 1 Progetto 2 Progetto 4 Progetto 3 Progetto 5 Progetto 6 Progetto 7 Progetto 8
- 39. In pratica, bastanoun po’ di dipendenze… Team A Team B Team C Team D Progetto 1 Progetto 2 Progetto 4 Progetto 3 Progetto 5 Progetto 6 Progetto 7 Progetto 8 1 2 5 6 4 3 Non sono escrescenze, sono straordinari
- 40. Questo non e’accettabile Team A Team B Team C Team D Progetto 1 Progetto 2 Progetto 4 Progetto 3 Progetto 5 Progetto 6 Progetto 7 1 2 5 6 4 3 Probabilmente il progetto più importante Non li pago per stare fermi
- 41. Ma questo e’ancora meno accettabile Team A Team B Team C Team D Progetto 2 Progetto 5 Progetto 7 2 5 Probabilmente il progetto più importante
- 42. Quindi: teniamo fissele date e andiamo di overtime! Team A Team B Team C Team D Progetto 1 Progetto 2 Progetto 4 Progetto 3 Progetto 5 Progetto 6 Progetto 7 Progetto 8 1 2 5 6 4 3
- 43. Dipendenze Il miglior antidotoalla scalabilita’
- 44. Dipendenze Chi le halasciate in giro?
- 45. Il mammut nelguardaroba
- 46.
- 47. Purtroppo Data-driven Design Dipendenze Frenone Effort di Coordinamento Stress Centralizzazione Focussui nomi Ma stiamo passando a Microservizi! Lo stile di modellazione incentrato sul dato porta a costruire sistemi che inevitabilmente generano dipendenze dannose
- 48. Guardando il dato(O i nomi) Articolo Prezzo Disponibilita’ Cliente Carrello Articolo Prezzo Pagamento Ordine Articolo Prezzo Cliente Cliente Ordine Ordine Pagamento Consegna Cliente Reclamo Cliente Ordine Fattura Articolo Alcuni Termini sono usati quasi dappertutto: -> centralizziamo Articolo Business flow Catalogo Acquisto Gestione ordine Delivery Claim
- 49. Spinta verso lacentralizzazione Mi serve il cliente! Mi serve il cliente! Mi serve il cliente!
- 50. Guardando il comportamento Articolo Prezzo Disponibilita’ Cliente Carrello Articolo Prezzo Pagamento Ordine Articolo Prezzo Cliente Cliente Ordine Ordine Pagamento ConsegnaCliente Reclamo Cliente Ordine Fattura Articolo Il dato e’ lo stesso, ma il comportamento e’ diverso -> Possibili modelli diversi, copie o altre opzioni architettura. Articolo Business flow Registra Completa Autorizza Aggiungi Rimuovi Checkout Aggiungi a catalogo Ritira Modifica descrizione Aggiorna Cliente Disponibilita’ Totale Carrello attiva gestisci chiudi attiva gestisci chiudi Cambia stato Sola lettura Catalogo Acquisto Gestione ordine Delivery Claim Payment Magazzino Billing
- 51. Un’altra storia! Event-driven Design Dipendenze“leggere” Piu’ spazio per evoluzione Coordinamento ridotto Meno riunioni Partizionamento Focus su eventi chiave Piano piano… Meno Stakeholders
- 52. I Microservizi (dasoli) non basteranno
- 53. Portare un modellodata- centrico a microservizi Significa annegare nelle dipendenze
- 54. Field Notes Il focussul dato ci porta a centralizzare (molti stakeholder per componente) Focus sul flusso (comportamenti ed eventi) ci porta a vedere altri confini (e pochi stakeholder per componente) Enterprise software Collaborazione fra team e dipartimenti diversi 🙂
- 55.
- 56. Meno riunioni controppa gente
- 57. Pairing! O meglio: facciamoesperimenti riducendo il WiP Limit
- 58. Quando funziona… WiP a1 Rilascio piu’ rapido Collaborazione #Pratiche #Architettura #Business #Processo #Persone Aperitivo! Design sulla frontiera Cliente contento
- 60.
- 61. Quando NON funziona… WiPa 1 Piu’ lenti…? Uno sulla tastiera #Pratiche #Architettura #Business #Processo #Persone Cosa sta succedendo?
- 64.
- 65. Quando funziona… WiP a1 Rilascio piu’ rapido Collaborazione #Pratiche #Architettura #Business #Processo #Persone Aperitivo! Design sulla frontiera Cliente contento OOP ed architettura Domain-Centric Posso splittare classi ed interfacce 🙂 Logica nel dominio (OOP)
- 66. Quando NON funziona… WiPa 1 Piu’ lenti…? Uno sulla tastiera #Pratiche #Architettura #Business #Processo #Persone Tre umarells a guardare Logica nelle stored procedure Strati web come passacarte 😳 Logica nelle Stored Non si e’ accorto di nulla! E il business…? Data-centric Architecture
- 67. Certe architetture invalidano lepratiche Architetture Pratiche
- 68. … ma seleggi bene bene tra le righe…
- 69. Ho appena cominciato E’molto peggio di cosi’
- 70. Logica Nelle stored E’tempo di guardarci meglio
- 71. Riapriamo il processo? Forse,sono emerse nuove prove… https://vimeo.com/253336751
- 73. Usiamo le stored procedures permigliorare le performances Ci vogliono 18 minuti per completare una query! Pensa quanto ci vorrebbe se la logica non fosse vicino al dato!
- 74. Tempo e ripetizioni Cosac’e’ dietro alla freccia?
- 75. Un giorno qualsiasi #Pratiche #Architettura #Business #Processo #Persone Logicanelle stored procedure ??? Nuovo requisito business Chi se ne occupa? Chi se ne occupa?
- 76. Al giorno zero… Ilcuore del nostro sistema, l’infrastruttura che non puo’ cedere Requisito Business Un ipotetico team di persone ugualmente competenti Competenza A chi affidereste l’attivita’? Stored Procedures Posso fare io! Posso fare anche io, e’ uguale… #Pratiche #Architettura #Business #Processo #Persone Solo programming
- 77. Il risultato? Competenza Un po’piu’ competente, perche’ ci ha messo le mani… Un po’ meno competenti, perche’ non conoscono le ultime modifiche… Stored Procedures
- 78. Il giorno successivo: RequisitoBusiness Competenza Stored Procedures A chi affidereste l’attivita’? Abbiamo una asimmetria!
- 79. Il risultato: Nuovo requisito Competenza StoredProcedures L’asimmetria tende naturalmente ad aumentare… E’ meglio se lo fai tu… Non sono allineato con le ultime
- 80. Prima o poi… Requisiticritici Stored Procedures Collo di bottiglia Burnout Competenze asimmetriche Ansia Turnover Requisiti critici Requisiti critici Business in ritardo #Pratiche #Architettura #Business #Processo #Persone Solo programming Il destino dell’universo Posso aiutarti? No, mi rallenti Ciao ragazzi, e’ stato bello…
- 82. Ineluttabilita’ E’ tutto tranneche sfortuna
- 85. Illusione del liberoarbitrio • Le stored procedure non facilitano la collaborazione • Lavoreremo principalmente da soli • Asimmetria sulle competenze • Specializzazione • colli di bottiglia • Tensione e stress • Maggior probabilita’ di turnover • Scadenze business difficilmente raggiungibili Quindi Quindi Quindi Quindi Quindi Quindi Quindi Posso accettare un ‘molto probabilmente’ … ma temo che il risultato non cambi
- 89. C’e’ un filorosso che collega un’architettura data- centric al planning non rispettato, All’apparizione di un ambiente malsano ed al rallentamento dell’evoluzione business
- 90. Non e’ sfortuna E’sulla linea di confine tra correlazione e causalita’ diretta
- 91. Possiamo fare pairing per condividerela conoscenza! Possiamo fare le stored procedure in TDD per essere piu’ sicuri
- 92. Lo Yeti! Non possoescludere che esista, ma nessuno l’ha mai visto…
- 94. Forse l’architettura esagonale ci e’ sfuggitaun po’ di mano…
- 95. Non abbiamo alcunanotizia di aziende che cerchino aiuto per uscire dall’architettura esagonale Forse, Alcune architetture sono piu’ reversibili di altre
- 96. L’illusione dell’ortogonalita’ Potrei seppellirvi diesempi, ma devo arrivare a qualche conclusione
- 97. Che problema hocon il database e le stored procedures?
- 98. Non tutte ledipendenze sono uguali • Non servono cliniche per curarmi
- 99. Il mio problemae’ che ci sono aziende che hanno questo problema da 20 anni E forse e’ troppo tardi per salvare tutti
- 100. Pero’ possiamo evitareche si ripeta Magari osservando quei piccoli “segnali deboli” che sono sotto i nostri occhi.
- 101. Sociotecnico Interrelazione tra aspettisociali e tecnici di un’organizzazione - L’interazione tra fattori sociali e tecnici crea le condizioni per la performance di un’organizzazione, in maniera lineare e non-lineare. - L’ottimizzazione di uno di questi aspetti indipendentemente dall’altro tende a far aumentare l’instabilita’ del sistema con relazioni non previste, ed a farne peggiorare il rendimento Liberamente tradotto da… https://en.wikipedia.org/wiki/Sociotechnical_system #Pratiche #Architettura #Business #Processo #Persone
- 102. La dimensione delproblema Bolle nate come soluzione tecnologica (come partizionare un grafo per aumentare la velocita’) L’algoritmo ha innescato comportamenti nuovi a livello individuale e collettivo Il nuovo paradigma ha reso possibili - e convenienti - strategie mirate per influenzare elezioni, etc.
- 103.
- 104. 1. Non possiamorisolvere problemi da specialisti #Pratiche #Architettura #Business #Processo #Persone
- 105. Non possiamo risolverei problemi da soli #Pratiche #Architettura #Business #Processo #Persone
- 106. Se accettiamo ilprincipio…
- 107.
- 108. “Non preoccupo deitools” E’ un’affermazione che potrebbe fare Sam
- 109. 2. I dettaglifanno la differenza • Architetture, processi e tools Impattano e vincolano individui ed interazioni • Individui ed interazioni sono piu’ importanti, ma non riusciremo a proteggerli se abbassiamo la guardia su architetture processi e strumenti. • Osserviamo ed analizziamo le interazioni, poi adattiamo gli strumenti per permettere interazioni positive
- 110.
- 111. Board fisica • Vincolifisici, • Policy esplicite • Discussione in un luogo ben preciso • Peso sul richiedente Ho una nuova feature per la settimana prossima, dove la posso mettere che non c’e’ posto?
- 112. Board digitale • Sensazioneche ci sia posto… • Un lieve sentore di rosso • Policy quasi mai visibili Metto in selected, poi ci penseranno loro
- 113. Non e’ uguale Stiamodando forma a due interazioni diametralmente opposte
- 114. Architetture, Processi eTools Gli strumenti inducono alcuni gesti invece che altri Piccoli gesti ripetuti ed accumulati ci portano lontano dell’obiettivo. Il caso non e’ nostro alleato: dobbiamo pensarci noi, ma per questo dobbiamo proteggere i confini.
- 115. 3. Proteggiamo iconfini! • Non lasciamo che siano altri, o il fato a decidere come portare a casa il risultato #SkinInTheGame • Costruiamo un luogo dove poter sperimentare e trovare la NOSTRA strada giusta Qui possiamo fare grandi cose BTW: lasciare i team liberi di scegliere il loro stack, sembra essere una strategia vincente
- 116. Minimizziamo le dipendenze AnalizzareI flussi di business con il focus sul comportamento aiuta a trovare i confini naturali per minimizzare le dipendenze. Dipendenze Sbagliate -> Death by Coordination Meetings (“Massimizzare il lavoro non fatto”) #Pratiche #Architettura #Business #Processo #Persone
- 117.
- 119. 4. Provate! Si imparadagli esperimenti ed anche dagli errori! Non fidatevi degli esperti da bar… Contesto Quello che troppo spesso dimentichiamo, ma che fa la differenza. 🙂