►
From YouTube: Git driven refactoring - Git Merge 2018
Description
Presented by Ashley Ellis Pierce, Application Engineer, GitHub
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
A
So
as
I
mentioned,
this
talk
is
going
to
be
about
get
driven
refactoring,
but
first
we
should
talk
about
what
we're
factoring
is
for
anyone
not
familiar.
We're
factoring
is
changing
the
structure
of
code
without
modifying
its
behavior.
It's
cleaning
up
your
mess
and,
of
course,
for
this
to
be
the
case.
This
implies
that
there
is
indeed
a
mess
to
clean
up
and
we've
all
been
there.
I,
don't
know
anyone
whose
codebase
is
always
perfect.
A
Knowing
where
we
went
wrong
leads
us
to
where
we
need
to
be
how
well,
luckily
we're
not
the
first
ones
to
ever
write
software,
it's
been
done
before,
and
smarter
people
than
me
have
gone
ahead
and
identified
common
places
that
we
often
go
wrong
and
they've
put
names.
Those
common
problems
and
every
common
design
problem
has
a
specific
or
factoring
technique
to
address
that
problem.
Once
you
know
what
problem
you
have,
you
can
easily
do
a
search
and
find
the
recommended
refactor
now.
A
I
recommend
sandy
menses
get
a
whiff
of
this
that
taught
who
is
in
detail
about
matching
up
code,
spells
for
their
prescribed
refactoring
to
fix
them,
but
again
here,
I'm,
focusing
on
the
first
step,
how
to
find
the
design
problem
to
begin
with,
and
so
that
brings
us
to
the
saw
principles.
The
solid
principles
are
5
design,
principles
for
object-oriented
development
laid
out
by
Robert
Martin
and
intended
to
make
software
more
flexible
and
maintainable.
So,
let's
just
run
through
what
these
principles
are.
A
A
Every
subclass
or
derived
class
should
be
substitutable
for
their
base
or
parent
class,
and
then
the
interface
segregation
principle.
No
client
should
be
forced
to
depend
on
methods
it
does
not
use,
and
the
last
one
is
the
dependency
inversion
principle.
Enemies
must
depend
on
abstractions,
not
concretions.
If
you
follow
these
principles,
your
code
will
be
easier
to
understand
and
easier
to
change.
A
A
A
Well,
maybe
not
quite
I
said
before
that
identify
our
mistakes
leads
us
fixing
it,
but
just
because
you
heard
these
rules
doesn't
mean
you
can
understand
them
completely
and
always
identify
when
you're,
in
violation
of
them,
I'd
venture
a
guess
that
there
are
some
of
you
in
this
audience
that
have
heard
these
design
rules
before
and
so
don't
feel
like.
You
have
a
full
grasp
of
them,
probably
because
you've
had
trouble
recognizing
these
patterns
in
real
life.
So
that's
what
we're
here
to
talk
about
today,
because
I've
had
that
same
problem.
A
A
As
the
first
thing
one
would
look
at
to
help
you
refactor,
so
you're
probably
wondering
how
how
or
why
I
use
them,
as
I
mentioned
in
the
beginning,
I
work
at
github
now
and
since
this
talk
focuses
a
lot
on
github
many
people
assume
that
I
formed
this
talk
as
a
result
of
working
there,
but
I
didn't
the
beginnings
of
this
talk
started
to
form.
For
me,
while
working
at
thoughtbot
Thapa
is
a
software
consultancy
and
they're
well
known
for
their
ability
to
help
companies
write
clean
code.
A
They
have
whole
courses
on
refactoring
that
they
teach,
and
this
is
one
of
the
primary
things
that
companies
come
to
that
before
so
I
started
Thapa
as
an
apprentice
and
I
was
in
general.
Very
green
I
had
only
worked
at
one
company
previously
for
about
a
year,
and
so,
although
I
had
done
all
my
homework
and
read
a
ton
of
books
on
refactoring
singko,
except
from
Sandy
Metz
and
Martin
Fowler,
and
all
these
big
names,
I
didn't
have
a
lot
of
food.
I
didn't
have
a
lot
of
experience.
Putting
that
theory
into
practice.
A
There
were
much
more
able
to
recognize
in
the
code
patterns,
but
I
just
didn't
see
it
all
I'd
submit
my
own
code
and
think
it
looked
great
our
view,
others
and
say
awesome
great
and
then
later
down
the
road
it
still
grown
into
this
mess,
and
eventually
what
I
came
to
realize
was
that
by
only
looking
at
the
actual
lines
of
code
in
my
editor,
I
was
doing
myself
a
disservice
because
you
can't
recognize
design
patterns
in
isolation.
You
need
context.
Otherwise
it's
like
you've
been
studying
for
a
multiple-choice
quiz,
but
suddenly
there's
essay
questions.
A
We
need
to
know
not
just
what
the
rules
are,
but
the
context
that
will
be
expected
to
know
them
in
and
for
me
because
get
is
where
I'm
like
code
lives.
Get.
Is
that
context
so,
instead
of
looking
for
possible
design,
violations
or
areas
that
might
need
refactoring,
but
looking
at
the
code
directly
I
turned
to
get
and
started.
A
So,
let's
get
back
to
the
solid
principles
and
see
if
we
can
use
clues
in
get
to
make
these
principles
make
a
little
more
sense.
I'll
explain
each
of
the
principles
briefly
as
we
go
through,
but
I
want
to
be
clear
that
the
goal
of
this
talk
is
not
necessarily
to
be
an
exhaustive
exploration
of
solid.
My
goal
here
is
simply
to
use
solid
to
exemplify
how
we
might
use
git
in
general
to
find
design
principle
violations
and
refactoring
opportunities.
A
Maybe
there's
a
new
feature
to
add
or
I
want
to
improve
some
bit
of
code,
but
when
I
was
really
trying
to
figure
this
out
and
see
which
of
my
classes,
if
any
might
violate
this
principle,
I
said:
okay,
I
have
to
take
a
step
back
and
really
think
about
it.
Why
has
my
class
changed
recently
because,
ideally,
you
never
would
have
written
any
code
that
violated
the
single
responsibility
principle,
but
if
you're
like
me,
you
probably
thought
everything
was
going
great
when
you
wrote
it
but
down
the
line.
A
Something
starts
to
feel
off
and
you
can't
really
pinpoint
what
it
is,
but
your
code
gets
harder
to
change
and
you
start
looking
for
ways
to
refactor,
and
this
question
is
a
great
place
to
start.
You
have
to
really
know
the
history
of
your
classes
to
know
what
might
have
gone
wrong
with
them
and
luckily,
for
us,
there's
a
place
specifically
suited
for
that,
the
git
log
for
that
class.
This
is
where
I
start
when
I
really
want
to
understand.
A
If
a
class
I
have
might
be
violating
some
design
rule,
and
it's
the
perfect
way
to
see
if
your
class
has
violated
the
single
responsibility
principle.
This
is
the
commit
history
for
my
engine
class
of
my
Tesla
Motors
company
and
here's
the
code.
You
don't
have
to
squint
and
try
to
read
it,
but
with
a
cursory
look,
it
seems
pretty
reasonable
to
me.
A
A
during
the
winter,
so
it's
all
warmed
up
by
the
time
you
get
in
an
idle
method
that
decreases
the
power
output
of
the
engine
and
a
hill
assist
that
increases
the
power
output
when
you're
going
up
hills
and
then
we
just
defined
some
devices
that
are
allowed
to
start
the
engine
remotely
seems
reasonable,
but
this
class
has
been
seeming
a
little
off
to
me.
I
feel
like
I
need
to
refactor,
but
I
can't
really
pinpoint
what's
wrong
with
it.
But
I
know
just
looking
at
the
code.
A
I
sometimes
miss
things,
so
I'm
gonna
take
another
step
back
and
look
at
the
commit
history
for
the
class.
It
seems
like
there
have
been
a
lot
of
reasons.
This
class
change
mainly
adding
some
new
functionality,
but
if
I
take
another
look,
I
can
notice
some
patterns
as
I.
Look
at
this
something
begins
to
jump
out
at
me.
I
have
a
lot
of
changes
in
this
that
are
related
to
the
remote
start
functionality,
but
then,
of
course,
some
that
don't
seem
to
be
related
to
that
at
all
and
really
the
more
I
look
at
this.
A
A
So
initially,
when
I
looked
at
this
I
thought
that
there
were
a
bunch
of
reasons
the
class
had
changed
and
that
identify
one
was
impossible.
But
really
when
you
lump
these
changes
into
larger
categories,
you
can
see
if
the
class
has
two
reasons
for
change:
a
change
in
the
power
output
and
it
changed
in
the
remote
start
functionality
and
suddenly
the
way
forward
towards
your
factoring
seems
much
easier
just
by
using
the
git
to
really
understand
what
was
changing
about
my
classes.
A
Now,
I
know
that
I
probably
need
to
make
remote
start
its
own
class.
Having
this
as
a
separate
class,
will
make
the
code
easier
to
change
and
keep
these
responsibilities
separate,
so
I
don't
have
to
worry
about
every
little
change
to
remote
start
affecting
how
the
power
output
is
determined
by
the
engine.
A
Now,
obviously,
for
this
to
work,
you
need
to
be
writing
commit
messages
of
a
certain
type.
You
need
good
commit
messages
that
serve
as
documentation
of
the
important
things
that
changed
in
your
code
and
why,
if
you
have
a
bunch
of
whip,
commit
or
commit
set
for
trivial
things
like
adding
white
space,
that
is
not
helpful
because
things,
like
add
whitespace,
add
nothing
to
the
overall
story
of
your
code.
That's
documentation
about
what
changes
you
were
going
through
and
your
processes.
You
were
writing
the
code
not
documentation
about
what
changes
the
code
was
going
through.
A
A
You
I've
heard
the
arguments
before
of
some
people
that
don't
particularly
care
about
having
nice
commits
and
a
lot
of
them
say
they
use
PR
as
more
as
their
code
documentation,
but
there's
no
easy
way
to
see
all
the
PR
is
a
touch
one
class
with
PRS.
You
can't
get
quick
context
locally
on
your
machine
or
in
your
editor,
like
you
can
with
the
get
log.
So,
in
my
opinion,
that's
reason
enough
for
me
to
use
commit
messages
that
are
clear
and
concise
and
tell
the
overall
story
of
my
work.
A
So
the
next
solid
principle
is
the
open
closed
principle.
A
class
should
be
open
for
extension
but
closed
for
modification.
This
is
one
of
those
principles
that
sounds
really
simple
but
was
actually
really
confusing
to
me,
because
I
didn't
understand
how
you
could
extend
something
without
modifying
it.
It's
like
saying
you
should
be
able
to
change
this
thing
without
actually
changing
it.
So
I
didn't
really
get
it.
A
I
read
so
many
books
and
blog
posts
and
articles
on
this
and
I
really
felt
like
I
understood
the
concept
in
theory,
but
I
for
the
life
of
me
could
not
figure
out
how
to
put
it
in
practice.
I.
Never
once
looked
at
a
class
and
said
you
know
what
this
is
not
closed
for
modification
I
would
review
my
co-workers
PRS
and
try
to
guess
whether
this
class
would
ever
need
to
change
in
the
future
and
if
that
change
would
be
easy
to
make.
But
I
just
didn't
fully
grasp
the
principle
enough.
A
So
let's
take
a
look
at
some
example
code
and
some
example
PRS
and
github
to
see.
If
we
can
make
some
sense
out
of
this
concept,
you
don't
have
to
try
to
read
all
this
code,
but
this
is
the
class
that
checks
for
engine
health
and
so
mainly,
it's
concerned
with
if
there
any
electrical
shorts
in
the
engine.
So
this
PR
gets
submitted
by
one
of
my
teammates
and
it's
my
job
to
review
it
so
I'm
like
ship,
it
it's
great
and
then
the
next
requirement
comes
in
and
it's
a
new
feature
request.
A
They
want
to
add
something
to
the
check
engine
class.
They
also
want
the
engine
check
that
all
the
spark
plugs
are
connected
because
someone
submits
a
PR.
It
looks
like
this
and
then
another
feature
request
comes
in
more
change.
They
want
to
check
something
else.
They
want
to
check
the
alternator,
so
mercury
grads
their
next
feature
and
the
PR
looks
like
this,
and
without
even
having
to
read
the
tiny
code,
we
can
notice
something
about
this
PR
and
the
last
one.
What
do
we
see
here
in
the
diff?
A
If
every
time
you're
adding
functionality,
you
need
to
change
existing
code,
then
you're
in
violation
of
the
open
principal
learning.
This
was
a
mind-blown
moment
for
me.
It's
so
simple
learning
to
look
for
this.
One
indicator
in
my
get
dis
instantly
made.
This
principal
makes
so
much
more
sense.
I
couldn't
believe
that
I
have
been
struggling
and
struggling
to
identify
this
theory
in
practice,
and
the
answer
was
color-coded
and
in
front
of
me
the
whole
time.
If
every
time
you
need
to
add
a
feature
to
a
class,
you
see
red
in
the
diff.
A
You
know
you
maybe
even
violation
of
the
open-closed
principle.
So
if
you
have
a
class,
it
doesn't
quite
feel
right.
Look
back
at
all
of
the
Piazza
touch
that
class
and
we're
only
meant
to
add
functionality
if
you're,
seeing
a
bunch
of
red
in
the
diff.
This
is
likely
your
problem
and
fixing
this
making
your
class
truly
open
for
extension,
but
closed
for
modification
will
make
it
so
much
easier
to
maintain
in
the
future.
A
All
of
that
red
in
the
diff
indicated
extra
work
that
someone
was
having
to
do
to
shoehorn
the
new
feature
in
and
make
it
fit.
Now
that
we've
recognized
that
the
problem
is
an
open,
closed
violation,
you
have
the
opportunity
to
fix
that
class
and
make
sure
no
one
is
having
to
do
all
of
that
extra
work
again
in
the
future.
A
Now,
in
the
last
section
we
talked
about
how
for
this
to
work,
you
need
to
have
solid,
commit
messages,
and
this
one
comes
with
a
bit
of
a
caveat
as
well
consistent
style
matters.
For
this
to
work,
you
have
to
have
a
solid
style
in
place.
I
used
to
think
that
having
a
set
style
guide
was
stupid
and
that
it
didn't
really
matter.
A
Reviewing
this
PR
is
going
to
be
a
pain
in
the
butt.
Programmers
are
lazy,
keep
things
easy,
keep
your
style
consistent.
The
next
principle
is
the
Liskov
steps.
In
principle,
every
subclass
or
derived
class
should
be
substitutable
for
their
base
or
parent
class,
so
set
another
way.
This
is
you
should
be
able
to
call
the
same
method
on
subclass
as
you
could
on
a
parent
and
get
a
compatible
result.
If
the
method
on
superclass
returns
the
string,
the
subclass
shells
to
be
able
to
handle
that
method
and
return
a
string.
A
Now
there
are
lots
of
my
languages
where
this
wouldn't
really
be
a
problem,
and
the
language
itself
will
do
some
tracking
of
this,
for
you,
but
I
program
in
Ruby
and
Ruby
has
no
such
guarantees.
So,
despite
all
of
our
best
intentions,
I
or
someone
else
on,
my
team
might
end
up
writing
something
like
this.
A
Here
we
have
a
vehicle
class
with
a
turn
on
lights
method
in
its
car
subclass.
We
actually
don't
want
to
turn
on
all
the
lights.
Just
the
headlights
when
this
method
is
called
and
for
a
bike,
we
don't
have
any
lights.
Unfortunately,
so
we
raise
and
not
implemented
error
in
this,
of
course,
in
LSP
violation,
because
you
can't
call
turn
on
lights
on
bike
and
get
a
compatible
result
what
you'd
get
on
vehicle,
but
you
know
people
forget
and
try
as
hard
as
you
might
were
not
perfect
all
the
time.
A
These
automatic
checks
are
fantastic
way
of
ensuring
that
your
code
stays
clean.
This
is
just
an
example,
but
you
can
write
your
own
style
bot
like
this
to
check
for
whatever
design
principles
you
want
provided,
there's
something
easily
identifiable
in
the
code
like
calling
a
not
implemented
error
on
a
subclass.
A
So
if
you've
never
thought
about
writing
your
own
custom,
webhooks
I
really
encourage
it.
Possibilities
are
endless,
and
this
can
be
a
great
tool
for
a
factoring
calling
attention
to
these
things.
Foos
of
a
bot
makes
the
person
who
submitted
the
pull
request,
stop
and
reconsider
their
code.
They
probably
knew
when
they
wrote
it.
A
It
didn't
feel
quite
right,
but
it
may
have
seemed
like
the
only
way
at
the
time
having
a
bot
publicly
call
attention
to
the
issue
is
usually
pretty
powerful
motivation
to
take
a
second
look
and
for
reviewers
this
also
gets
some
thinking
about
it
as
well.
Maybe
they
normally
would
have
skipped
over
or
not
noticed
it
in
their
view,
but
now
suddenly
they're
also
thinking
about
different
ways.
You
can
design
the
code
to
avoid
this.
A
Don't
rely
on
your
human
reviewers
to
always
spot
things
like
this
off
the
bat,
because,
even
if
they
see
it,
they
might
not
want
to
mention
it
in
a
comment
because
they
assume
the
best
of
you
and
they
assume
you
probably
really
needed
it.
The
bot
makes
no
sense
options
and
it
will
force
you
to
rethink
whenever
possible.
Let
your
box
do
the
nagging.
A
So
the
next
principle
is
the
interface
segregation
principle.
No
client
should
be
forced
to
depend
on
methods.
It
does
not
use
the
classic.
Examples
of
this
are
in
typed
languages
like
Java,
where
you
have
actual
interfaces
that
define
some
sort
of
behavior.
So,
let's
switch
to
Java
to
see
an
example.
A
Here
we
have
an
air-traffic
control
class
and
it
takes
anything
that
implements
the
aircraft
interface
that
we
saw
earlier
and
it
tells
the
aircraft
to
take
off
well
what
if
we
have
a
helicopter
as
the
type
of
aircraft
that
implements
this
interface,
it
should
still
be
able
to
interact
with
the
air
traffic
control
because
it
still
needs
to
take
off,
but
it
doesn't
need
to
retract
its
landing
gear.
So
this
is
an
interface
segregation
violation.
A
Air
traffic
control
depends
on
everything
that
interacts
with
having
a
retract
landing
gear
method,
even
though
it
does
not
use
it,
because
the
aircraft
interface
defines
in
another
way.
That
this
principle
is
often
explained
is
by
saying
that
many
small
client
specific
interfaces
are
better
than
one
large
general-purpose
interface
instead
of
having
one
huge
aircraft
interface,
that
does
lots
of
things.
We
saw
it's
better
to
have
a
small
interface.
A
Let's
take
another
look
at
the
air
traffic
control
class
this
time
in
Ruby
this
time
when
you
initialize
the
class,
you
pass
in
all
the
aircrafts
that
we'll
be
dealing
with,
and
we
have
a
method
called
today's
aircraft
that
finds
the
flights
that
are
supposed
to
go
out
today
by
checking
where
the
flight
day
is
today
in
rails.
This
way
or
method
method
is
an
active
record
method,
meaning
our
list
of
aircrafts
here
must
be
an
active
record
relation,
a
list
of
objects
straight
from
our
database.
A
So
even
though
you
don't
see
it
clearly
defined
here,
air
traffic
control
really
relies
on
the
active
record
interface.
If
we
were
to
pretend
like
Ruby,
is
typed
and
do
a
little
Ruby
Java
bastardization.
It
would
look
like
this
with
an
explicit
requirement
that
aircrafts
implement
the
active
record
interface,
which
is
really
not
that
different
from
the
air
traffic
control
class
in
Java.
That
we
saw
was
an
ISP
violation.
A
What
if
you
wanted
to
pass
in
aircrafts
from
a
CSV
instead
of
an
aircraft
relation
instead
of
an
active
record
relation
of
aircrafts
from
your
database?
You
wouldn't
be
able
to
because
there's
an
assumption
that
the
aircrafts
are
an
active
record
relation.
Of
course
you
could
take
advantage
of
Ruby's
duck
typing
and
just
define
a
wear
method
on
CSV
aircrafts.
If
we
define
we're
on
our
CSV
aircraft,
it's
no
big
deal
that
in
the
beginning,
we
assumed
aircrafts
is
going
to
be
an
active
record
relation.
A
But
the
point
is
that
that
assumption
can
get
out
of
hand
really
quickly.
First
you're
calling
aircrafts
to
wear
outside
of
the
aircraft
class.
Then
aircrafts
not
find
the
aircraft's
net
warder
the
aircraft
start
having
and
then
aircrafts
that
group
and
before
you
know
it,
you
basically
need
to
re-implement
all
of
active
record
on
your
CSV
aircrafts
class
to
be
able
to
use
it
with
air
traffic
control
because
you
wrote
the
air
traffic
control
class,
assuming
that
aircrafts
would
always
adhere
to
the
active
interface.
A
Call
the
active
record
methods
inside
of
the
aircraft's
class
is
completely
fine,
and
actually
what
you
want
in
this
example
we're
keeping
the
aircraft
the
today's
aircrafts
calls
inside
of
the
aircraft
class,
and
so,
instead
of
calling
it
in
the
air
traffic
control
class.
This
is
a
much
better
way
to
do
it,
because
a
model,
that's
backed
by
active
active
record,
can
of
course,
use
active
record
methods,
but
just
don't
let
that
leak
all
over
the
rest
of
your
application
into
completely
unrelated
models
like
air
traffic
control.
A
Pane
Ruby
by
relying
on
huge
general-purpose
interfaces
like
active
record
instead
of
small
client
specific
interfaces
like
those
methods
that
you've
defined
on
your
model,
because,
whether
we're
in
Java
or
Ruby,
the
statement
that
small
client
specific
interfaces
are
better
than
one
large
general-purpose
interface
still
remains
true,
whether
you're
using
a
type
language
like
Java
or
a
dynamic
language
like
Ruby
using
a
large
general-purpose
interface,
isn't
always
a
huge
deal,
though,
or
at
least
it's
a
lot
of
times
likely
not
the
biggest
issue
with
your
code.
It's
about
balance.
A
You
don't
want
to
rely
on
lots
of
huge
interfaces
or
have
tons
of
useless
tiny
interfaces.
You
want
to
be
able
to
take
advantage
of
Ruby's
duck
typing
and
implement
your
own
version
of
one
small
method,
but
not
reimplemented
record
on
a
non
active
record
model
so
to
use
git
to
help.
You
find
that
balance.
I
would
use
the
git
log
in
here
see
if
or
how
big
of
a
problem
I
have,
instead
of
just
using
it
to
identify
different
things
that
are
changing
in
a
class
like
we
did
for
the
single
responsibility
principle.
A
We're
gonna
use
it
here
to
see
how
often
our
class
is
changing
and
when
change
happens,
how
often
is
it
related
to
some
sort
of
ISP
violation?
If
you
have
a
class
like
this,
where
you're
constantly
adding
additional
message
trying
to
imitate
some
other
interface,
then
you
probably
have
an
ISP
violation.
A
So
the
last
solid
principle,
it's
the
dependency
inversion
principle
and
it
is-
must
depend
on
abstractions,
not
concretions.
Here
we
have
a
car
class
with
a
play,
radio
method
and
inside
that
method,
recalling
FM
radio
dot
play.
This
makes
FM
radio
a
dependency
of
the
car
class.
This
class
relies
on
FM
radios,
continued
existence
and
you
can't
easily
make
cars
with
different
types
of
radios
to
be
in
the
dependent
to
be
in
line
with
the
dependency
inversion
principle.
A
We
want
to
decouple
this
code
so
to
do
that,
we
can
practice
a
concept
called
dependency
injection
we're
instead
of
calling
FM
radio
deep
in
the
internals
of
our
car
class,
we
inject
it
as
a
dependency
right
when
we
initialize
the
class.
This
is
another
case
where
you
could
benefit
from
an
automatic
style,
ba
and
github,
or
whatever
your
code.
A
You're
good
to
go.
Car
is
now
less
specific
and
a
lot
more
reusable.
So,
let's
recap:
how
can
get
help
you
refactor?
You
can
use
the
git
log
to
group
commits
into
topics
and
recognize
when
a
class
is
doing
more
than
one
thing.
You
can
keep
an
eye
out
for
red
in
the
diff
when
you're
adding
functionality.
This
could
indicate
a
violation
of
the
open,
closed
principle.
A
You
could
integrate
tools
like
automatic
style
enters
with
your
github
account
to
make
code
cleaner
and
easier
to
recognize
problems.
Use
the
git
log
and
get
blamed
to
find
out
how
often
class
their
methods
have
had
to
change.
This
tells
you
where
your
worst
offenders
most
in
need
of
refactor
are
by
following
all
these
tips.
It
can
help
you
a
factor
and
achieve
solid
code.
The
code
will
be
more
flexible
and
maintainable
and
adapt
to
change
easier,
hopefully,
for
all
of
you
here
who
are
already
familiar
with
solid
principles,
but
I
had
trouble
applying
them.