Talk given in Montevideo in 2011 for 30mins. Focussing on code quality and understanding what that means.

1. Ola.

2. @nigelfds
github.com/nigelfds

5. (Talk
+
Examples)
~
1hour
(Talk
–
Examples)
~
30mins

7. Refactoring?

8. a
change
made
to
the
internal
structure
of
soFware
to
make
it
easier
to
understand
and
cheaper
to
modify
without
changing
its
observable
behavior
-­‐
MarLn
Fowler

9. Don't
touch
anything
that
doesn't
have
coverage.
Otherwise,
you're
not
refactoring;
you're
just
changing
shit.

11. a
change
made
to
the
internal
structure
of
soFware
to
make
it
easier
to
understand
and
cheaper
to
modify
without
changing
its
observable
behavior
-­‐
MarLn
Fowler

12. SomeLmes
it
just
feels
right.

14. Step
1:
Measure
the
toxicity.

16. Smells
in
the
code

17. CyclomaLc
Complexity
5
to
7
is
decent
for
most
ruby
code

18. Saikuro

19. Assignments,
Branches,
Calls
with
Flog
Watch
for
scores
greater
than
40

20. Flog

21. DuplicaLon
with
Flay
Watch
for
scores
greater
than
30

22. Flay

23. Control
Couples
and
more
with
Reek
Simulated
Polymorphism
Feature
Envy
ULlity
Methods

24. LinLng
with
Dust/Nitpick
Branch
Checks

25. Common
smells
in
Ruby

26. PrimiLve
Obsession

27. Feature
Envy
class Cart
def price
@item.price + @item.tax
end
end

28. Meta-­‐programming
Keep
it
simple.
Keep
it
declaraLve

30. Toxicity
is
more
than
code
smells

31. “The
real
problem
I
have
with
the
CK
suite
and
similar
metrics
is
that
they
only
measure
a
single
module
(or
class
in
this
case).
I
claim
that
the
quality
of
the
design
of
a
system
is
not
something
that
can
be
determined
by
looking
at
individual
classes.
It
is
conceivable
that
every
class
in
a
system
could
be
considered
reasonable
by
whatever
single-­‐class
metrics
are
being
used,
but
the
overall
design
is
considered
bad.”
Ewan
Tempero:
A
Research
Agenda
hDp://www.cs.auckland.ac.nz/~ewan/

32. Duplicity
vs
Coupling

33. DEPENDENCY

34. Tangles

35. Step
2:
Make
it
visible

36. Treemaps
(Max
CC)
hbp://mbostock.github.com/protovis/

37. Treemaps

38. Dependency
matrix

39. Step
3:
Agree
on
the
fix

42. Step
4:
Go
fix
it

43. “I
do
believe
that
complexity
is
the
enemy.
UnKl
we
beDer
understand
complexity,
our
chances
of
building
beDer
IT
systems
is
limited.
The
first
thing
we
must
understand
about
complexity
is
that
not
all
complexity
is
equal.
And
the
complexity
on
which
most
people
focus
is
probably
the
least
complex
complexity
of
all.”
Roger
Sessions
hbp://simplearchitectures.blogspot.com/2009/03/cancer-­‐of-­‐complexity.html

44. Gracias