Detailed Notes
Code reviews are starting to become more common in enterprise development. Dev Ops and related automation have helped shine the light on improving quality and reliability in our processes. This presentation looks at how we can set our teams up for success in code reviews through better and consistent processes.
Code Reviews In Detail There is a time and place for code reviews. Likewise, there are ways to approach these complex tasks that can make the most of both our time and resources. Nevertheless, this process does not come without cost. Therefore, we need to be intentional in our approach and requirements to craft better code and provide a path for building better developers.
The Mentor-Mastermind Group This series comes from our mentoring/mastermind classes.  These classes are virtual meetings that focus on how to improve our technical skills and build our businesses.  The goals of each member vary.  However, this diversity makes for great discussions and a ton of educational value every time we meet.  We hope you enjoy viewing this series as much as we enjoy creating it. As always, this may not be all new to you, but we hope it helps you be a better developer. Drop us a line to find out when the next one is so you can join our group.
Transcript Text
[Music] we will get started here and this time we're going to go we're going to talk about code reviews we have mentioned code reviews a couple of times and also static analysis tools and so those are going to come into play as part of this presentation but it's we've talked about code reviews as and you know hey they're good things they're nice to have this is a little bit more about how to do them and thinking about making them a part of your life basically a part of your processes because there definitely is a value to it and so we're going to talk we'll start with just sort of what is a code review what what entails actual code reviews where you think about them put a little bit of a definition around it we're going to talk about the benefits of code reviews there's also costs you know you can think pros and cons but there's definitely an investment essentially that you're making into your your code your organization when you're do and it's really is it's your organization more than even your code when you do code reviews we're going to talk about some some points you know some places where it makes sense to do a code review and sort of how to factor that into your processes particularly if you have uh very well defined you know like ci cd things like that that have sometimes even automated process is built into your whole flow from writing code to deploying out to production and then we're going to talk a little bit about building habits making it something that um it's something that you're you're not only comfortable with but it just becomes you're it's very natural to your your process whether it is an organization or it is um a personal kind of code review whatever that would be it's not so much a culture there but a code review attitude we'll say so first what's a code review i mean go with the definition i started you know checking out a little bit on this one so from d-zone developer zone uh quick shameless plug for them uh if if you want to learn stuff about anything technical basically check out d-zone they've got all kinds of downloadable little flyers and e-books they have all kinds of articles they cover lots of technology stuff it's a great source for just keeping up with what's going on so for them definition code review is a systematic examination of software source code intended to find bugs and estimate the code quality um slightly reworded it's a process where source code's peer-reviewed your goal really is to address bugs standards really maintain standards and overall quality now this also as i'll bring up a little bit through this presentation is a short-sighted uh i see this is a little bit short-sighted as a view of what a code review is because while code reviews are by the name itself focused on code i think that there is a lot that comes out of code reviews it actually has to do with the developers and your development shop your software development processes that is probably even more valuable than the code review process itself so code review points where which is basically okay if i want to do a code review and go back here just looking at the most basic you know we're we're going to do a systematic examination of software source code basically we're looking for bugs trying to make sure that we're following standards and making sure that we're matching a certain quality so there's different places that make sense or that i guess it's an option to do a code review you can do it on a commit so as soon as somebody commits code you can have something that says hey it needs to be reviewed we need to go through a code review process you can do it before deployment so you can say before we deploy to and deployment may not be we're not talking necessarily production deployment so this could be for example we do let's say we do weekly deploys to a qa staging server you know something along those lines then maybe that's part of it is it your before you do that deployment part of the process is we're going to do a code review and this may either you know stop the deployment or maybe something that we put on our backlog for uh to address before the next deployment it may be part of a release so your release process particularly if you're thinking of sprints um that can be a really good way to do it is that as you get towards the end of the sprint where you're you're into that this is what we're going to put in this sprint this is going to be released you're doing your sprint review maybe that part of that is you have a code review as well that you go through it say hey we're going to look at everything that we've done for this release it's slightly same but slightly different in um its placing as you can do it as part of a retrospective so it could be something that you've you've already deployed you've released it to some extent but now you're going back and looking at what you did and you're actually taking a closer look at the code itself and then you may do it um with all of these regardless of the the time points it can be done individual individually you may have certain individuals do a code review you may have a team that gathers and has some sort of a team meeting or something along those lines whether it's virtual or in person um these there are plenty of ways that you can look at it and you do get slightly different um costs and benefits on whether you you have in like individuals just sort of check code and they just by themselves do a code review versus having that that communication that meeting kinds of an approach where you have multiples and multiple people involved and they're together doing the code review and you can do it much like any other meeting where there may be like a pre-meeting kind of thing or essentially you can send out the code you know effectively setting an agenda you can send the code out let everybody review it beforehand and maybe even send some comments in so that your meeting is focused on the feedback and you're not not necessarily going through the work of a code review during that meeting but instead you're going through the uh the communication of in the discussion of that code because code reviews are not always going to be black and white there are it's like a lot of things where there are some gray areas in there where you may say uh it may even be open-ended questions is this the best way to do this does this follow our standards the way we want it to so timing and your approach can be of a big factor in whether a code review how useful it is um and whether it's even going to be something that you can maintain and turn into a habit as an organization or even as an individual developer so sort of laid the groundwork that there's this thing out there and i really want to talk you know get a little bit more now into the benefits of why would you do this because even thinking about it already you know that all right we're spending some time we're looking at code it's all been written maybe it's already been deployed and we've got resources that we're now spending their time over here over here on this code review thing when they could be on this new development thing or fixing bugs so why would you even care to do a code review particularly if you think it's like hey that source has been released so there may not be any use in us doing that well there are some benefits one uh and i'll start sort of in the the middle on this one actually reducing bugs is sort of the obvious one there are bugs that and i think we all know there are bugs that you can release that may not be it may not appear except in certain cases they could be like outlier bugs and things like that they may also be things that only trigger at certain times like there's race conditions that you'll run into where everything runs fine until you happen to have task a and task b run at close enough the same time window that they lock each other or block each other or cause each other to break and there's also some state kinds of things that we can run into where you're the only way you're going to see that bug is if you're in a certain state and sometimes if you haven't run into this you'll realize that if you look at the code that thing will jump out at you as you look at the code you'll say hey there's a gap here or here's a here's a check that we're not making uh particularly i can code it may be something where like for example you have a try catch and the catch part of it when you catch the exception it's not doing anything so all it's doing effectively is just hiding the exception you just say oh i'm going to try this and if you don't have it do anything when it catches an exception then you can essentially swallow the exception sometimes that's that's needed or that's part of your design but a lot of times that's not and technically probably should not be as if there's an exception something somewhere should be noted so that you can handle that exception properly there should be some sort of handling and some sort of clean addressing of that situation so reducing bugs even if the code's already gone out it could go through qa but you will still have could there'll be cases and instances where a code review will actually surface bugs that were not found otherwise along with that that becomes and this is a it's a bigger picture than just bugs but improving code quality because now because there are things that you can do you can code stuff that is not going to generate a bug but is going to be potentially not scalable easily we all know you know really nasty spaghetti code or stuff that's not documented or the the naming standards are ridiculously bad where the maintenance is a nightmare um you can have stuff where the the logic flow is so convoluted that not only is it hard to maintain but it also ends up being not scalable there's a certain point where you realize that if you call that enough times or if you try to push enough data through it it breaks it just it chokes it brings the system to its knees so it's improving code quality and not just through bugs but all of the other things that we want good code to do which makes it you know it's readable it's maintainable it's scalable it's stable those are things that you're going to find you can get those things out of a code review those kinds of things can be surfaced and then addressed i talked about there being more to a code review than the code itself and so one of those is cross-training of the team when you have other developers looking at your code regardless of how the team is organized that means that those other developers get an insight into your code into what you were working on and you might be working side by side by with somebody and working on roughly the same uh functions or methods or pieces of code but if you don't do it then it's something that could be a blind spot to you and when you see when you're doing code reviews you're bringing the team together to say all right let's all take a look at this and see what we're doing so you get a you can see not only what they're doing also but actually sort of how they think and while yes some people can be personally attached to their code and feel uh we'll say slighted if somebody points out a you know a bug or an improvement or something like that i think well i'm not if you do it right then you're gonna you're gonna pull the team together instead of break them apart and if somebody wants to be you know point at them like hey you had six bugs i only had three or something like that then you know to be flippant you smack them upside the head and say no that's not how this works it's not what this is that's not what we're trying to do um but know to be more but more seriously about it is you can build a team culture because then you get done right is it's hey we're all working together so it's not that you wrote code that had a bug in it or something like that it said hey here's the direction we want to go and here's another set of eyes to help you you know remind you that hey here's something that we do or as a team to discuss code quality to a level of hey you've got a solution and we're looking at that as a team and maybe it's maybe we can as a team come up with a better solution or we can review some of the other options that are out there and it educates all of us on that process on that problem-solving process and how we got to that solution because code review sometimes is not just pointing out hey this needs to change sometimes it's a conversation that hey you did this i want to understand your thought process or why did you need to do it that way i don't i thought it would be simpler and you have this more complicated thing and this sort of goes also back to the cross training where you may say yeah i did it this way and it may seem sort of odd but it's because i found that we have a b and c requirements that require us essentially to do the code this way and it may even go to the the most famous and nasty of things that you'll find occasionally where you'll have a comment even in a code that says this line doesn't really do anything but i have to have it or else the code breaks and i can't figure out why and i think we've all run up against those at some point and code reviews can can surface those sayings sometimes it'll be somebody else can actually say oh this is why you have to do that or it at least notifies everybody that oh yeah this is yeah it's like this is a critical piece of code even though it doesn't look like it so please don't touch it you know it's it goes back to a old simpsons episode where the neighborhood gets together to build a house and there's a poster on one of the children's room bedrooms and kid doesn't like it is about to take it down i'm like oh no no don't take that poster down it's a load-bearing poster which you know an architectural joke would be is pretty amusing in itself but we have that in code i think we've all had those moments where we realized that this doesn't make sense that i need to do this but i need to because if i take this out everything breaks but if i leave it in it works now probably there is something that you know there's probably something more to it but sometimes that's all we can find at the point and we get to move on and so the last point too is that i think the more you discuss your code in a team environment where everybody's pulling towards let's be better as a team and we talk about building better developers this is building a better development team a better development environment a better development culture that building that up spending that time helps you remove your personal attachment to your code there's still that pride and work ethic i think that goes into it where you say hey i want to i'm going to strive to go into a code review and do things in a way that checks all the boxes off and is something that people say hey this is you know this this follows our standards but in doing so i think if you do in the right environment it pushes you to do that without you feeling like it's a personal attack if you didn't and it makes it that much easier for you to throw your code out there and say hey take a look at this you know do you have i think this works do you have some suggestions on how it can be better because that's going to be key to getting better is not doing the same thing that you want to do but getting other people to take a look at it and point out where you can make improvements you know if you if you write code perfect the first time you will never get better either technically there'd be no need if you write 100 perfect code there is no better but nobody does that so there's always going to be a better and the the sooner that we remove we'll say almost the stigma in our own mind of us not being at a hundred percent the sooner we're going to be able to improve you
Transcript Segments
[Music]
we will get started here and this time
we're going to go we're going to talk
about code reviews we have
mentioned code reviews
a couple of times and
also static analysis tools and
so those are going to come into play as
part of this presentation
but it's
we've talked about code reviews as and
you know hey they're good things they're
nice to have
this is a little bit more about
how to do them and thinking about making
them a part of your life basically a
part of your processes because there
definitely is a value to it
and so we're going to talk we'll start
with just sort of what is a code review
what
what entails
actual code reviews where you think
about them put a little bit of a
definition around it
we're going to talk about the benefits
of code reviews there's also costs you
know you can think pros and cons but
there's definitely
an investment essentially that you're
making into your
your code your organization
when you're do and it's really is it's
your organization more than even your
code when you do code reviews
we're going to talk about some
some points you know some places where
it makes sense to do a code review
and sort of how to
factor that into your processes
particularly if you have uh very well
defined you know like ci cd things like
that
that have sometimes even automated
process is built into your whole
flow from writing code to deploying out
to production
and then we're going to talk a little
bit
about building habits
making it something that
um
it's something that you're you're
not only comfortable with but it just
becomes
you're it's very natural to your your
process whether it is an organization or
it is um a personal
kind of code review
whatever that would be it's not so much
a culture there but a code review
attitude we'll say
so first
what's a code review
i mean go with the definition i started
you know checking out a little bit on
this one so from d-zone developer zone
uh
quick shameless plug for them uh if if
you want to learn
stuff about anything technical basically
check out d-zone they've got all kinds
of downloadable little flyers and
e-books they have all kinds of articles
they cover lots of technology stuff
it's a great source for just keeping up
with what's going on
so for them definition code review is a
systematic examination of software
source code intended to find bugs and
estimate the code quality
um slightly reworded it's a process
where source code's peer-reviewed
your
goal really is to address bugs
standards really maintain standards and
overall quality
now this
also as i'll bring up a little bit
through this presentation is
a short-sighted uh i see this is a
little bit short-sighted as a view of
what a code review is
because while code reviews are
by the
name itself focused on code
i think that there is a lot that comes
out of code reviews it actually has to
do with the developers and your
development shop your software
development processes
that is
probably even more valuable than the
code review process itself
so code review points
where which is basically okay if i want
to do a code review and go back here
just looking at the most basic you know
we're
we're going to do a systematic
examination of software source code
basically we're looking for bugs trying
to make sure that we're following
standards and making sure that we're
matching a certain
quality
so there's different places that make
sense or that
i guess it's an option to do a code
review you can do it on a commit so
as soon as somebody commits code you can
have something that says hey it needs to
be reviewed we need to go through a
code review process
you can do it before deployment so you
can say before we deploy to
and deployment may not be we're not
talking necessarily production
deployment so this could be
for example we do let's say we do weekly
deploys to a
qa
staging server you know something along
those lines then maybe that's part of it
is it your before you do that deployment
part of the process is we're going to do
a code review
and this may either you know stop the
deployment or
maybe something that we put on our
backlog for uh to address before the
next deployment
it may be part of a release so your
release process particularly if you're
thinking of sprints
um
that can be a really good way to do it
is that as you get towards the end of
the sprint where you're you're into that
this is what we're going to put in this
sprint this is going to be released
you're doing your sprint review maybe
that part of that is you have a code
review as well that you go through it
say hey we're going to look at
everything that we've done
for this release
it's slightly
same but slightly different in
um
its placing as you can do it as part of
a retrospective so it could be something
that you've you've already deployed
you've released it to some extent but
now you're going back and looking at
what you did and you're actually taking
a closer look at the code itself
and then you may do it um
with all of these regardless of the the
time points
it can be done
individual individually you may have
certain individuals do a code review you
may have a team that gathers and has
some sort of a team meeting or something
along those lines whether it's virtual
or
in person
um
these
there are plenty of ways that you can
look at it and you do get slightly
different um costs and benefits
on whether you you have in like
individuals just sort of check code and
they
just by themselves
do a code review versus having that
that communication that meeting
kinds of an approach where you have
multiples and multiple people involved
and they're together doing the code
review and you can do it
much like any other meeting where there
may be
like a pre-meeting kind of thing or
essentially you can send out the code
you know effectively setting an agenda
you can send the code out let everybody
review it beforehand and maybe even send
some comments in so that your meeting is
focused on the feedback and you're not
not necessarily going through the work
of a code review during that meeting but
instead you're going through the
uh the communication of
in the discussion of that code because
code reviews are not always going to be
black and white there are
it's like a lot of things where there
are some gray areas in there where you
may say uh it may even be open-ended
questions is this the best way to do
this does this
follow our standards the way we want it
to
so timing and
your approach
can be of a big factor in whether a code
review
how useful it is um and whether it's
even going to be something that you can
maintain and turn into a habit as
an organization or even as an individual
developer
so sort of laid the groundwork that
there's this thing out there
and i really want to talk you know get a
little bit more now into the benefits of
why would you do this because even
thinking about it already you know that
all right we're spending some time we're
looking at code it's all been written
maybe it's already been deployed
and we've got
resources that we're now spending their
time over here over here on this code
review thing when they could be on this
new development thing or fixing bugs
so why would you even care to do a code
review particularly if you think it's
like hey
that source has been released so
there may not be any use in us doing
that well
there are some benefits
one uh and i'll start sort of in the the
middle on this one actually reducing
bugs is sort of the obvious one
there are
bugs that and i think we all know there
are bugs that you can release
that may not be
it may not appear
except in certain cases they could be
like outlier bugs and things like that
they may also be things that only
trigger at certain times like there's
race conditions that you'll run into
where
everything runs fine until you happen to
have task a and task b
run at close enough the same time window
that they lock each other or
block each other or cause each other to
break
and there's also some state kinds of
things that we can run into where
you're the only way you're going to see
that bug is if you're in a certain state
and sometimes
if you haven't run into this you'll
realize that if you look at the code
that thing will jump out at you as you
look at the code you'll say hey
there's a gap here or here's a here's a
check that we're not making
uh particularly i can code it may be
something where like for example you
have a try catch
and
the catch part of it when you catch the
exception it's not doing anything so all
it's doing effectively is just
hiding the exception you just say oh i'm
going to try this and if you don't have
it do anything when it catches an
exception then you can essentially
swallow the exception
sometimes that's
that's needed or that's part of your
design
but a lot of times that's not and
technically probably should not be as if
there's an exception something somewhere
should be noted so that you can
handle that exception properly there
should be some sort of handling and some
sort of clean
addressing of that situation
so reducing bugs even if the code's
already gone out it could go through qa
but you will still have
could there'll be cases and instances
where
a code review will actually surface bugs
that were not found otherwise
along with that that becomes
and this is a it's a bigger picture than
just bugs but improving code quality
because now because
there are things that you can do you can
code stuff that is not going to generate
a bug but is going to be
potentially not scalable
easily we all know you know really nasty
spaghetti code or stuff that's not
documented or the the naming standards
are ridiculously bad
where the maintenance is a nightmare
um you can have stuff where
the the logic flow
is so convoluted that not only is it
hard to maintain but it also ends up
being not scalable there's a certain
point where you realize that if you call
that enough times or if you try to push
enough data through it it breaks it just
it chokes it brings the system to its
knees
so it's improving code quality and not
just
through bugs but all of the other things
that we want good code to do which makes
it you know it's readable it's
maintainable it's scalable it's stable
those are things that you're going to
find you can get those things out of a
code review those kinds of things can be
surfaced and then addressed
i talked about
there being more to a code review than
the code itself
and so one of those is cross-training of
the team
when you have
other developers looking at your code
regardless of how the team is organized
that means that those other developers
get an insight into your code into what
you were working on
and you might be working side by side by
with somebody and working on roughly the
same
uh functions or methods or pieces of
code
but if you don't do it then
it's something that could be a blind
spot to you and when you see when you're
doing code reviews you're bringing the
team together to say all right let's all
take a look at this and see
what we're doing so you get a you can
see not only what they're doing also but
actually sort of how they think
and while yes some people can be
personally attached to their code and
feel
uh we'll say slighted if somebody points
out a you know a bug or an improvement
or something like that
i think
well i'm not
if you do it right
then you're gonna
you're gonna pull the team together
instead of break them apart and if
somebody wants to be you know point at
them like hey you had six bugs i only
had three or something like that
then you know
to be flippant you smack them upside the
head and say no that's not how this
works it's not what this is that's not
what we're trying to do
um
but know to be more but more seriously
about it
is you can build a team culture because
then you get
done right is it's hey we're all working
together
so it's not that
you wrote code that had a bug in it or
something like that it said hey here's
the direction we want to go
and here's another set of eyes to help
you you know remind you that hey here's
something that we do
or
as a team to discuss code quality to a
level of hey
you've got a solution
and we're looking at that as a team and
maybe it's maybe we can as a team come
up with a better solution
or we can review some of the other
options that are out there
and it educates all of us on that
process on that problem-solving process
and how we got to that solution
because code review sometimes is not
just pointing out hey this needs to
change
sometimes it's a conversation that hey
you did this
i want to understand your thought
process or
why did you need to do it that way i
don't i thought it would be simpler and
you have this more complicated thing and
this sort of goes also back to the cross
training where you may say
yeah i did it this way and it may seem
sort of odd but it's because i found
that we have a b and c requirements that
require us essentially to do the code
this way
and it may even go to the the most
famous and nasty of things that you'll
find occasionally where you'll have a
comment even in a code that says
this line doesn't really do anything but
i have to have it or else the code
breaks and i can't figure out why and i
think we've all run up against those at
some point
and code reviews can can surface those
sayings sometimes it'll be somebody else
can actually say oh this is why you have
to do that
or it at least notifies everybody that
oh yeah this is yeah it's like this is a
critical piece of code even though it
doesn't look like it so please don't
touch it
you know it's
it goes back to a
old simpsons episode
where the neighborhood gets together to
build a house
and
there's a poster on one of the
children's room bedrooms and kid doesn't
like it is about to take it down i'm
like oh no no don't take that poster
down it's a load-bearing poster
which
you know an architectural joke would be
is pretty amusing in itself
but we have that in code i think we've
all had those moments where we realized
that this doesn't make sense that i need
to do this
but i need to because if i take this out
everything breaks but if i leave it in
it works
now
probably there is something that you
know there's probably something more to
it but sometimes that's all we can find
at the point and we get to move on
and so the last point too is that
i think the more you
discuss your code
in a team environment where everybody's
pulling towards let's be better as a
team
and we talk about building better
developers this is building a better
development team a better development
environment a better development culture
that
building that up spending that time
helps you
remove your personal attachment to your
code
there's still that pride and work ethic
i think that goes into it where you say
hey i want to
i'm going to strive to go into a code
review and do things in a way
that
checks all the boxes off and
is something that people say hey this is
you know this this follows our standards
but
in doing so i think if you do in the
right environment it pushes you to do
that without you feeling like it's a
personal attack if you didn't
and it makes it that much easier for you
to throw your code out there and say hey
take a look at this
you know do you have
i think this works do you have some
suggestions on how it can be better
because that's going to be key to
getting better is not doing the same
thing that you want to do but getting
other people to take a look at it and
point out where you can make
improvements you know if you if you
write code perfect the first time you
will never get better either technically
there'd be no need if you write 100
perfect code there is no better
but nobody does that
so there's always going to be a better
and the the sooner that we remove
we'll say almost the stigma in our own
mind of us not
being at a hundred percent
the sooner we're going to be able to
improve
you