Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Powerpoint exploring the locations used in television show Time Clash
Big Ball of Mud: Software Maintenance Nightmares
1. Big Ball of Mud
Software Maintenance Nightmares
Nov 2013
Gonzalo Fernández Rodríguez (gfr@tid.es)
2. BBM: Software Maintenance Nightmares
The importance of maintainability
A large part of a developer’s work consist of spending time in
MAINTENANCE tasks
MANTAINABILITY is the best compromise that architects and
developers might get.
Scalability
MAINTAINABILITY
Performance
Security
1
Gonzalo Fernández Rodríguez (gfr@tid.es)
3. BBM: Software Maintenance Nightmares
The Big Ball of Mud: what is?
Big Ball of Mud (BBM) is a term coined by Briand Food and Joseph Yooder in 1999
that indicates a clear antipattern for architects and developers.
The expresion Big Ball of Mud refers to a software code that lacks a good desing.
Original Paper: http://www.laputan.org/mud
Wikipedia - A big ball of mud is a software system that lacks a perceivable architecture.
Although undesirable from an engineering point of view, such systems are common in
practice due to business pressures and developer turnover. They have therefore been
declared a design anti-pattern.
Wikipedia - BIG BALL OF MUD systems have usually been developed over a long period
of time, with different individuals working on various pieces and parts. Systems developed
by people with no formal architecture or programming training often fall into this pattern.
2
Gonzalo Fernández Rodríguez (gfr@tid.es)
5. BBM: Software Maintenance Nightmares
Causes
q The limited skills of the team
q Frequent changing of requirements
q High rate of turnover among team members
q
q
q
q
Software architecture is seldom discussed.
Unconcerned about architecture: If doesn’t matter if it works….
THROWAWAY CODE is Good!! The real problem comes when it isn't thrown away.
Systems that were once tidy, become overgrown as PIECEMEAL GROWTH gradually
allows elements of the system to sprawl in an uncontrolled fashion.
4
Gonzalo Fernández Rodríguez (gfr@tid.es)
6. BBM: Software Maintenance Nightmares
Alarming Symptoms
RIGIDITY
A simple two day change grows into a multiweek of changes
q Every
change causes a cascade of subsequent changes in dependent
modules.
q Managers fear to allow engineers to fix non-critical problems
5
Gonzalo Fernández Rodríguez (gfr@tid.es)
7. BBM: Software Maintenance Nightmares
Alarming Symptoms
FRAGILE
Make a change here, break the code there
This happen when we enter a change in software and cause it to
misbehave in some places
q
q When a change in a software module breaks other modules (because
of hidden dependencies), we are facing to a bad design and we should
repair it ASAP.
6
Gonzalo Fernández Rodríguez (gfr@tid.es)
8. BBM: Software Maintenance Nightmares
Alarming Symptoms
INMOBILITY
Easier to use than reuse
q If the same code doesn’t work when it’s moved to another project,
it’s because of dependencies.
q Disadvantages:
• We have to import a much larger set of functions
to use this functionality in other project.
• Increases duplication
7
Gonzalo Fernández Rodríguez (gfr@tid.es)
9. BBM: Software Maintenance Nightmares
Alarming Symptoms
VISCOSITY
Easier to work around than to fix
q We
have several ways to add a new
feature or to solve a problem in the
software but ….
• The scalable and elegant ways to do it
are very difficult to apply because we
have a lot of restrictions.
• The only way to do it is with a sort of
trick that is a temporary rather than a
scalable solution.
8
Gonzalo Fernández Rodríguez (gfr@tid.es)
10. BBM: Software Maintenance Nightmares
But…. how can we get the maintainability ?
HIGH COHESION!!!
LOW COUPLING!!!
SEPARATION OF CONCERNS!!!
9
Gonzalo Fernández Rodríguez (gfr@tid.es)
11. BBM: Software Maintenance Nightmares
SOLID PRINCIPLES
An experienced programmer doesn’t use solid as a checklist - he INTERNALISES it
S
• Single Responsibility
O
• Open/Closed Principles
L
• Liskov’s Principle
I
• Interface Segregation
D
• Dependency Inversion
Is a mnemonic acronym introduced by Robert C. Martin in the early 2000s which
stands for five basic principles of object-oriented programming and design.
10
Gonzalo Fernández Rodríguez (gfr@tid.es)
12. BBM: Software Maintenance Nightmares
Single Responsibility
Only one reason for a class to change
GOAL: Keeping the code simple. (Effective way to simplify maintenance)
11
Gonzalo Fernández Rodríguez (gfr@tid.es)
13. BBM: Software Maintenance Nightmares
Open / Closed principle
Software Entities (Classes, Modules, Functions, etc.) should be open for Extension, but
closed for Modification (Bertrand Meyer, the creator of Eiffel Language).
GOAL: Low Coupling.
12
Gonzalo Fernández Rodríguez (gfr@tid.es)
14. BBM: Software Maintenance Nightmares
Open / Closed principle
Open for Extension
q The behavior of the module can be extended. We can make the
module behave in a new and different ways as the requirements of
the application change, or to meet the needs of new applications.
Closed for Modification
q The source code of such a module is inviolate. No one is allowed
to make source code changes to it.
…. How can these two oposing attributes
be resolved?
13
Gonzalo Fernández Rodríguez (gfr@tid.es)
15. BBM: Software Maintenance Nightmares
Open / Closed principle
The key is… ABSTRACTION
q It is possible to create abstractions that are fixed and yet
represent an unbounded group of possible behaviors. The
abstraction could be got by abstract base classes or by
implementing an interface, and the unbounded group of possible
behaviors is represented by all the possible derivative classes or
all the possible classes that implement the inteface.
Template Method Pattern
Strategy Pattern
14
Gonzalo Fernández Rodríguez (gfr@tid.es)
16. BBM: Software Maintenance Nightmares
Liskov’s Principle
The Objects of subtypes should behave like those of supertypes if used via supertype
methods.
Subclasses should be substitutable for their base classes.
The Methods that use the references to base classes (interfaces) must be able to use
objects of derived classes (implementer classes) without knowing it.
TWO CONCEPTS BEHIND: ABSTRACTION and POLYMORPHISM.
15
Gonzalo Fernández Rodríguez (gfr@tid.es)
17. BBM: Software Maintenance Nightmares
Interface Segregation
Components should not be forced to implement members of interfaces (or base
classes) that they don’t plan to use.
Goal: High Cohesion & Low Coupling
Is OK to have methods with a void
implementation?. It depends of……
- If we have a deliberately partial implementation, then is Acceptable
for instance: we will release the implementation in a later version
- If we have a bad designed interface, then is NOT OK
for instance: we have held all the public interfaces in a only “interface” and
forced to several classes to implement this interface even when some of
them won’t be able to implement some of the methods.
16
Gonzalo Fernández Rodríguez (gfr@tid.es)
18. BBM: Software Maintenance Nightmares
Interface Segregation
Poorly designed interface
ISupplier represents the interface for card service
providers.
ThreeVProvider manages payment cards.
TisProvider manages non payments cards, but it
has to implement all the payments methods
defined in ISupplierProvider due to a poorly
designed interface. All theses methos will throw
a NotImplementedException.
Why do we have to implement these
Methods when they are not needed?
(Example extracted from Wallet Server. PDI)
17
Gonzalo Fernández Rodríguez (gfr@tid.es)
19. BBM: Software Maintenance Nightmares
Interface Segregation
Refactoring the previous interface
TisProvider doesn’t comply the relation “is a” IPaymentProvider
IServiceProvider: interface which expose the
operations related with cards in “general”.
IPaymentProvider: interface which expose
the operations that will be implemented by
credit cards.
TisProvider: will implement only general
operations for any card that are exposed on
IServiceProvider.
ThreeVProvider: implement both interfaces,
because ThreeVProvider is a credit card.
(Example extracted from Wallet Server. PDI)
18
Gonzalo Fernández Rodríguez (gfr@tid.es)
20. BBM: Software Maintenance Nightmares
Dependency Inversion
High level modules should not depend upon low level modules. Both should depend
upon abstractions.
Abstractions should not depend upon details. Details should depend upon
abstractions.
Goal: Reduce the interdependence of the modules, writing loosely coupled classes.
19
Gonzalo Fernández Rodríguez (gfr@tid.es)
21. BBM: Software Maintenance Nightmares
Code Smells
How Can I realize out my
code is getting to a
Big Ball of Mud?
20
Gonzalo Fernández Rodríguez (gfr@tid.es)
22. BBM: Software Maintenance Nightmares
Code Smells
Long Method
Long
Parameter
List
Difficult to read,
u nerstand and
troubleshoot
More paremeters
à More complex
Refactor into
smaller methods
Redundant.
(Forces you to
change it if the
type changes)
Duplicate
code
Combinatorial
Explosion
Large Class
Take care of
large conditional
logic blocks.
Lots of code that
does almost the
same.
Difficult to read,
understand, and
troubleshoot
Consider to
refactor
Refactor:
generics,
template,
interpreter...
Refactor into
smaller classes
Dead Code
Speculative
Generality
Oddball Solution
Temporary Field
YAGNI
Don’t Repeat
Yourself
Are they useful?
Type Embedded in
Name
Conditional
Complexity
Delete code that
isn't being used.
Comments
Limit the number
of parameters or
combine them in
an object
Uncommunicative
Names
Inconsistent
Names
Are they selfexplanatory?
Agree a set of
consistent
names
Avoid
innecessary
fields in objects
Suspects of rare
solutions
Use Version
control systems
Don't worry
about tomorrow's
problems until
they come.
Not cherrypicking single
fields when
passing objects
http://www.codinghorror.com/blog/2006/05/code-smells.html
21
Gonzalo Fernández Rodríguez (gfr@tid.es)
23. BBM: Software Maintenance Nightmares
Success Keys
Managers Support
q Managers
believing in the quality of code for the success of products
and prioritizing it over the amount of functionality will help the team to
adopt the use of this priniciples from the begining.
q Managers should let themselves to be advised by the team and to be
able to take decissions to accomplish an improvement period if it is
necessary.
Gonzalo Fernández Rodríguez (gfr@tid.es)
22
24. BBM: Software Maintenance Nightmares
Success Keys
The collaboration of Team Members
q This
practice is not useful if it is not implemented by all the team
members.
q It is necessary to throw away the idea that implement SOLID based
software is more difficult and more expensive than to improvise code
without follow these principles.
q Team members should get used to implement SOLID principles in their
code in a implicit fashion, without thinking in it like when they are able to
use a language they master.
23
Gonzalo Fernández Rodríguez (gfr@tid.es)
25. BBM: Software Maintenance Nightmares
Success Keys
The collective ownership of code
q It
helps to maintain the uniformity of the code, fostering the best
practices in all the involved modules in the project.
q What happen if not all team members implement SOLID principles?
• Some members will spend a lot of time refactoring wrong code.
• The members that not follow this principles will contaminate the
SOLID code generating a Big Ball of Mud again.
24
Gonzalo Fernández Rodríguez (gfr@tid.es)
26. BBM: Software Maintenance Nightmares
Bibliography
1. Programming Microsoft ASP.NET 4, Dino Esposito. Microsoft
Press, March 2011.
2. http://www.laputan.org/mud/
3. http://c2.com/cgi/wiki?CouplingAndCohesion
4. http://www.objectmentor.com/resources/articles/ocp.pdf
5. http://prashantbrall.wordpress.com
6. http://www.codinghorror.com/blog/2006/05/code-smells.html
Code Examples in: https://github.com/lentregu/Solid
25
Gonzalo Fernández Rodríguez (gfr@tid.es)