►
From YouTube: GitHub Driven Refactoring - GitHub Universe 2017
Description
Presented by Ashley Ellis Pierce, GitHub.
Often we know that our code needs refactoring, but we have no idea where to start. Maybe we studied some common code smells and learned about the things that we should be avoiding, but memorizing the rules doesn’t automatically lead to fixing all problems. In this talk, we explore how you can use GitHub to recognize and address violations to each of the SOLID principles. Using diffs, commit history and pull requests you can learn to recognize patterns in code that point to problems. These same tools can help you correct those issues and write more maintainable code.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Hello,
everyone
welcome.
This
is
github
driven
refactoring.
My
name
is
Ashley
Ellis
Pierce
I'm,
an
application
engineer
at
github
I'm
on
the
billing
and
payments
team.
So
if
you
ever
have
trouble
paying
for
private
repos,
it
was
probably
my
fault
and
if
you
in
you
can
find
me
on
twitter
at
ALS,
paris,
if
you'd
like
to
continue
this
conversation
afterward.
A
So
as
I
mentioned,
this
talk
is
going
to
be
about
github,
driven
or
factoring,
but
first
we
should
talk
about
what
we're
factoring
is
for
anyone
not
familiar
refactoring
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.
There's
some
plies
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,
despite
the
best
of
their
their
intentions.
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
design,
common
problems
and
every
common
design
problem
has
a
specific
refactoring
technique
to
address
that
problem.
A
Once
you
know
what
problem
you
have,
you
can
easily
do
a
search
and
find
the
recommended
refactor
now.
For
that
reason,
this
talk
is
not
going
to
focus
specifically
on
how
to
correct
your
code,
but
more
about
that
very
first
step
of
identifying
exactly
what
problem
it
is
that
we
have
for
a
great
talk
about
how
you
can
use
these
on
principle
violations
to
find
out
exactly
how
to
fix
them.
I
recommend
sandy
Metz's
get
a
whiff
of
this.
A
This
talk
goes
in
detail
about
matching
up
code,
smells
with
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
solid
principles.
The
solid
principles
are
five
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
A
A
A
They
have
whole
courses
on
her
factoring
that
they
teach,
and
this
is
one
of
the
primary
things
that
companies
come
to
thoughtbot
for
so
I
started
at
thoughtbot
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
been
all
of
my
homework
and
read
a
ton
of
books
from
where
factoring
and
clean
code
like
stuff
from
Sandy,
Mets
and
Martin
Fowler
and
all
these
big
names,
I
didn't
have
a
lot
of
experience.
A
A
There
were
much
more
able
to
recognize
in
the
code
patterns
that
I
just
didn't
see
it
all
I'd
submit
my
own
code
and
think
it
looked
to
rate
or
to
review
others
and
say
awesome
great
and
then
later
down
the
road
it
still
grow
into
this
mess,
and
eventually
what
I
came
to
realize
was
that
by
only
looking
at
the
actual
lines
of
code
in
my
editor,
that
I
was
doing
myself
a
disservice
because
you
can't
recognize
design
patterns
in
isolation.
You
need
context.
A
A
A
So
that's
why
all
of
the
tips
that
I
give
you
today
are
not
gonna,
be
some
new
crazy
feature
in
github
that
you've
never
seen
before.
It's
about
saying
that
everyday
aspects
of
github
like
the
commit
history,
PRS
and
comments
differently
and
viewing
them
through
a
lens
that
will
help
you
on
your
goal
towards
refactoring
and
writing
cleaner
code.
A
So,
let's
get
back
to
the
solid
principles
and
see
if
we
can
use
clues
in
github
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
to
simply
use
solid
to
exemplify
how
we
might
use
the
tools
in
github
in
general
to
find
design
principle
violations
and
refactoring
opportunities.
A
Maybe
there's
new
features
or
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
had
to
take
take
a
step
back
and
really
think
about
it.
Why
has
my
class
change
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
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
github
history
of
you
for
that
class.
This
is
where
I
start.
What
I
really
want
to
understand
if
a
class
I
have
might
be
violating
some
design
role,
and
it's
the
perfect
way
to
see
if
your
class
has
violated
the
single
responsibility
principle.
A
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.
Lots
of
small
well
named
methods
that
do
one.
Then
an
engine
start
method
that
takes
a
true
or
false
as
to
whether
we're
starting
the
engine
remotely
through
some
sort
of
app
or
the
FOB
a
delay
start.
So
you
can
set
the
time
that
you
want
to
start
your
engine
like
in
the
morning
at
9:00
a.m.
A
during
the
winter,
so
it's
all
warmed
up
by
the
time
you
get
in
it.
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
define
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
it
needs
a
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
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
I'm
gonna
try
to
take
a
step
back
and
see
if
I
notice,
any
patterns,
and
indeed,
as
I,
look
at
this.
Something
does
begin
to
jump
out
at
me.
A
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,
the
more
I
realize
you
can
group
the
commits
into
two
logical
groups.
We
have
commits
that
are
related
to
the
power
output
of
the
engine,
like
increasing
the
power
adjusting
its
frequency
and
adding
Hill
assistant
idle
functionality,
and
then,
of
course,
we
have
all
the
remote
start
functionality.
A
So
initially,
when
I
looked
at
this
I
thought
there
are
a
bunch
of
reasons
the
class
had
changed
and
that
identifying
one
was
impossible.
But
really
when
you
lump
these
changes
into
larger
categories,
you
can
see
that
the
class
has
two
reasons
for
change
it.
Changing
the
power
output
and
a
change
in
the
remote
start
functionality
and
suddenly
the
way
to
forward
towards
your
factoring
seems
much
easier.
Just
by
using
this
history
view
to
really
understand
what
was
changing
about
my
classes
now.
I
know
that
I
probably
need
to
make
remote
start
its
own
class.
A
Now,
obviously,
for
this
to
work,
you
need
to
be
writing
commit
messages
of
a
certain
type.
You
need
good
commit
messages
that
service
documentation
of
the
important
things
that
change
in
your
code
and
why,
if
you
have
a
bunch
of
whip,
commits
or
commits
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
You
can
write
commits
like
this
as
you're
working,
but
before
you
go
to
merge
that
in
you
need
to
rebase
or
squash
merge
your
commits
to
have
good
commit
messages,
embrace
the
full
power
of
get
to
help
your
factory
code
by
using
it
in
a
way
that
makes
that
easy
help
get
help.
You
I've
heard
the
arguments
of
some
people
that
don't
particularly
care
about
having
nice
commit
messages
and
a
lot
of
them
say
that
they
use
pr's
more
as
their
code
documentation.
A
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
into
practice.
I
never
once
looked
at
a
class
and
said
you
know
what
does
not
closed
for
modification
our
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
think
fully
grasped
the
principle
enough.
A
So
let's
take
another
look
at
some
example
code
and
some
example
pr's
on
github
to
see
if
we
can
make
some
sense
out
of
this
concept,
you
don't
have
to
try
to
read
all
this
code
for
this:
the
class
that
checks
for
engine
health
and
so
mainly
its
concerned,
was
it
with
if
there
are
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
to
check
that
all
the
spark
plugs
are
connected.
So
someone
submits
a
PR
and
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
my
coworker
adds
their
next
feature
and
the
PR
looks
like
this,
and
without
even
having
to
read
the
tiny
tiny
code,
we
can
notice
something
about
this
PR
and
the
last
one.
What
do
we
see
here
in
the
depth?
A
If
every
time
you're
adding
functionality,
you
need
to
change
existing
code,
then
you're
in
violation
of
the
open,
closed
principle
learning.
This
was
a
mind
blown
moment
for
me.
It's
so
simple
learning
to
look
for
this.
One
indicator
in
my
github
pr's
instantly
made
this
principle
makes
so
much
more
sense.
I
couldn't
believe
I
had
been
struggling
and
struggling
to
identify
the
Sirian
practice,
and
the
answer
was
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
A
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
that
extra
work
again
in
the
future.
Now,
in
the
last
section
we
talked
about
her
for
this
to
work,
you
need
to
have
solid,
commit
messages,
and
this
one
comes
with
a
bit
of
a
caveat
as
well.
A
Consistent
style
matters,
blister
work.
You
have
to
have
a
solid
style
in
place.
I
used
to
think
that
having
a
set
style
guide
was
stupid
and
that
didn't
really
matter.
But
then,
when
I
started
to
realize
how
powerful
tool
github
can
be
for
recognizing
opportunities
to
refactor,
then
style
became
much
more
important
to
me
if,
in
addition
to
adding
a
feature,
you're
changing
around
the
syntax
from
symbols
to
strings
or
rearranging
the
method
order,
it's
be
alphabetical,
changing
the
hash,
syntax
or
any
of
the
other
silly
things
developers
fight
about
and
feel
very
strongly
about.
A
Then
your
mudding
up
your
disks
and
you're,
making
it
really
hard
just
in
general,
to
review
your
code,
but
it
also
then
makes
it
easy
and
simple
tricks
like
this
useless
you've
taken
all
the
ease
out
reviewing
this
PR
is
going
to
be
a
pain
in
the
butt.
Programmers
are
lazy,
keep
things
easy,
keep
your
style
consistent.
A
The
next
principle
is
the
Liskov
substitution
principle.
Every
subclass
or
derived
class
should
be
substitutable
for
their
base
or
parent
class
set.
Another
way
this
is,
you
should
be
able
to
call
the
same
method
on
a
subclass,
as
you
could
on
a
parent
and
get
a
compatible
result.
If
the
method
on
a
superclass
returns
a
string,
the
subclass
should
also
be
able
to
handle
that
method
and
return
a
string.
A
Now
there
are
lots
of
languages
where
this
wouldn't
really
be
a
problem,
and
the
language
itself
will
do
some
checking
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
viewable
class
with
a
turn
on
lights
method
in
its
card
subclass.
We
actually
don't
want
to
turn
on
all
the
lights.
Just
the
headlights
and
this
method
is
called
and
for
a
bike
we
don't
have
any
lights.
Unfortunately,
so
we
raise
a
not
implemented
error
and
this
is
of
course,
an
LSP
violation,
because
you
can't
call
turn
on
lights
on
bike
and
get
a
compatible
result
to
what
you
would
get
on
vehicle.
But
you
know
people
forget
and
try
as
hard
as
midnight,
we're
not
perfect
all
the
time.
A
So
I
think
this
is
great.
I
push
this
code
up
to
github
and
open
a
PR,
and
my
code
will
of
course
be
reviewed
by
a
teammate,
but
my
reviewer
is
also
not
perfect,
so
I
don't
want
to
rely
on
them
to
always
have
to
catch
things
like
this,
but
thanks
to
the
magic
of
github
web
hooks
I
don't
have
to
when
I
open
the
PR
I
could
get
this
an
automatic
comment
from
a
style
bot
that
this
might
be
an
LSP
violation.
A
These
automatic
checks
are
a
fantastic
way
of
ensuring
that
your
code
stays
clean.
You
can
write
your
own
style
about
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
plus.
There
are
lenders
like
how
them
from
da
pod
that
I'll
check
for
more
general
style,
guide
violations
and
everyday,
more
powerful
tools
are
coming
out
to
analyze
your
code.
So
if
you've
never
thought
about
writing
custom
web
hooks,
I
really
encourage
it
internal
to
github.
A
A
And
respond
to
are
also
some
things
that
you
could
check
for
with
this.
Obviously,
there
are
places
where
these
things
might
be
called,
where
they're,
not
specifically
in
LSP
violation
but
they're,
usually
a
code
smell,
especially
a
duct
type
language
like
Ruby,
for
the
class
of
a
thing
shouldn't
matter.
A
A
They
probably
knew
when
they
wrote
the
code
that
it
didn't
feel
quite
right,
but
have
met,
but
it
may
have
seemed
like
the
only
way
at
the
time
having
a
bot
publicly
call
attention
to
this
thing
you
did
that
already
felt
kind
of
icky
is
usually
pretty
powerful
motivation
to
take
a
second
look
and
for
reviewers
this
also
gets
them
thinking
about
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.
A
You
can
design
the
code
to
avoid
this
and
they
can
chime
in
with
suggestions
to
help
you
fix
it.
Don't
rely
on
your
human
reviewers
to
always
follow
spot
things
like
this
off
the
bat,
because,
even
if
they
see
it,
they
might
not
want
to
mention
in
a
comment
because
they
assume
the
best
of
you
and
they
assume
you
probably
really
needed
it.
The
bot
makes
no
such
assumptions
and
it
will
force
you
to
rethink
wherever
possible.
Let
your
bots
do
the
nagging
for
you.
A
They
can
see
things
a
lot
more
clearly
than
we
can.
After
all,
when
you
write
a
bot
like
this
you're
writing
it
with
the
sole
focus
of
helping.
You
improve
your
code
when
you're
much
more
focused
on
that
task
than
you
normally
are
as
much
as
we'd
all
like
to
say
that
we're
always
focused
on
code
quality
and
proving
our
code.
We've
all
got
a
million
things
on
our
mind
day
to
day
and
our
jobs.
A
Sometimes
it's
hard
to
see
every
aspect
of
a
pull
request
that
you're
reviewing
clearly
automate
away
the
things
that
can
be
automated,
avoiding
all
those
few
violations
like
this
makes.
Your
code
able
to
adapt
and
grow
much
more
easily,
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
interface
interfaces
that
define
some
sort
of
behavior.
A
A
Here
we
have
an
air
traffic
control
class
and
it
takes
anything
that
implements
that
aircraft
interface
that
we
saw
earlier
and
it
tells
the
aircraft
to
take
off
well
what
if
we
have
a
helicopter
as
a
type
of
aircraft
that
implements
this
interface,
it
should
still
be
able
to
interact
with
air
traffic
control
because
it
still
needs
to
takeoff
visit,
but
it
doesn't
need
to
retract
its
landing
gear.
So
this
is
an
interface
segregation
violation.
A
Another
way
that
this
principle
is
often
explained
is
by
saying
that
many
small
clients,
specific
interfaces
are
better
than
one
large
general-purpose
interface
instead
of
having
one
huge
aircraft
interface,
that
does
lots
of
things,
as
we
saw
it's
better
to
have
a
small
interface.
That
only
does
the
things
that
air
traffic
control
needs.
A
So
I
said
the
typical
example
is
in
Java,
but
can
you
see
eyes
fee
violations
and
non-type
languages
like
Ruby?
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
of
the
aircrafts
that
we'll
be
dealing
with,
and
we
have
a
method
called
today's
aircrafts
that
finds
the
flights
they're
supposed
to
go
out
today
by
checking
where
the
flight
day
is
to
in
Ruby.
A
This
way,
our
method
is
an
active
record
method,
meaning
our
list
of
aircrafts
here
must
be
an
active
record
relation.
A
list
of
active
active
record
objects
straight
from
our
database.
So
even
though
you
don't
see
it
clearly
defined
here,
air
traffic
control
really
relies
on
the
active
record
interface.
A
If
we
were,
if
we
were
to
pretend
that
Ruby
is
typed
and
do
a
little
Ruby
Java
bastardization,
it
would
look
like
this
with
an
explicit
requirement
that
aircrafts
input
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
an
aircraft's
from
a
CSV
instead
of
an
active
record
relation
of
aircraft
straight
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
where
on
CSV
aircraft.
It's
no
big
deal
that
in
the
beginning,
we
assumed
aircrafts
who's
going
to
be
an
actor
record
relation.
But
the
point
is
that
that
assumption
can
get
out
of
hand
really
quickly.
A
First
you're
calling
aircrafts
dot
we're
outside
of
the
aircraft's
class
VIN
aircraft
stop
find
then
aircraft
stat
order,
aircraft
stop
having
and
then
aircraft
our
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
record
interface.
And
this,
of
course,
not
saying
you
shouldn't
use
active
record
within
the
aircraft
class.
A
Calling
active
record
methods
inside
of
the
aircraft
class
is
completely
fine
and
really
what
we
want
here.
A
model-
that's
backed
by
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
Air
traffic
control
should
not
have
to
know
that
aircraft
is
an
active
record,
backed
model,
so
you
can
violate
ISP
and
Ruby,
or
at
least
you
can
violate
the
spirit
of
ISP
and
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.
A
All
of
that
being
said,
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
or
at
least
lots
of
times.
It's
likely
not
the
biggest
issue.
With
your
code.
It's
about
balance.
You
don't
want
to
rely
on
lots
of
huge
interfaces
or
have
tons
of
useless
tiny
interfaces.
A
A
I
would
use
github,
commit
history
here
again
to
see
if
or
how
big
of
a
problem
I
have,
instead
of
just
using
it
to
identify
different
things
that
we're
changing
in
a
class
like
we
did
for
the
single
responsibility
principle
we're
going
to
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
methods
trying
to
imitate
some
other
interface,
then
you
probably
have
an
ISP
violation.
A
The
last
solid
principle
is
the
dependency
inversion
principle.
Any's
must
depend
on
abstractions,
not
concretions.
Here
we
have
a
car
class
with
a
play,
radio
method
and
inside
that
method
we're
calling
FM
radio
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
line
with
the
dependency
inversion
principle.
A
While
you
think
this
isn't
a
violation
of
the
dependency
inversion
principle
or
why
it's
a
worthwhile
sacrifice
to
make
here
and
if
you're,
just
starting
out
on
your
refactoring
journey-
and
you
already
have
a
lot
of
place
in
your
code,
where
you're
coupling
your
classes
to
dependencies,
use
history
and
blame
to
find
out
how
often
those
classes
are
met
or
methods
are
having
to
change.
So
you
can
prioritize
and
make
sure
you're
addressing
your
worst
offenders.
First,
adapting
your
code
to
inject
your
dependencies
into
your
classes.
A
A
A
A
By
following
all
these
tips,
github
can
help
you
refactor
and
achieve
solid
code.
Your
code
will
be
more
flexible
and
maintainable
and
adapt
to
change
easier,
hopefully,
for
all
of
you
here
who
are
already
familiar
with
the
solid
principles
but
had
trouble
applying
them.
These
tips
will
help
you
recognize
through
github
how
to
find
various
solid
violations
and
have
shown
you
in
the
context
of
the
work
that
you
do
every
day
what
those
violations
look
like.
Thank
you.