Abstract
- Perché fare Refactoring?
Riconoscere le situazioni ed i problemi che si risolvono con il Refactoring
- Quali i prerequisiti per fare Refactoring?
Dotarsi del necessario per applicare il Refactoring in continuo miglioramento
- Come comprendere e reagire ai feedback del codice?
Esempio "Live" di Refactoring del 2° tipo applicato al codice dell'interazione utente
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)Stefan ROOCK
Klassisch: Low Trust, Agil: High Trust. Das spiegelt sich in den heute üblichen Verträgen wieder. Sie sind von Misstrauen geprägt. Das führt zu Abgrenzung, Zurückhalten von Informationen und schlechtem Risikomanagement. Es gibt Vertrauen in Intentionen und in Fähigkeiten. Was Verträgen zugrunde liegt, ist Angst. Angst, dass die der Vertragspartner falsche Intentionen verfolgt oder die notwendigen Fähigkeiten nicht hat. Auch bei vertrauensbasierten Verträgen müssen wir den Ängsten Rechnung tragen. Allerdings begegnen wir diesen Ängsten mit Kooperation statt Abgrenzung. Durch Kooperation und häufige Face-2-Face-Kontakte wächst Vertrauen. Vertrauen selbst reduziert soziale Komplexität und erlaubt damit agilen Verfahren überhaupt erst, sich richtig zu entfalten. Über Feedback-Schleifen kann sichergestellt werden, dass Vertrauen nicht missbraucht wird.
Draft your next training course with ideas from Training from the Back of the...Luca Minudel
A personal approach on applying the 4Cs techniques for the book 'Training from the Back of the Room!' starting from the end like the legend of the Phoenix.
Von der Governance-getriebenen Architektur der IT-Entscheider und Architecture Boards kamen wir zur emergenten, teambestimmten Architektur, und von dort über Strategien wie MicroServices zu Organisationsformen, die wir frei anhand unserer Wunscharchitektur definieren. Im Gegensatz zu den sich immer weiter beschleunigenden Architektur- und Technologietrends bewegen sich Team- und Abteilungsstrukturen mit ihrer eigenen Geschwindigkeit - und manchmal auch gar nicht. Ein Bericht aus der Praxis, vom Planen, Scheitern, Lernen und demütiger Architektur.
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)Stefan ROOCK
Klassisch: Low Trust, Agil: High Trust. Das spiegelt sich in den heute üblichen Verträgen wieder. Sie sind von Misstrauen geprägt. Das führt zu Abgrenzung, Zurückhalten von Informationen und schlechtem Risikomanagement. Es gibt Vertrauen in Intentionen und in Fähigkeiten. Was Verträgen zugrunde liegt, ist Angst. Angst, dass die der Vertragspartner falsche Intentionen verfolgt oder die notwendigen Fähigkeiten nicht hat. Auch bei vertrauensbasierten Verträgen müssen wir den Ängsten Rechnung tragen. Allerdings begegnen wir diesen Ängsten mit Kooperation statt Abgrenzung. Durch Kooperation und häufige Face-2-Face-Kontakte wächst Vertrauen. Vertrauen selbst reduziert soziale Komplexität und erlaubt damit agilen Verfahren überhaupt erst, sich richtig zu entfalten. Über Feedback-Schleifen kann sichergestellt werden, dass Vertrauen nicht missbraucht wird.
Draft your next training course with ideas from Training from the Back of the...Luca Minudel
A personal approach on applying the 4Cs techniques for the book 'Training from the Back of the Room!' starting from the end like the legend of the Phoenix.
Von der Governance-getriebenen Architektur der IT-Entscheider und Architecture Boards kamen wir zur emergenten, teambestimmten Architektur, und von dort über Strategien wie MicroServices zu Organisationsformen, die wir frei anhand unserer Wunscharchitektur definieren. Im Gegensatz zu den sich immer weiter beschleunigenden Architektur- und Technologietrends bewegen sich Team- und Abteilungsstrukturen mit ihrer eigenen Geschwindigkeit - und manchmal auch gar nicht. Ein Bericht aus der Praxis, vom Planen, Scheitern, Lernen und demütiger Architektur.
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
New Lean-Agile Coach Self-Assessment - detailed descriptions v3Luca Minudel
Detailed descriptions for the Lean-Agile Coach Self-Assessment
Includes references to resources useful to improve in each competency area (download the deck and look at the notes)
From Continuous Integration to Continuous Delivery and DevOpsLuca Minudel
An overview of Continuous Delivery from a business and a technical point of view.
Includes an overview of:
- business value proposition of CD
- prerequisites and tips for CD implementation
- CD implementation was stories and strategies
- CD technical practices
This is a presentation on "Lean & Agile Organizational Leadership: History, Theory, Models, & Popular Ideas," which are emerging models for managing high-risk, time-sensitive R&D-oriented new product development (NPD) projects with demanding customers and fast-changing market conditions (at the enterprise, portfolio, and program levels). It establishes the context, provide a definition, and describe the value-system for lean and agile methods, principles, and core ideas. It provides a brief history and comparative analysis of agile methods (i.e., Crystal Methods, Scrum, Dynamic Systems Development Method, Feature Driven Development, and Extreme Programming), project management models (i.e., Radical, Adaptive, Extreme, Agile, and Simplified Agile), and portfolio frameworks (i.e., Enterprise Scrum, Scaled Agile Framework, Large Scale Scrum, Disciplined Agile Delivery, and Recipes for Agile Governance). Then it provides multiple histories of the fields of organizational leadership, administration, and management over the last 100 years. It then introduces, delves into, describes, and provides a brief survey and comparative analysis of emerging theories, models, and methods of lean and agile leadership (i.e., Agile, Employee, Radical, Lean, and Leadership 3.0). Finally, it closes with an expose of the top organizational change paradigms most closely aligned with the field of lean and agile development, project management, and portfolio management methodologies (along with a unique summary of the major tenets, principles, and practices of lean & agile organizational leadership). This briefing has been warmly received by multiple U.S. government agencies, contractors, and university audiences throughout Baltimore-Washington, DC.
Von flachen Hierarchien zur Networked Company, von losen Netzwerken zur Holacracy, von Managern zur Bossless Organization: IT-Unternehmen diskutieren zurzeit viele Begriffe aus dem NewWork-Umfeld. Warum springt gerade unsere Branche auf diese Konzepte an? Dreht sich alles um den Arbeitsmarkt und die Generation Y, oder reagieren wir auf steigende Komplexität und Dynamik? Welche Folgen hat das auf das Unternehmen und unsere Arbeit? Ein Bericht aus Theorie und Praxis, von Hypes, offensichtlichen und nicht offensichtlichen Fehlern.
Organize for Complexity, part I+II - Special Edition PaperNiels Pflaeging
The future of the Organization.
Special Edition of the BetaCodex Network´s white papers on Organizing for Complexity - two papers in one! Illustrations by Pia Steinmann
Aula 2 para a turma de 2012 do curso Técnico em Informática do Senac Bauru.
- Planejamento de Projetos Web
- Conceitos e Metodologia de Planejamento
- A importância do Briefing
- Modelo de Briefing
- Projetando passo a passo – parte 1
Adaptive rendering e ASP.NET 2.0 CSS Friendly Control Adapters 1.0DotNetMarche
In questa sessione verrà introdotta una nuova caratteristica di ASP.NET 2.0, l'Adaptive Rendering, che permette di modificare il rendering di un controllo per adattarlo alle nostre esigenze. Vedremo poi all'opera i CSS Friendly Control Adapters, che sfruttano l'Adaptive Rendering per modificare il codice HTML generato dai principali controlli ASP.NET in modo da fornire una versione client-side molto più adatta a gestire contenuti accessibili.
This presentation gives a relavent detail about the JAVA Debugging tools and how how is it useful in debugging various JAVA based applications an JAVA OS.
Indian Dental Academy: will be one of the most relevant and exciting training center with best faculty and flexible training programs for dental professionals who wish to advance in their dental practice,Offers certified courses in Dental implants,Orthodontics,Endodontics,Cosmetic Dentistry, Prosthetic Dentistry, Periodontics and General Dentistry.
New Lean-Agile Coach Self-Assessment - detailed descriptions v3Luca Minudel
Detailed descriptions for the Lean-Agile Coach Self-Assessment
Includes references to resources useful to improve in each competency area (download the deck and look at the notes)
From Continuous Integration to Continuous Delivery and DevOpsLuca Minudel
An overview of Continuous Delivery from a business and a technical point of view.
Includes an overview of:
- business value proposition of CD
- prerequisites and tips for CD implementation
- CD implementation was stories and strategies
- CD technical practices
This is a presentation on "Lean & Agile Organizational Leadership: History, Theory, Models, & Popular Ideas," which are emerging models for managing high-risk, time-sensitive R&D-oriented new product development (NPD) projects with demanding customers and fast-changing market conditions (at the enterprise, portfolio, and program levels). It establishes the context, provide a definition, and describe the value-system for lean and agile methods, principles, and core ideas. It provides a brief history and comparative analysis of agile methods (i.e., Crystal Methods, Scrum, Dynamic Systems Development Method, Feature Driven Development, and Extreme Programming), project management models (i.e., Radical, Adaptive, Extreme, Agile, and Simplified Agile), and portfolio frameworks (i.e., Enterprise Scrum, Scaled Agile Framework, Large Scale Scrum, Disciplined Agile Delivery, and Recipes for Agile Governance). Then it provides multiple histories of the fields of organizational leadership, administration, and management over the last 100 years. It then introduces, delves into, describes, and provides a brief survey and comparative analysis of emerging theories, models, and methods of lean and agile leadership (i.e., Agile, Employee, Radical, Lean, and Leadership 3.0). Finally, it closes with an expose of the top organizational change paradigms most closely aligned with the field of lean and agile development, project management, and portfolio management methodologies (along with a unique summary of the major tenets, principles, and practices of lean & agile organizational leadership). This briefing has been warmly received by multiple U.S. government agencies, contractors, and university audiences throughout Baltimore-Washington, DC.
Von flachen Hierarchien zur Networked Company, von losen Netzwerken zur Holacracy, von Managern zur Bossless Organization: IT-Unternehmen diskutieren zurzeit viele Begriffe aus dem NewWork-Umfeld. Warum springt gerade unsere Branche auf diese Konzepte an? Dreht sich alles um den Arbeitsmarkt und die Generation Y, oder reagieren wir auf steigende Komplexität und Dynamik? Welche Folgen hat das auf das Unternehmen und unsere Arbeit? Ein Bericht aus Theorie und Praxis, von Hypes, offensichtlichen und nicht offensichtlichen Fehlern.
Organize for Complexity, part I+II - Special Edition PaperNiels Pflaeging
The future of the Organization.
Special Edition of the BetaCodex Network´s white papers on Organizing for Complexity - two papers in one! Illustrations by Pia Steinmann
Aula 2 para a turma de 2012 do curso Técnico em Informática do Senac Bauru.
- Planejamento de Projetos Web
- Conceitos e Metodologia de Planejamento
- A importância do Briefing
- Modelo de Briefing
- Projetando passo a passo – parte 1
Adaptive rendering e ASP.NET 2.0 CSS Friendly Control Adapters 1.0DotNetMarche
In questa sessione verrà introdotta una nuova caratteristica di ASP.NET 2.0, l'Adaptive Rendering, che permette di modificare il rendering di un controllo per adattarlo alle nostre esigenze. Vedremo poi all'opera i CSS Friendly Control Adapters, che sfruttano l'Adaptive Rendering per modificare il codice HTML generato dai principali controlli ASP.NET in modo da fornire una versione client-side molto più adatta a gestire contenuti accessibili.
This presentation gives a relavent detail about the JAVA Debugging tools and how how is it useful in debugging various JAVA based applications an JAVA OS.
Indian Dental Academy: will be one of the most relevant and exciting training center with best faculty and flexible training programs for dental professionals who wish to advance in their dental practice,Offers certified courses in Dental implants,Orthodontics,Endodontics,Cosmetic Dentistry, Prosthetic Dentistry, Periodontics and General Dentistry.
Actions: Develop a design tool to help incorporate linkages between focal areas
at program level, to break down silos at project level to hard wire linkages into project design (see STAP tool)
Improve coordination of GEF projects across focal areas within a geographic region where potential synergies and value added are high. Capture these synergies in policy reform and governance arrangements to solidify links, improve outcomes and enhance sustainability.
It takes two to tango - why tech and business succeed or fail together v4.1 b...Luca Minudel
In this session, we will discuss how to achieve real technical excellence that matters to the Business, how to build trust between Business and Tech, and how Business can react quickly and beat the competition with help from Tech. After many years in professional software development, we experienced the impact of Business’ decisions on Tech, the importance of technical excellence for the Business, and the role of Software Craftsmanship/Craftswomenship in achieving technical excellence.
We learned that Tech is an enabler for the Business, that Business is a key stakeholder, that mastery in practices such as Software Craftsmanship/Craftswomenship leads to technical excellence that really matters. Then, in an unexpected turn of events, we learned these assumptions were flawed, it was much more than that.
Project management in the age of accelerating change - IT/Tech specificLuca Minudel
- What is Agile and why is becoming increasingly popular?
- For what types of endeavours Agile is best suited?
- What additional tools does Agile add to a PM toolbox?
- How does a traditional project differ from an Agile digital product delivery?
- What is the role of the PM in an Agile delivery?
This session gives a short introduction of Agile for traditional Project Managers and describes the structure, the steps and the activities of an Agile project from Inception to delivery.
Project management in the age of accelerating change - general non IT specificLuca Minudel
- What is Agile and why is becoming increasingly popular?
- For what types of endeavours Agile is best suited?
- What additional tools does Agile add to a PM tool box?
- How does a traditional project differ from an Agile digital product delivery?
- What is the role of the PM in an Agile delivery?
This session gives a short introduction of Agile for traditional Project Managers, and describes the structure, the steps and the activities of an Agile project from Inception to delivery.
New Self-assessment radar for Scrum Masters.
Use this as a permanent link to always get access to the latest version: http://www.smharter.com/blog/scrum-master-skills-self-assessment-radar/
What is Agility?
What are the characteristics that contribute to Agility?
What are the team/org structures that support Agility?
What are the challenges that require Agility?
Agility: The scientific definition of how to be(come) AgileLuca Minudel
Many talks about doing Agile versus being Agile. The session presents a scientific definition of Agility, how to move from doing Agile to being Agile. Characteristics of Agility that can be enhanced, inhibitors the can be reduced and removed and contexts where Agility is an advantage are all presented in this session. All this enables you, a team and an organization to decide when and to know how to go from doing Agile to being Agile.
References
The content of this session is based on studies and experiments promoted by U.S. DoD and NATO research and presented in these books:
The Agility Advantage: A Survival Guide For Complex Enterprises and Endeavors; David Alberts; 2011.
Power to the Edge: Command...Control...in the Information Age; David Alberts and Richard Hayes; 2003.
Lightning talk: Active Agility, the magic ingredient of Lean and AgileLuca Minudel
Many talks about doing Agile versus being Agile. The session presents a scientific definition of Agility, how to move from doing Agile to being Agile. Characteristics of Agility that can be enhanced, inhibitors the can be reduced and removed and contexts where Agility is an advantage are all presented in this session. All this enables you, a team and an organization to decide when and to know how to go from doing Agile to being Agile.
References
The content of this session is based on studies and experiments promoted by U.S. DoD and NATO research and presented in these books:
The Agility Advantage: A Survival Guide For Complex Enterprises and Endeavors; David Alberts; 2011.
Power to the Edge: Command...Control...in the Information Age; David Alberts and Richard Hayes; 2003.
Software development in Formula One: challenges, complexity and struggle for ...Luca Minudel
This is an experience report based on more than 3 years (2006-2009) of software development in F1 with Scrum, Lean and XP, developing evolving and maintaining software to support the F1 racing team from the vehicle conception and throughout every test and race.
In these 3 years I promoted and supported the advancement of the existing Agile practices in my team and then for all the software development teams of the F1 racing team.
How was this experience? It was dense and intense. What made it valuable? It was:
- the unique context characterized by very high levels of competition, speed and unpredictable rapid changes.
- the challenge of doing computer programming in an F1 team: the team and I had to learn and invent how to work with a code-base that is very large and long lived, a product that is uncommonly complex, in an organization that has high levels of interdependency and with technologies and competitors that are fast moving targets. We found ourselves far behind the boundaries where centralized top-down approaches could possibly work and where a book, a school degree or an expert could possibly reveal the right answer.
We had to do software development in extreme conditions and push ourselves to the limit as F1 drivers that really push and find the limits with the aim of outperforming competitors.
Have we survived this chaos? How did we survive? Which team and coding practices emerged? This experience report will look at the answers to all those questions and will try to answer questions from participants.
Refactoring legacy code driven by tests - ENGLuca Minudel
re you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?
During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.
We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.
Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)
Refactoring legacy code driven by tests - ITALuca Minudel
Are you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?
During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.
We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.
Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)
Continuous Delivery (CD) is often thought to be within the purview of tech practitioners – developers, testers, operations, delivery managers, etc. However, the industry is fast realizing that CD is actually more of a business decision. CD can be the game changer to help the organization stay a step ahead by delivering value to the customer reliably and frequently. CD isn’t a geeky fad, but a huge business enabler vouched for by Facebook, LinkedIn, Flickr and the like. In this session I’ll Introduce the principles, the practices, the tools, and the business value proposition of continuous delivery both from a business point of view and from a technical point of view.
1 - quando e quanto
2 - gli strumenti per (non i tool)
3 - esempio “live” di refactoring
Il punto da cui partiamo è questa defininizione.
No intro
tutte le informazioni utili per applicare il Refactoring anche in un ambiente Ostile (molte di queste nuove metodologie si applicano meglio in team)
- non si fa xKè la SH non compra i Tool (ora c’è Together CE) o non fa formazione e quindi il Disegno lo sa leggere solo chi l’ha scritto e non a chi serve
-Nel disegno classico lo fa il progettista
-Nel Refactoring lo fa lo Sviluppatore
Analisi:
- Cosa il sistema deve fare (il comportamento esterno)- Usa il linguaggio dell’Utente (Non qui si parla di .NET/Java, Remoting/Web Services, SqlServer/Oracle)
Disegno:- Come il sistema lo deve fare- Usa il linguaggio dello sviluppatore
Quanto?
- > = _quando_ serve!
- quando fermarsi?
-Quando abbiamo chiarito le complessità che avvertivamo del
sistema e le abbiamo semplificate
- Quando modificando il codice non avvertiamo “attriti” (si xKè il Refactoring si fa in maniera adattiva e non predittiva)
- Design up-front è + facile da fare: svolge ruolo di indirizzo- il Design up-front può ridursi ed il ruolo di indirizzo lo fanno le sole schede CRC
- vedendo e provando il programma l'utente capisce meglio ciò di cui aveva bisogno (nuovi requisiti e req cambiati) e anche noi capiamo cose a cui non avevamo pensato
col tempo arrivano nuovi requisiti: mi serve questo… mi serve quello…
- vi è mai capitato di arrivare alla fine di un progetto, di aver imparato molte cose e dire… “adesso lo progetterei in modo diverso”?
è più difficile cancellare codice che scriverne Es. riunione col capo (poco tempo) o con utenti (poca concentrazione) o doc tecnico per colleghi da convincere/articolo-Tip
il disegno migliora invece di degradare!
Rigido - Fragile - ImmobileFlessibileLocalmente in parti isolate= 1+ metodi, 1+classi strettamente correlate (stesso namespace/assembly) => When the extent of that cascade of change (in moduli correlati) cannot be predicted by the designers or maintainers the impact of the change cannot be estimated.
Robusto- bug in cascata: fisso 1 e compare un altro- + applicazioni sulla stessa Virtual Directory- Portale<= applicazione (javascript/frame)Riutilizzabile- funz. Collegata a… autenticazione, log errori, condivisione connessione,…- user control con dentro SQL
Un altro modo di dire Basso Accoppiamento Altra Coesione
attributi interi ed esterni (predetti da misura di quelli interni con metodo statistico/modello matematico)
Individuare i programmi che hanno i problemi appena descritti
Individuare quali hanno esigenze di evoluzione/complessità (mutabilità dei requisiti, nuovi requisiti, tailoring per nuovi clienti, molti bug da correggere)
Intervenire
- Refactoring del 1° tipo (meccanico) sui punti che + ne hanno bisogno
- Refactoring del 2° tipo (manuale) quando il cliente chiede modifiche
Info da usare per far avvicinare i colleghi al R e altre info utili per migliorarsi.
-Come comprendere e reagire ai feedback del codice?
metriche
predittive e di controllo
attributi interi ed esterni (predetti da misura di quelli interni con metodo statistico/modello matematico)
metriche statiche (complessità, comprensibilità, manutenibilità)
metriche dinamiche (efficienza, affidabilità)
Vil a linea di comando:- La metrica che voglio raccogliere- Il titolo- Il file htmpl di output
Lo faccio per ogni metrica
Con il Copy unisco tutti i risultati in un unico html
e visualizzo il risultato
Ho avuto problemi con la lunghezza del comando (command + arguments) da VS.NET External Tools… e ho risolto specificando la directory iniziale e quindi potendola togliere dal Command
@echo on / pause
==> www.1bot.com
trasformazioni in piccoli passi semplici
applicati con sistematicità e disciplina
velocità->rischio di introdurre bug sottili
Nota: questi sono i sintomi (queste metriche misurano attributi internni per predire quelli esterni)
la malattia: cattivo disegno = rigidità, fragilità, immobilità
la cura: fare refactoring (->basso accoppiamento alta coesione) verificando se "ha senso" (OO, Pattern, LSP, OCP, DIP)
modello iso osi, esempio chat e livelli applicazione e sessione
-> programmazione OO + pratica -> feedback dal codice
- da una parte i dp possono “materializzarsi” spontaneamente nel codice facendo refactoring
- dall’altra funzionano da ispirazione durante il refactoring
- inoltre nuovi dp possono nascere proprio facendo refactoring
- Introdurre il refactoring come attività continua durante la scrittura di codice
- approfondire i principi della programmazione OO e design e applicare il refactoring del 2° tipo
- fare pratica di TDD e applicare TDD+Refactoring di 1° tipo
Shotgun surgery
Codice duplicato
Cambiamenti divergenti
Commenti
Generalizzazione speculativa