About me
Uberto Barbini
Software artisan
Agile enthusiast.
@ramtop
+10 years experience in project leading.
Currently Teamleader and TechArchitect
for Vodafone editorial and backend
products.
Wednesday, April 18, 12
Slide 2
Slide 2 text
The State of the
Quality
Making life hard for bugs
DEVELOPERS - April 2012 - Poznan
Wednesday, April 18, 12
Slide 3
Slide 3 text
Wednesday, April 18, 12
Slide 4
Slide 4 text
greenfield n : land (as a potential
industrial site) not previously developed
or polluted.
Wednesday, April 18, 12
Slide 5
Slide 5 text
greenfield n : land (as a potential
industrial site) not previously developed
or polluted.
If all your projects are like this
you may be not interested in this talk
Wednesday, April 18, 12
Slide 6
Slide 6 text
My project are more like this...
Wednesday, April 18, 12
Slide 7
Slide 7 text
My project are more like this...
Wednesday, April 18, 12
Slide 8
Slide 8 text
My project are more like this...
brownfield n : abandoned, idled or
underused industrial and commercial
facility where expansion or
redevelopment is complicated by real or
perceived environmental
contamination.
Wednesday, April 18, 12
Slide 9
Slide 9 text
Whom will they call out?
Wednesday, April 18, 12
Slide 10
Slide 10 text
Whom will they call out?
Wednesday, April 18, 12
Slide 11
Slide 11 text
Whom will they call out?
Maybe...
Wednesday, April 18, 12
Slide 12
Slide 12 text
Whom will they call out?
Maybe...
Wednesday, April 18, 12
Slide 13
Slide 13 text
Whom will they call out?
Maybe...
More likely...
Wednesday, April 18, 12
Slide 14
Slide 14 text
Whom will they call out?
Maybe...
More likely...
That will be us!
Wednesday, April 18, 12
Slide 15
Slide 15 text
What can we do?
Wednesday, April 18, 12
Slide 16
Slide 16 text
A tale about Quality
Wednesday, April 18, 12
Slide 17
Slide 17 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Wednesday, April 18, 12
Slide 18
Slide 18 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Wednesday, April 18, 12
Slide 19
Slide 19 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Wednesday, April 18, 12
Slide 20
Slide 20 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Why we didn’t start in time?
Wednesday, April 18, 12
Slide 21
Slide 21 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Why we didn’t start in time?
Because there were many bugs still open
Wednesday, April 18, 12
Slide 22
Slide 22 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Why we didn’t start in time?
Because there were many bugs still open
Why were there bugs still open?
Wednesday, April 18, 12
Slide 23
Slide 23 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Why we didn’t start in time?
Because there were many bugs still open
Why were there bugs still open?
Because we take more time to close bugs
Wednesday, April 18, 12
Slide 24
Slide 24 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Why we didn’t start in time?
Because there were many bugs still open
Why were there bugs still open?
Because we take more time to close bugs
Why are we taking more time to close bugs?
Wednesday, April 18, 12
Slide 25
Slide 25 text
A tale about Quality
Once upon a time everything was easy, now everything
takes ages to complete.
Why we cannot honor estimates anymore?
Because we don’t start in time
Why we didn’t start in time?
Because there were many bugs still open
Why were there bugs still open?
Because we take more time to close bugs
Why are we taking more time to close bugs?
Because...
Wednesday, April 18, 12
Slide 26
Slide 26 text
Bugs had became harder to find!
Wednesday, April 18, 12
Slide 27
Slide 27 text
Bugs had became harder to find!
What if we change the background?
Wednesday, April 18, 12
Slide 28
Slide 28 text
Bugs had became harder to find!
What if we change the background?
Wednesday, April 18, 12
Slide 29
Slide 29 text
Bugs had became harder to find!
What if we change the background?
Can you spot the insect now?
Wednesday, April 18, 12
Slide 30
Slide 30 text
We need to make bugs
more evident!
There are two ways to write
code: write code so simple there
are obviously no bugs in it,
or write code so complex that
there are no obvious bugs in it.
C.A.R. Hoare
Wednesday, April 18, 12
Slide 31
Slide 31 text
Reshape your code!
Wednesday, April 18, 12
Slide 32
Slide 32 text
Reshape your code!
What do we want to
get rid of?
Wednesday, April 18, 12
TMandelbrot = class
....
public
Par: TMandParameters;
Colors : TColorize;
constructor Create(ABitmap: TBitmap; const ProdVers: string);
destructor Destroy; override;
procedure Prepare( AMandelSet: TMandelSet; AColors: TColorize );
procedure Render( UpdatingInfo: boolean = true );
function AlgMndFlt( CR, CI :Extended ): extended;
function GetPercentDrawn: Extended;
procedure UpdateInfo;
procedure Redraw;
procedure DoProgress( Progress: Extended = -1 );
procedure DoFilter( AFilter: TFilterKind; KeepProgr: Boolean = True);
procedure RestoreFilter;
procedure StoreFilter;
procedure MandelSetDefault( var AMandelset: TMandelSet );
property Info: TMandelInfo read FInfo;
published
property ProgressTimer: Cardinal read FTimer write SetTimer;
property OnProgress: TProgrEvent read FOnProgress write SetOnProgress;
end;
http://fractalforge.cvs.sourceforge.net/viewvc/fractalforge/fractalforge/Mandelbrot.pas?view=markup
Fractal Forge has been
my first serious tentative
with Object Oriented
programming.
It’s written in Object
Pascal (Borland Delphi).
This class is 1751 lines
of code.
Wednesday, April 18, 12
Slide 39
Slide 39 text
TMandelbrot = class
....
public
Par: TMandParameters;
Colors : TColorize;
constructor Create(ABitmap: TBitmap; const ProdVers: string);
destructor Destroy; override;
procedure Prepare( AMandelSet: TMandelSet; AColors: TColorize );
procedure Render( UpdatingInfo: boolean = true );
function AlgMndFlt( CR, CI :Extended ): extended;
function GetPercentDrawn: Extended;
procedure UpdateInfo;
procedure Redraw;
procedure DoProgress( Progress: Extended = -1 );
procedure DoFilter( AFilter: TFilterKind; KeepProgr: Boolean = True);
procedure RestoreFilter;
procedure StoreFilter;
procedure MandelSetDefault( var AMandelset: TMandelSet );
property Info: TMandelInfo read FInfo;
published
property ProgressTimer: Cardinal read FTimer write SetTimer;
property OnProgress: TProgrEvent read FOnProgress write SetOnProgress;
end;
http://fractalforge.cvs.sourceforge.net/viewvc/fractalforge/fractalforge/Mandelbrot.pas?view=markup
Fractal Forge has been
my first serious tentative
with Object Oriented
programming.
It’s written in Object
Pascal (Borland Delphi).
This class is 1751 lines
of code.
It works but it is the most
unSOLID possible design.
Can you spot the issues?
Wednesday, April 18, 12
Slide 40
Slide 40 text
Wednesday, April 18, 12
Slide 41
Slide 41 text
Rule 2
No duplication!
Wednesday, April 18, 12
Slide 42
Slide 42 text
Duplicated intents
Wednesday, April 18, 12
Slide 43
Slide 43 text
Duplicated intents
This code is
repeated several
times in different
services.
The intent is the
same, that is
use cache with a
specific logic.
But every time
the lines in red
are different.
What can we do?
Wednesday, April 18, 12
Slide 44
Slide 44 text
Solution:
Template Pattern in
inner class.
Wednesday, April 18, 12
Slide 45
Slide 45 text
Solution:
Template Pattern in
inner class.
Wednesday, April 18, 12
Slide 46
Slide 46 text
Cons:
Slightly more code (if
only 1 occurrence)
Not the most familiar
of code.
Pros:
Remove of cache
access logic from
main class.
Impossible to forget a
step.
Possible to change
the logic for testing
Solution:
Template Pattern in
inner class.
Wednesday, April 18, 12
Slide 47
Slide 47 text
Just one
more thing
Wednesday, April 18, 12
Slide 48
Slide 48 text
Rule 3
No afterthoughts!
Just one
more thing
Wednesday, April 18, 12
Slide 49
Slide 49 text
Avoid undetermined results
by changing interface
Wednesday, April 18, 12
Slide 50
Slide 50 text
Avoid undetermined results
by changing interface
Here it’s not clear what will happen
Wednesday, April 18, 12
Slide 51
Slide 51 text
Avoid undetermined results
by changing interface
Here it’s not clear what will happen
Wednesday, April 18, 12
Slide 52
Slide 52 text
Avoid undetermined results
by changing interface
Here it’s not clear what will happen
Now it’s clear what’s the goal
Wednesday, April 18, 12
Slide 53
Slide 53 text
Which one does resemble
your code better?
Wednesday, April 18, 12
Slide 54
Slide 54 text
Which one does resemble
your code better?
A well cut code has no interstices
Wednesday, April 18, 12
Design clean interfaces
I thought of
objects being
like biological
cells and/or
individual
computers on a
network, only
able to
communicate
with
messages.
Alan Key
Don’t think Methods,
think Messages
Wednesday, April 18, 12
Slide 57
Slide 57 text
Wednesday, April 18, 12
Slide 58
Slide 58 text
Hollywood Principle
Wednesday, April 18, 12
Slide 59
Slide 59 text
There is no calling order
Hollywood Principle
Wednesday, April 18, 12
Slide 60
Slide 60 text
There is no calling order
Easy to test and mock
Hollywood Principle
Wednesday, April 18, 12
Slide 61
Slide 61 text
Reduce the information
passed around
Immutable objects
Enum or Method instead
of integer and strings
Wednesday, April 18, 12
Slide 62
Slide 62 text
Extract algorithms with
Strategy and Functions
There was a very long and
complex method here...
Wednesday, April 18, 12
Slide 63
Slide 63 text
Wednesday, April 18, 12
Slide 64
Slide 64 text
Fractal architecture
Wednesday, April 18, 12
Slide 65
Slide 65 text
Fractal architecture
1. Inject the Dependencies
Wednesday, April 18, 12
Slide 66
Slide 66 text
Fractal architecture
1. Inject the Dependencies
2. Hide the Objects behind Interfaces
Wednesday, April 18, 12
Slide 67
Slide 67 text
Fractal architecture
1. Inject the Dependencies
2. Hide the Objects behind Interfaces
3. Call Functions and Continuations
Wednesday, April 18, 12
Slide 68
Slide 68 text
Fractal architecture
1. Inject the Dependencies
2. Hide the Objects behind Interfaces
3. Call Functions and Continuations
4. Pass Immutable Value Objects
Wednesday, April 18, 12
Slide 69
Slide 69 text
Fractal architecture
1. Inject the Dependencies
2. Hide the Objects behind Interfaces
3. Call Functions and Continuations
4. Pass Immutable Value Objects
5. Go one level down and repeat
Wednesday, April 18, 12
Slide 70
Slide 70 text
Block state
percolating
from one
level to the
next!
Wednesday, April 18, 12
Slide 71
Slide 71 text
The power of mocks
All dependencies passed on the
constructor using interfaces
Test complex object for behavior
not for state
Wednesday, April 18, 12
Slide 72
Slide 72 text
Delegated Control
Wednesday, April 18, 12
Slide 73
Slide 73 text
Delegated Control
Wednesday, April 18, 12
Slide 74
Slide 74 text
How to operate
Wednesday, April 18, 12
Slide 75
Slide 75 text
How to operate
1. Start with a God class to split
Wednesday, April 18, 12
Slide 76
Slide 76 text
How to operate
1. Start with a God class to split
2. Write a test for it with near 100% coverage
Wednesday, April 18, 12
Slide 77
Slide 77 text
How to operate
1. Start with a God class to split
2. Write a test for it with near 100% coverage
3. Mock all external relations
Wednesday, April 18, 12
Slide 78
Slide 78 text
How to operate
1. Start with a God class to split
2. Write a test for it with near 100% coverage
3. Mock all external relations
4. Extract methods basically everywhere
Wednesday, April 18, 12
Slide 79
Slide 79 text
How to operate
1. Start with a God class to split
2. Write a test for it with near 100% coverage
3. Mock all external relations
4. Extract methods basically everywhere
5. Aggregate and move some methods and external
relation to collaborators
Wednesday, April 18, 12
Slide 80
Slide 80 text
How to operate
1. Start with a God class to split
2. Write a test for it with near 100% coverage
3. Mock all external relations
4. Extract methods basically everywhere
5. Aggregate and move some methods and external
relation to collaborators
6. Repeat again on collaborators until clean
Wednesday, April 18, 12
Slide 81
Slide 81 text
Going Modular
Module
Domain
Service
Adapter
Module Module
Platform
Service Service
Wednesday, April 18, 12
Slide 82
Slide 82 text
Going Modular
Module
Domain
Service
Adapter
Module Module
Platform
Service Service
Uncle Bob's "Package Cohesion Principles" are:
REP: The Release Reuse Equivalency Principle
-- The granule of reuse is the granule of release.
CCP: The Common Closure Principle
-- Classes that change together are packaged
together.
CRP: The Common Reuse Principle
-- Classes that are used together are packaged
together.
Wednesday, April 18, 12
Slide 83
Slide 83 text
Project complexity
Time to develop a feature
OOP+FP
Functional P
Object Oriented P
Procedural P
Wednesday, April 18, 12
Slide 84
Slide 84 text
Project complexity
Time to develop a feature
OOP+FP
Functional P
Object Oriented P
Procedural P
Statistic data sample:
1 interview to myself
Wednesday, April 18, 12
Slide 85
Slide 85 text
Questions?
https://joind.in/talk/view/6304
Feedback welcome on joind.in:
Wednesday, April 18, 12