Big Ball of Mud: Software Maintenance Nightmares
Upcoming SlideShare
Loading in...5
×
 

Big Ball of Mud: Software Maintenance Nightmares

on

  • 7,590 views

Do you already know what big ball of mud means? ...

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.

Statistics

Views

Total Views
7,590
Views on SlideShare
7,590
Embed Views
0

Actions

Likes
2
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Big Ball of Mud: Software Maintenance Nightmares Big Ball of Mud: Software Maintenance Nightmares Presentation Transcript

  • Big Ball of Mud Software Maintenance Nightmares Nov 2013 Gonzalo Fernández Rodríguez (gfr@tid.es)
  • 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)
  • 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)
  • BBM: Software Maintenance Nightmares Big Ball of Mud seems like…. Haphazardly structured Spaguetti code Sprawling Duplicate data Sloppy Duplicate behaviour Duct-tape Unregulated grotwh Bailing wire Repeated expedient repair 3 Gonzalo Fernández Rodríguez (gfr@tid.es)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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
  • 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)
  • 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)
  • 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)