big ball of mud: software maintenance nightmares
Post on 06-May-2015
9.452 Views
Preview:
DESCRIPTION
TRANSCRIPT
Big Ball of Mud Software Maintenance Nightmares
Nov 2013
Gonzalo Fernández Rodríguez (gfr@tid.es)
BBM: Software Maintenance Nightmares
1
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
Performance
Security
MAINTAINABILITY
Gonzalo Fernández Rodríguez (gfr@tid.es)
2
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. 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.
Original Paper: http://www.laputan.org/mud
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
3
Big Ball of Mud seems like….
Haphazardly structured
Sprawling
Sloppy
Duct-tape
Bailing wire
Spaguetti code
Duplicate data
Duplicate behaviour
Unregulated grotwh
Repeated expedient repair
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
4
q The limited skills of the team q Frequent changing of requirements q High rate of turnover among team members
q Software architecture is seldom discussed. q Unconcerned about architecture: If doesn’t matter if it works…. q THROWAWAY CODE is Good!! The real problem comes when it isn't thrown away. q Systems that were once tidy, become overgrown as PIECEMEAL GROWTH gradually
allows elements of the system to sprawl in an uncontrolled fashion.
BBM: Software Maintenance Nightmares Causes
Gonzalo Fernández Rodríguez (gfr@tid.es)
5
Alarming Symptoms
q Every change causes a cascade of subsequent changes in dependent modules. q Managers fear to allow engineers to fix non-critical problems
RIGIDITY A simple two day change grows into a multiweek of changes
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
6
FRAGILE Make a change here, break the code there
q This happen when we enter a change in software and cause it to misbehave in some places 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.
Alarming Symptoms
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
7
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
Alarming Symptoms
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
8
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.
Alarming Symptoms
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
9
But…. how can we get the maintainability ?
HIGH COHESION!!!
LOW COUPLING!!!
SEPARATION OF CONCERNS!!!
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
10
SOLID PRINCIPLES
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.
S • Single Responsibility
O • Open/Closed Principles
L • Liskov’s Principle
I • Interface Segregation
D • Dependency Inversion
BBM: Software Maintenance Nightmares
An experienced programmer doesn’t use solid as a checklist - he INTERNALISES it
Gonzalo Fernández Rodríguez (gfr@tid.es)
11
Single Responsibility
Only one reason for a class to change GOAL: Keeping the code simple. (Effective way to simplify maintenance)
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
12
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
13
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?
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
14
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.
Strategy Pattern
Template Method Pattern
Open / Closed principle
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
15
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
16
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
17
Interface Segregation
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.
Poorly designed interface
(Example extracted from Wallet Server. PDI)
Why do we have to implement these Methods when they are not needed?
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
18
Interface Segregation
Refactoring the previous interface
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)
TisProvider doesn’t comply the relation “is a” IPaymentProvider
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
19
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
20
Code Smells
BBM: Software Maintenance Nightmares
How Can I realize out my code is getting to a
Big Ball of Mud?
Gonzalo Fernández Rodríguez (gfr@tid.es)
21
Code Smells
BBM: Software Maintenance Nightmares
Comments
Are they useful?
Long Method
Difficult to read, u nerstand and troubleshoot
Refactor into smaller methods
Long Parameter
List
More paremeters à More complex
Limit the number of parameters or combine them in
an object
Duplicate code
Don’t Repeat Yourself
Conditional Complexity
Take care of large conditional
logic blocks.
Consider to refactor
Combinatorial Explosion
Lots of code that does almost the
same.
Refactor: generics, template,
interpreter...
Large Class
Difficult to read, understand, and
troubleshoot
Refactor into smaller classes
Type Embedded in Name
Redundant. (Forces you to change it if the type changes)
Uncommunicative Names
Are they self-explanatory?
Inconsistent Names
Agree a set of consistent
names
Dead Code
Delete code that isn't being used.
Use Version control systems
Speculative Generality
YAGNI
Don't worry about tomorrow's
problems until they come.
Oddball Solution
Suspects of rare solutions
Temporary Field
Avoid innecessary
fields in objects
Not cherry-picking single fields when
passing objects
http://www.codinghorror.com/blog/2006/05/code-smells.html
Gonzalo Fernández Rodríguez (gfr@tid.es)
22
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
23
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
24
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.
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
25
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
BBM: Software Maintenance Nightmares
Gonzalo Fernández Rodríguez (gfr@tid.es)
top related