The document discusses refactoring code to improve its structure and quality. It recommends measuring code smells and toxicity using various metrics tools to identify areas for refactoring. Key areas include complexity, duplication, feature envy, and dependency tangles. The steps involve quantifying issues, visualizing dependencies, agreeing on solutions, and then refactoring the code. Maintaining test coverage is important to ensure refactoring does not introduce bugs. The overall goal is to make the code easier to understand and modify without changing its functionality.

1. Ola.

2. You’re
making
me
refactor.
You
won’t
like
me
when
I
refactor

4. Refactoring?

5. a
change
made
to
the
internal
structure
of
so=ware
to
make
it
easier
to
understand
and
cheaper
to
modify
without
changing
its
observable
behavior
ThoughtWorks

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

8. a
change
made
to
the
internal
structure
of
so=ware
to
make
it
easier
to
understand
and
cheaper
to
modify
without
changing
its
observable
behavior
ThoughtWorks

9. SomeHmes
it
just
feels
right.

13. Step
1:
Measure
the
toxicity.

15. Smells
in
the
code

16. CyclomaHc
Complexity
5
to
7
is
decent
for
most
ruby
code

17. Saikuro

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

19. Flog

20. DuplicaHon
with
Flay
Watch
for
scores
greater
than
30

22. Control
Couples
and
more
with
Reek
Simulated
Polymorphism
Feature
Envy
UHlity
Methods

23. LinHng
with
Dust/Nitpick
JSLint
for
Ruby

24. Common
smells
in
Ruby

25. PrimiHve
Obsession

26. Feature
Envy

27. Meta-­‐programming
Keep
it
simple.
Keep
it
declaraHve

29. Toxicity
is
more
than
code
smells

30. “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/

31. DEPENDENCY

32. Tangles

33. Step
2:
Make
it
visible

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

35. Treemaps

36. Dependency
matrix

37. Step
3:
Agree
on
the
fix

40. Step
4:
Go
fix
it

41. Obrigado