In the last two decades, refactoring for code and design smells have received considerable focus from both academia and industry. This talk covers large scale refactoring for architectural smells which is gaining considerable attention from the software engineering community in the last few years. The main focus is on real-world case-studies and experiences in performing large scale refactoring for architectural smells from both industrial and open source projects. This talk will provide useful pointers to the participants on how to deal with refactoring for architectural smells in real-world contexts; further, it will also suggest research questions for the software engineering community to explore.
CALL ON ➥8923113531 🔝Call Girls Kakori Lucknow best sexual service Online ☂️
Refactoring for Software Architecture Smells
1. Refactoring for Software Architecture Smells:
Managing Architecture Debt
Ganesh Samarthyam, Corporate Trainer and Author
www.designsmells.com
2. Agenda
• Introduction &
motivation
• What is architectural
refactoring?
• Case studies in
architectural refactoring
• Challenges in architecture
refactoring
4. City metaphor
“Cities grow, cities evolve, cities
have parts that simply die while other
parts flourish; each city has to be
renewed in order to meet the needs of its
populace… Software-intensive systems
are like that. They grow, they evolve,
sometimes they wither away, and
sometimes they flourish…”
Grady Booch in the foreword for “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014.
18. Agenda
• Introduction & motivation
• What is architectural
refactoring?
• Case studies in
architectural refactoring
• Challenges in architecture
refactoring
25. Refactoring “missing layer”
smell
This
smell
arises
when
one
of
the
layers
is
missing
(or
when
no
layers
are
provided
at
all
when
needed)
Layer&A&
Layer&B&
DAL&
Layer&A&
Layer&B&
28. Conway’ law
The structure of a
system mirrors the
structure of the
organisation that
designed it
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”
Melvin E. Conway. "How do committees invent?", Datamation, 14(4):28–31, April 1968
29. Structure of a compiler team
Front-end team
Back-end team
Front-end team
Back-end team
Platform I Platform 2
30. Component interfaces vs.
team boundaries
“Don't publish
interfaces prematurely.
Modify your code
ownership policies to
smooth refactoring.”
– Martin Fowler (Refactoring,
Addison-Wesley, 1999)
A guideline for
code refactoring
A guideline for
architecture refactoring
“Respect code
ownership and retain
team boundaries to
ensure smooth
refactoring.”
31. Code refactoring Architecture refactoring
A module-level or class-level concern
A system level concern that cuts across
modules or sub-systems
Impact of refactoring is within a team Impact of refactoring is often across teams
Typically performed to improve the internal
structure of the code
Performed for various reasons: cost, legal,
security, performance, availability, …
Management buy-in typically not required Management buy-in is typically required
Upfront planning is typically (relatively)
limited
Upfront planning and co-ordination
(sometimes between teams) is often required
Unit tests are important to ensure that
“behaviour is preserved”
Unit tests, integration tests, system tests,
NFR tests, … are required
Risk of breaking the working software is
relatively low
Risk of breaking the working software is
relatively high
Real-world analogy:
“fixing potholes”
Real-world analogy:
“metro construction”
32. Agenda
• Introduction & motivation
• What is architectural
refactoring?
• Case studies in
architectural refactoring
• Challenges in architecture
refactoring
33. Architecture represents the significant
design decisions that shape a
system, where significant is
measured by cost of change.
- Grady Booch (2006)
43. Agenda
• Introduction & motivation
• What is architectural
refactoring?
• Case studies in
architectural refactoring
• Challenges in
architecture refactoring
44. Key challenges in
architecture refactoring
Getting
management
buy-in
Fear of breaking
working software
Lack of tool
support
Merge process
problems
45. How to get management
buy-in?
logger.severe(“details”)
errlog.log(“details”)logger.error(“details”)
System.err.println(“details”)
Since ROI (Return On Investment)
is not clear, how to get
management buy-in for this
architectural refactoring?
Log4j java.util.logging custom log library SOPs
46. Dealing with the fear of
“breaking the working software”
Module 1 Module 2 Module N
How to validate architectural
refactoring changes?
Currently through architecture, design, and code reviews
+ running system, integration, and unit tests =>
Can still break the working software!
47. Lack of tool support
Unlike code refactoring, most
architectural refactoring is manual
due to lack of tool support!
49. Lack of tool support
Lack of automated support for
architectural refactoring
Inadequate support for
detecting smells
Limited support for
quantifying architectural debt
…
50. Merge process problems
Challenge I: How to handle merges from
distributed teams?
Challenge II: How to merge changes from
long-running branches?
51. Illustration: How to co-ordinate
changes in distributed teams?
Module 1
Country 1
Module 2
Country 2
Module N
Country N
How do co-ordinate refactoring when
code ownership is distributed with
teams across the globe? (more
pronounced in refactoring situations)
52. Illustration: How to deal with
changes in long-running branches?
Module 1
Module 2
Module N
6 months
53. Key take-aways
Architecture smells and violations contribute to technical debt (known
as architecture debt)
Architecture refactoring plays a key role in enhancing agility and
enables business success
Code refactoring and architecture refactoring are altogether different
ballgames
Architecture smells can be viewed in terms of Architectural Decisions
(ADs)
Refactoring for replaying architecture debt is an emerging topic